Advanced Networking & Diagnostics

The Networking Basics lesson covered reaching a host. This one is about diagnosing a connection that isn't behaving: what's listening locally, what DNS actually resolved, and where along the path things are slow or broken.

netstat and ss: what's listening

Before you can debug "why won't clients connect," check whether anything is even listening on the port you expect:

netstat
ss

ss ("socket statistics") is the modern replacement for netstat - faster on a real system, and the one you'll find preinstalled going forward. Both report the same shape of information:

Netid  State   Recv-Q  Send-Q   Local Address:Port    Peer Address:Port
tcp    LISTEN  0       128      0.0.0.0:22             0.0.0.0:*

State: LISTEN on 0.0.0.0:22 means: something is bound to port 22, accepting connections from any address. If your own service's port is missing from this list entirely, the problem isn't the network - the service never started, or it's not listening where you think it is.

dig and nslookup: is it DNS?

A surprising fraction of "the server is down" reports are actually DNS problems - the name never resolved to the right address in the first place.

dig example.com
nslookup example.com

dig's output is the more detailed of the two, structured in sections:

;; QUESTION SECTION:
;example.com.       IN  A

;; ANSWER SECTION:
example.com.  300   IN  A  203.0.113.10

;; Query time: 24 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)

The ANSWER SECTION is what you came for: the actual IP address that name resolved to, and a TTL (300, in seconds) telling you how long that answer can be cached before it should be looked up again. nslookup prints the same core answer in a shorter, older format.

traceroute: where does it slow down or stop

Once you know DNS is correct, traceroute shows every network hop between you and the destination, with the round-trip time to each one:

traceroute example.com

traceroute to example.com (203.0.113.10), 30 hops max
1   10.0.1.1        7 ms
2   10.0.2.1       10 ms
3   203.0.113.10   27 ms

Reading it: latency climbing steadily across hops is normal (you're crossing more distance and more routers). A hop that suddenly times out or spikes hard, followed by hops after it recovering, usually points at one overloaded or misconfigured router in the middle - not a problem with your machine or the destination.

A troubleshooting order that actually works

1. Is it DNS? dig the hostname - does it resolve, and to the address you expect?
2. Is it reachable at all? ping the resolved IP directly, bypassing DNS.
3. Is the port open? ss/netstat on the server, or a direct connection attempt from the client.
4. Where's it slow? traceroute to see which hop introduces the delay.

Working in that order - name, then host, then port, then path - finds the actual fault far faster than guessing.

Try it

ss
netstat
dig example.com
nslookup example.com
traceroute example.com

Further reading

• "TCP/IP Illustrated, Volume 1" by W. Richard Stevens (Addison-Wesley) - the deep, authoritative reference for what dig and traceroute are actually showing you on the wire.
• "UNIX and Linux System Administration Handbook" by Nemeth, Snyder, Hein, Whaley, and Mackin (Pearson) - walks through exactly this kind of layered network troubleshooting on real production systems.