🌐 Troubleshooting Linux Network Connectivity Layer by Layer

“It can’t connect” is a sentence that hides at least six different problems: the interface is down, there’s no route, DNS is broken, the port isn’t listening, a firewall is dropping it, or the remote end is the actual fault. Guess randomly and you’ll waste an hour.

After 25 years of network tickets, here’s the layered method I use — bottom of the stack to the top — and where AI reads the dense output so you reach the cause faster.

Work the stack in order

The discipline that saves time: don’t jump to DNS or the firewall. Start at layer 1 and climb. Each step rules out everything below it.

1. Interface up and has an address?

ip addr show
ip link show

Is the interface UP? Does it have the IP you expect? A state DOWN or a missing address ends the investigation right here — bring it up or fix the config before looking anywhere else. The modern ip command replaced ifconfig; if you’re still typing ifconfig, this is your nudge.

2. Is there a route?

ip route show
ip route get 8.8.8.8

ip route get is the underused gem: it tells you exactly which interface and gateway the kernel would use to reach a destination. No default route, or a route pointing at a dead gateway, and nothing leaves the box. This single command answers “can this packet even find its way out.”

3. Can you reach the gateway and beyond?

ping -c3 <gateway-ip>
ping -c3 8.8.8.8

Ping the gateway first (local network OK?), then a public IP (routing/upstream OK?). If the gateway pings but 8.8.8.8 doesn’t, the problem is upstream of you. If 8.8.8.8 works but names don’t — it’s DNS, go to step 4.

4. Is it DNS?

The most common “network” problem isn’t the network:

ping -c3 8.8.8.8        # works
ping -c3 google.com     # fails  -> it's DNS

Confirm with:

resolvectl status        # systemd-resolved
dig google.com
cat /etc/resolv.conf

If dig against a public resolver works but the system default doesn’t, your configured resolver is the problem. “It’s always DNS” is a meme because it’s true.

5. Is the port actually listening?

On the server side, confirm the service is bound:

ss -tlnp
ss -tlnp 'sport = :443'

ss replaced netstat. The flags: t TCP, l listening, n numeric, p process. If your service isn’t in the list, it never bound — that’s an app problem, not a network one. Watch for binds to 127.0.0.1 when you needed 0.0.0.0; a service listening only on localhost is invisible to the network and trips people up constantly.

6. Is a firewall dropping it?

sudo iptables -L -n -v        # or
sudo nft list ruleset
sudo ufw status verbose

Check both the local host firewall and remember there may be a cloud security group upstream. From the client, test whether the port is reachable end to end:

nc -vz host 443

A connection refused means something’s listening but rejecting; a timeout usually means a firewall is silently dropping.

7. When all else fails, watch the packets

sudo tcpdump -ni eth0 host 10.0.0.5 and port 443

tcpdump is the ground truth. It tells you whether packets arrive, whether SYNs get SYN-ACKs, and where the handshake dies. This is dense output — and exactly where AI shines.

Let AI read the dense output

ss, ip route, iptables -L, and especially tcpdump produce walls of terse output. Capture and hand it over:

“Here’s ip addr, ip route get <dest>, ss -tlnp, and a tcpdump capture for a connection that times out. Walk the network stack and tell me at which layer it’s failing and why. Give read-only commands to confirm.”

The model reads a tcpdump trace fast — spotting “SYN sent, no SYN-ACK, so the packet isn’t reaching the listener or a firewall is dropping it” in seconds. That layer-by-layer reasoning is exactly what tired humans skip. I keep these in my prompt library, and it’s the same evidence-first method I use for incident triage: AI reads and reasons, you run the commands.

Two AI cautions for networking

• It invents interface names and IPs. Ask for a command and it may use eth0 when yours is ens5. Always substitute your real values from ip addr.
• It suggests flushing firewall rules. A model debugging a connectivity issue will sometimes propose iptables -F — which on a remote box can lock you out or open everything. Never run a firewall flush on a remote host without console access and a clear rollback.

The one-screen triage

When the ticket lands, run these four in order and you’ve localized 90% of problems:

ip addr show
ip route get <dest>
ss -tlnp
ping -c3 <dest>

Up the stack, one layer at a time. Let AI read the packet captures and the rule sets while you keep your hands on the commands. The network isn’t magic — it’s six checkable layers, and the fault is almost always at the lowest one you haven’t ruled out yet.

AI network diagnoses are assistive. Verify interface names, IPs, and especially firewall commands against your own system before running them.