The Tools, and Which Layer Each One Answers

Every network tool sends something and interprets what comes back, and the something determines what the tool can see. ping sends ICMP echo, so it can tell you whether a host answers ICMP and how long that takes — and nothing about whether port 443 is open. nc opens a TCP connection, so it can tell you whether a listener exists — and nothing about whether the HTTP behind it works. curl sends an HTTP request, so it walks every layer and reports the first one that fails. tcpdump sends nothing at all; it watches, which is why it is the tool that settles arguments.

The map in this lesson answers, for each tool, three things: which layer it exercises, which question it answers cleanly, and — the part nobody memorises — what it cannot tell you. A tool used outside its layer produces confident, misleading output. A failed ping "proving" a service is down is the canonical example; ping: What an Echo Actually Proves is a whole lesson on why.

The interactive lets you pick a tool and see which rungs of the Why Can’t I Connect? ladder it lights up.

Read the fourth column as carefully as the third. Most bad diagnoses come from a tool’s silence being read as evidence about a layer the tool never touched.

curl -v prints, in order: name resolution, the connect attempt with the IP it chose, the TLS handshake with the negotiated version and the certificate it verified, the request it sent, and the response it got. The first line that deviates from that script is the layer that failed. Two flags make it a precision instrument. --resolve host:port:ip skips DNS and pins the connection to an address while keeping the Host header and SNI correct — the only clean way to test "is the new server fine before I flip DNS". -w with a format string prints per-layer timings so you can see where 800 ms went.

On the timings: time_namelookup is DNS, time_connect minus that is the TCP handshake (one RTT), time_appconnect minus time_connect is TLS (one RTT on TLS 1.3, two on 1.2), time_starttransfer minus time_appconnect is the server thinking, and time_total minus time_starttransfer is the body. A server that is "slow" with time_connect at 150 ms and time_starttransfer 30 ms later is not slow; it is far away — see Where the Time Goes: The Request Timeline.

ss (the modern replacement for netstat on Linux) reads socket state straight from the kernel. ss -tlnp — TCP, listening, numeric, with process — is the first command to run on any server that "refuses connections": it shows whether anything is listening, on which address and port, and which PID owns it. The address column is the most frequent surprise: 127.0.0.1:8080 is loopback-only, 0.0.0.0:8080 is every IPv4 interface, [::]:8080 is every interface for both families on a dual-stack host.

For listening sockets Recv-Q is the number of connections that completed the handshake and are waiting in the accept queue, and Send-Q is the backlog limit. A Recv-Q sitting at the limit means the application is not calling accept() fast enough — the server is the bottleneck, not the network. ss -tan lists every connection with its state; ss -tan state time-wait | wc -l and ss -s summarise. -i adds per-connection TCP internals: cwnd, rtt, retransmits.

tcpdump captures at the point where the kernel hands packets to and from the NIC, so it sees exactly what left and arrived on this host — the ground truth that resolves "the client says it sent it" versus "the server says it never came". -n avoids reverse DNS lookups that make it hang; -i any captures all interfaces; a BPF filter such as port 443 and host 203.0.113.10 keeps the noise out; -w out.pcap saves for Wireshark. Flags in the output are S (SYN), S. (SYN-ACK), . (ACK), P. (PSH-ACK, data), F. (FIN), R (RST). Three lines — S, S., . — are a healthy handshake.

Wireshark is the same capture with analysis on top: it flags retransmissions, out-of-order segments, zero windows and RSTs, reassembles TCP streams, and decodes TLS alerts and HTTP/2 frames. Display filters worth memorising: tcp.flags.reset==1, tcp.analysis.retransmission, tcp.analysis.zero_window, tls.alert_message, dns.flags.rcode != 0. Follow → TCP Stream turns a thousand packets into one readable conversation.

nc -vz host port is the fastest port check in existence: it reports "succeeded" (SYN-ACK came back), "Connection refused" (RST), or hangs until timeout (dropped). nc -l 9000 on a server plus nc host 9000 on a client tests a path with no application in the way — if bytes typed on one end appear on the other, the network is fine and the argument moves to the application. openssl s_client -connect host:443 -servername host performs a TLS handshake and prints the certificate chain, the verification result and the negotiated protocol; TLS Debugging: Why the Certificate Is "Invalid" reads its output line by line.

The questions are identical; the names differ. tracert is traceroute but probes with ICMP echo rather than UDP. Test-NetConnection -ComputerName host -Port 443 is nc -vz (and adds a ping and a route lookup; TcpTestSucceeded : True is the line that matters). Resolve-DnsName name -Server 8.8.8.8 is dig @8.8.8.8; ipconfig /displaydns and /flushdns inspect and clear the client cache. netstat -ano and Get-NetTCPConnection replace ss. pathping is a slow but useful mtr. Packet capture is pktmon or Wireshark with Npcap; curl.exe ships with Windows 10+ and behaves like the Unix one (the PowerShell alias curl is Invoke-WebRequest and does not).