Network Diagnostic Tools

The whole series has introduced many tools scattered across the layers. This article gathers them into a single toolkit and, more importantly — a workflow for using them in sequence to pinpoint a problem. Because network troubleshooting isn't guessing; it's going layer by layer (Article 1) to find the break.

Each tool inspects one layer

The most effective way to remember them is to tie each tool to the layer it checks:

   Layer               Question                       Tool
   ─────────────────────────────────────────────────────────────────
   Application (HTTP)  does the server answer HTTP?    curl -v
   TLS                 encryption/certificate okay?    openssl s_client
   DNS                 does the name resolve right?    dig
   Transport (TCP)     port open? service listening?   nc, ss/netstat
   Network (IP)        host reachable? path?           ping, traceroute
   Every layer         see the real packets            tcpdump

A quick pass through each with the most common syntax:

ping — is the host alive and reachable (L3), plus latency and packet loss:

ping -c 3 1.1.1.1

3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max = 31.3/37.4/49.7 ms

0.0% packet loss = reachable; high loss or high RTT = a path problem. (Note: many servers block ICMP so they don't respond to ping even though they're up — a failed ping doesn't always mean dead.)

traceroute — the path to the destination, where it stalls at which hop (L3, Article 4):

traceroute 1.1.1.1

dig — does DNS resolve correctly (Article 7):

dig +short example.com        # does it return an IP yet?
dig +trace example.com        # see the whole resolution chain

ss / netstat — listening ports and connections (L4, Articles 6, 13 of the Linux series):

ss -tlnp                      # Linux: ports in LISTEN + the process
netstat -an -p tcp            # macOS: connections + state

nc — is a port open/reachable (L4, Article 6):

nc -zv example.com 443        # can it connect to port 443?

curl -v — how the server answers HTTP (L7, Article 8):

curl -v https://example.com   # see the request, response, status, headers

openssl s_client — TLS and certificates (Article 9):

openssl s_client -connect example.com:443 -servername example.com

tcpdump — inspect the real packets at every layer (needs root):

sudo tcpdump -n -i any 'port 443 and host example.com'

tcpdump is the "microscope": when the tools above aren't enough, it lets you see every packet (SYN, ACK, ...) on the wire. The most powerful but also the most "raw" — save it for when you need it.

The workflow: pinpoint by layer

When you hit "can't reach https://api.example.com," don't guess — go from the lower layers up (or in the order a request happens). Here's the decision tree:

   1. DNS returns the right IP?    dig +short api.example.com
        ├─ empty/wrong → DNS error (wrong name, wrong record, cache TTL) → Article 7
        └─ returns IP ✓
   2. Host (IP) reachable?         ping <IP>  /  traceroute <IP>
        ├─ no          → network/routing error (or ICMP blocked) → Article 4
        └─ reachable ✓
   3. Port open/reachable?         nc -zv <host> 443
        ├─ timeout     → firewall DROP (Article 10) or service not listening
        ├─ refused     → reached the host but NO ONE listens on that port (ss -tlnp on the server)
        └─ succeeded ✓
   4. TLS okay?                    openssl s_client -connect <host>:443
        ├─ verify error → certificate expired/wrong name (Article 9)
        └─ ok ✓
   5. What does HTTP return?       curl -v https://...
        ├─ 4xx         → your fault (URL, auth, parameters)
        ├─ 5xx         → the server's fault (check server logs)
        └─ 2xx ✓ → the network is fine; the problem (if any) is in the application/logic layer

Each step rules out a layer. The moment a step fails, you know where the problem is and which article to read to fix it. This is the difference between "trying everything" and "diagnosing systematically."

Two symptom pairs that are often confused

Remembering these two pairs saves a lot of time:

• timeout vs connection refused (in nc/curl): timeout = the packet was dropped by a firewall silently, or the host is unreachable; refused = the host was reached but no service listens on that port (the firewall let it through). Two entirely different causes.
• DNS is fine but still can't connect vs DNS is wrong: if dig returns the right IP, rule out DNS — don't waste time there; move on down to TCP/TLS/HTTP.

An environment note

A few tools differ across OSes:

   Linux            macOS              Windows
   ip addr          ifconfig           ipconfig
   ss               netstat            netstat
   traceroute       traceroute         tracert
   dig/curl/nc/openssl: nearly the same

Since servers are mostly Linux, learn the Linux set (ip, ss) primarily; but dig, curl, nc, openssl, ping, traceroute are nearly identical everywhere — that's your "carry-anywhere" set.

Wrap-up

Each diagnostic tool inspects one layer: ping/traceroute (network), dig (DNS), ss/nc (port/TCP), openssl (TLS), curl -v (HTTP), tcpdump (packets at every layer). The real power is in the workflow: go from DNS → host → port → TLS → HTTP, each step ruling out a layer to pinpoint the problem instead of guessing. Remember to distinguish timeout (drop/firewall) from refused (no one listening).

The final article (13) puts it all together: tracing a complete https://... request through every layer we've learned, and a series wrap-up.