Linux Network Troubleshooting: Step-by-Step Diagnosis - 夜莺博客

Linux Network Troubleshooting: Step-by-Step Diagnosis

"The network is down" is one of the most common — and most misdiagnosed — Linux support calls. The disciplined approach is to work from the physical layer upward: interface state, local connectivity, gateway reachability, DNS resolution, routing, and finally application ports. This six-step methodology, based on a practical Linux troubleshooting guide, gives you the exact command sequence to isolate any network problem, plus the fixes for each layer, so you stop jumping straight to tcpdump and start finding root causes in minutes.

Step 1: Check the Interface with ip addr

ip addr show       # or: ip a
sudo ip link set eth0 up        # interface DOWN — bring it up
sudo dhclient eth0              # no IP — request DHCP
ip -s link show eth0            # look for RX/TX errors

A surprising number of "network is down" cases are simply a disabled interface or a missing IP address.

Step 2: Test Local Connectivity with ping

ping -c 3 192.168.1.50     # your own IP — verifies the TCP/IP stack
ping -c 3 192.168.1.1      # another host on the same subnet
ip neigh show              # ARP table — is the gateway MAC being learned?

Step 3: Check Gateway Reachability

ip route show
sudo ip route add default via 192.168.1.1 dev eth0   # no default route
ip neigh show | grep 192.168.1.1
sudo ip neigh flush all

If the gateway doesn't respond, nothing can leave your segment. Check ARP and clear stale entries before assuming the gateway is down.

Step 4: Test DNS with dig

dig +short google.com                  # system resolver
dig +short google.com @8.8.8.8         # bypass /etc/resolv.conf
nc -zvu 8.8.8.8 53                     # is UDP 53 blocked?

If the query works against 8.8.8.8 but not your configured resolver, the DNS server configuration is the problem — not the network.

Step 5: Trace the Route to the Destination

traceroute 8.8.8.8
mtr --report --report-cycles 10 8.8.8.8
sudo traceroute -T -p 443 google.com   # TCP-based trace (ICMP may be filtered)

Each hop that times out narrows the problem to a specific segment of the path.

Step 6: Check Application Ports with ss

sudo ss -tulnp | grep :80
nc -zv 192.168.1.100 80                 # from the client
sudo nft list ruleset | grep "dport 80" # firewall check
sudo tcpdump -i eth0 -nn "port 80" -c 20

If routing and DNS work but the app is unreachable, confirm the service is listening and nothing blocks the port — then capture traffic as the last resort.

Two Common Pitfalls

  • Jumping to complex tools: always start with ip addr and ip route — 10 seconds that should never be skipped.
  • Cached DNS masking intermittent failures: clear caches with resolvectl flush-caches before retesting with dig +short.

For deeper packet-level debugging, pair this with our tcpdump BPF filter guide; for day-to-day Linux ops see Linux server operations from selection to troubleshooting and the Chrony time sync troubleshooting article.

原文链接:https://commandinline.com/linux-network-troubleshooting-guide