linux-network-debugginglisted

# Linux Network Debugging Work down the stack — socket, host, path — and let the failure mode tell you which layer to look at. ## Purpose **Use this when:** - Connections from a host fail with `connection refused`, `connection timed out`, or `connection reset by peer`. - Throughput is poor or transfers stall at a consistent size. - `nf_conntrack: table full` appears in `dmesg`. - You need to interpret `ss`, `netstat`, `tcpdump` or `conntrack` output. **Do not use this when:** - The failure is name resolution — use `dns-troubleshooting`. `no such host` is never a TCP problem. - The failure is HTTP-level (status codes, keepalive, proxies) — use `http-debugging`. - The failure is inside Kubernetes Services or NetworkPolicies — use `kubernetes-networking`. **What this skill assumes:** shell access on at least one end of the connection, and `sudo` for packet capture and conntrack. Capturing on both ends is worth the effort: it is the only way to tell "we never sent it" from "they never received it". ## Operating Procedure 1. **Read the error precisely.** Refused, timeout and reset are three different layers. 2. **Confirm the target.** Resolve the name, and note the IP you are actually connecting to. Half of "network" problems are the client talking to the wrong address. 3. **Test the socket layer** with `ss` locally: is anything listening, is the backlog overflowing. 4. **Test the path** with `curl`, `nc`, or `mtr`. One hop at a time. 5. **Check host-level limits**: