Networking Commands: ip, ss, ping, curl and wget

"The site is down" can mean the DNS name does not resolve, the server has no route, the service is not listening, a firewall drops the packets, or the application returns an error. Each layer has a command that answers its question. This lesson walks up that stack — interfaces and routes, reachability, DNS, listening ports, HTTP — using the modern tools (ip, ss) that replaced ifconfig and netstat, and teaches curl well enough to test any API from the shell.

Interfaces and Addresses: ip

The ip command from the iproute2 package replaces ifconfig, route and arp.

bash

ip -br addr                 # brief: name, state, addresses
ip addr show eth0           # full detail for one interface
ip -br link                 # link state and MAC addresses
ip route                    # routing table; the "default via" line is the gateway
ip route get 8.8.8.8        # which interface and gateway a packet would use
ip neigh                    # ARP table: neighbours seen on the LAN

Reachability: ping, traceroute, mtr

bash

ping -c 4 1.1.1.1                 # 4 packets; tests raw IP connectivity
ping -c 4 example.com             # also tests DNS
traceroute example.com            # each hop toward the destination
mtr -rw example.com               # traceroute plus packet loss per hop, report mode

If ping 1.1.1.1 works but ping example.com fails, the problem is DNS. If neither works, check ip route for a default gateway. Note that many hosts and firewalls block ICMP, so a failed ping does not by itself prove a server is down — test the actual port next.

DNS: dig and resolvectl

bash

dig example.com                    # full answer with TTL
dig +short example.com             # just the addresses
dig example.com MX                 # mail records
dig @1.1.1.1 example.com           # ask a specific resolver
dig -x 93.184.216.34               # reverse lookup
resolvectl status                  # which resolver this machine uses (systemd-resolved)
cat /etc/hosts                     # static overrides checked before DNS
getent hosts example.com           # resolve the way applications do (hosts file + DNS)

Ports and Connections: ss

ss (socket statistics) replaces netstat. The flags spell "tulpn": TCP, UDP, listening, process, numeric.

bash

sudo ss -tulpn                     # every listening port with the owning PID
sudo ss -tulpn | grep :443
ss -tn state established           # active TCP connections
ss -tnp dst :5432                  # who is connected to PostgreSQL

bash

Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      511          0.0.0.0:80         0.0.0.0:*     users:(("nginx",pid=812,fd=6))
tcp   LISTEN 0      511        127.0.0.1:3000       0.0.0.0:*     users:(("node",pid=1290,fd=18))

A service bound to 127.0.0.1 accepts local connections only; 0.0.0.0 or [::] means all interfaces. This distinction explains most "works with curl on the server but not from my laptop" cases.

To test whether a remote port is open without any special tool:

bash

nc -zv example.com 443             # netcat: zero-I/O port check
timeout 3 bash -c '</dev/tcp/example.com/443' && echo open   # bash builtin, no nc required

HTTP from the Shell: curl

curl transfers data over almost any protocol and is the standard way to test web services.

| Option | Purpose | |---|---| | -s / -S | silent (no progress) / but still show errors | | -I | HEAD request: headers only | | -i | include response headers with the body | | -L | follow redirects | | -o file / -O | save to a file / keep the remote name | | -X POST | HTTP method | | -H "Name: value" | add a header | | -d 'data' | request body (implies POST) | | -u user:pass | basic auth | | -w '%{http_code}' | print variables after the transfer | | -k | skip TLS verification (testing only) | | --max-time 10 | overall timeout |

bash

curl -I https://example.com
curl -sL -o page.html https://example.com
curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com
curl -s https://api.example.com/users | jq '.[0].email'
curl -X POST https://api.example.com/users \
     -H "Content-Type: application/json" \
     -H "Authorization: Bearer $TOKEN" \
     -d '{"name":"Ada","role":"admin"}'

-w variables such as %{http_code}, %{time_total} and %{remote_ip} make curl a lightweight health checker in scripts.

Downloading Files: wget

wget is built for downloads: it retries, resumes and can mirror sites.

bash

wget https://example.com/app.tar.gz
wget -O latest.tar.gz https://example.com/app.tar.gz
wget -c https://example.com/big.iso           # continue a partial download

Use curl for APIs and inspection, wget for large or batch downloads.

Common Mistakes

Reaching for ifconfig and netstat; they are deprecated and often not installed. Learn ip and ss.
Declaring a server down because ping fails when ICMP is simply blocked.
Binding an app to 127.0.0.1 and expecting external access, or to 0.0.0.0 and forgetting the firewall.
Testing an API with curl and no Content-Type header, so the server ignores the JSON body.
Using -k in production scripts and silently accepting invalid certificates.

Key Takeaways

ip -br addr and ip route show addresses and the gateway; ss -tulpn shows listening ports and processes.
Work up the stack: ping an IP, then a name (dig), then the port (nc -zv), then the HTTP response (curl -I).
A service on 127.0.0.1 is local-only; 0.0.0.0 listens on all interfaces.
curl with -X, -H, -d, -o and -w tests any API; wget -c resumes big downloads.
ifconfig and netstat are legacy; ip and ss are the tools on modern systems.

Next lesson: SSH, scp and Working with Remote Servers — log in to remote machines securely and copy files between them.