Linux Network Commands: ip, ss, ping, traceroute, dig and curl for Network Troubleshooting

Linux network commands cover almost all everyday troubleshooting: ip shows addresses and routes, ss shows open ports and connections, ping and traceroute check whether a host is reachable, dig checks DNS, and curl checks what a web service returns. Below is a cheat sheet with the most useful flags and a step-by-step order for finding the cause when "the network is down".

Cheat sheet: linux network commands in one table

ip: addresses, interfaces and routes

The ip command from the iproute2 package has replaced the outdated ifconfig and route. Subcommands can be shortened: ip a is ip addr, ip r is ip route. The -br flag gives a brief output, and -c colours it.

$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             192.168.1.25/24 fe80::a00:27ff:fe4e:66a1/64
docker0          DOWN           172.17.0.1/16

If an interface has no address from the network you expect, or it is in the DOWN state, there is no point looking further: the problem is at this level.

How to add an IP address and bring up an interface

sudo ip link set eth0 up
sudo ip addr add 192.168.1.50/24 dev eth0
sudo ip addr del 192.168.1.50/24 dev eth0

Changes made with ip last until the next reboot. Permanent settings belong in the system configuration: netplan on Ubuntu, NetworkManager (nmcli) on Fedora and RHEL, systemd-networkd on servers.

Routes and the default gateway

$ ip route
default via 192.168.1.1 dev eth0 proto dhcp metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.25

$ ip route get 10.20.0.5
10.20.0.5 via 192.168.1.1 dev eth0 src 192.168.1.25 uid 1000

The default via line is the gateway that receives everything not matched by a more specific route. If that line is missing, there is no internet access even though the local network works. To add a route: sudo ip route add 10.20.0.0/16 via 192.168.1.254.

ss: which ports are open and who is listening

ss has replaced netstat and runs faster. The most common combination is ss -tulpn:

$ sudo ss -tulpn
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      128          0.0.0.0:22         0.0.0.0:*     users:(("sshd",pid=640,fd=3))
tcp   LISTEN 0      151        127.0.0.1:3306       0.0.0.0:*     users:(("mysqld",pid=901,fd=21))

Pay attention to the address: 0.0.0.0 means the service accepts connections from all interfaces, 127.0.0.1 means local connections only. This is a common reason a database "does not respond" from another machine.

How to find out who occupies a port

sudo ss -ltnp 'sport = :8080'
sudo ss -tn dst 10.0.0.7          # connections to a specific address
ss -tan state time-wait | wc -l   # how many sockets are in TIME-WAIT

ping: is a host reachable

ping sends ICMP echo requests and shows the response time and packet loss. On Linux it runs forever, so set the number of packets with -c.

$ ping -c 4 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=12.4 ms
...
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 12.1/12.5/13.0/0.3 ms

Useful flags: -i 0.2 sets the interval, -W 2 sets the reply timeout, -4/-6 select the IP version, -s 1472 -M do checks the MTU without fragmentation. Keep in mind that many servers and clouds block ICMP: no reply to ping does not mean the host is unreachable.

traceroute and mtr: where packets are lost

traceroute shows the hops on the path to the target. Asterisks on individual hops are normal, because an intermediate router may not reply. A warning sign is when asterisks continue all the way to the end after a certain hop.

traceroute -n example.com        # without DNS names, faster
sudo traceroute -T -p 443 example.com   # TCP instead of UDP, passes through firewalls
tracepath example.com            # runs without root, also shows the MTU

mtr combines ping and traceroute and updates the loss statistics for each hop in real time. For a report: mtr -rwc 50 example.com.

dig: DNS checks

dig from the dnsutils package (bind-utils on RHEL) is the main tool for checking DNS. The short form returns only the answer:

$ dig +short example.com
93.184.215.14

$ dig example.com MX +short
$ dig @8.8.8.8 example.com A       # ask a specific server
$ dig -x 8.8.8.8 +short            # reverse lookup (PTR)
$ dig +trace example.com           # walk the chain from the root servers

In the full output, look at status: NOERROR means the record was found, NXDOMAIN means the domain does not exist, SERVFAIL means the server could not answer (often a DNSSEC problem or an unreachable authoritative server). If dig @8.8.8.8 answers but plain dig does not, the local resolver is at fault: check /etc/resolv.conf and resolvectl status.

Note that dig does not read /etc/hosts. To check name resolution the way an application will do it, use getent hosts example.com.

curl: checking HTTP and APIs

curl answers the last question: whether a service responds and what exactly it returns.

$ curl -s -o /dev/null -w '%{http_code} %{time_connect} %{time_total}\n' https://example.com
200 0.041 0.187

curl error messages point clearly to the layer at fault: Could not resolve host means DNS, Connection refused means the port is closed or nothing is listening, Connection timed out means a firewall is dropping packets or there is no route, SSL certificate problem means a certificate issue.

Troubleshooting order: when "the network does not work"

1. Interface and address: ip -br addr — the interface is UP and has an address.
2. Gateway: ip route — there is a default via line; then ping -c 3 <gateway>.
3. External network by IP: ping -c 3 1.1.1.1. If it works, routing is fine.
4. DNS: dig +short example.com. An empty answer or an error while ping by IP works points to the resolver.
5. Port: nc -zv host 443 or curl -v. On a server, ss -tulpn shows whether the service is listening and on which address.
6. Firewall: sudo nft list ruleset, sudo iptables -L -n, sudo ufw status.
7. Application: curl -I and the service logs (journalctl -u nginx).

Work from the bottom up and do not skip steps: this way you find out in a couple of minutes which layer has the problem, instead of restarting everything in turn.

Old and new commands

Recent distributions often do not install net-tools at all, so get used to the new commands.

Summary

Six Linux network commands are enough for everyday troubleshooting: ip, ss, ping, traceroute, dig and curl. Check layer by layer — address, route, DNS, port, application — and the fault is found quickly. Our Linux course shows these network commands and typical failures in practice.