Debugging Network Problems and Networking Interview Questions

This is the last lesson of the series. The earlier lessons gave you the pieces: layers and packets, IP and routing, TCP and UDP, DNS, HTTP, TLS, proxies and load balancers and real-time connections. Now we put them to work. When something is broken at 2 a.m., you do not need more theory. You need a short list of commands, a habit of reading their output, and a fixed order to follow.

The lesson has two halves. The first half is a toolbox, with real output from a small lab. The second half is a long list of interview questions with model answers, because networking is asked about in almost every backend, DevOps and full-stack interview.

Words used in this lesson

• A timeout means a wait that ended because nothing came back in time. It is different from a refusal, where something answered "no".
• Connection refused means the machine answered, and said no program listens on that port. It is an active answer (a TCP RST).
• A packet capture (or pcap) is a recording of packets on a network interface, saved to a file so you can read it later.
• tcpdump is a command-line tool that captures and prints packets.
• Wireshark is a graphical program that reads packet captures and decodes them layer by layer. tshark is its command-line twin.
• A BPF filter is the small filter language (tcp port 80 and host 10.0.0.5) that tcpdump and Wireshark use to choose which packets to capture.
• A socket state is the stage a TCP connection is in: LISTEN, ESTABLISHED, TIME_WAIT, CLOSE_WAIT and so on.
• TTFB (time to first byte) is the time from sending a request until the first byte of the answer arrives.
• NXDOMAIN is the DNS answer that means "this name does not exist".
• An exit code is the number a command returns when it ends. 0 means success. curl uses many different non-zero codes to say what failed.
• A resolver is the part of the system (or a server) that turns a name into an address.

The method: one layer at a time

When a request fails, the worst thing to do is to change things at random. The second worst thing is to stare at the app log. Instead, work through the stack in order. Each step has one question and one tool.

The order matters, because a step can only work if the earlier ones did. An HTTP 502 tells you that DNS, routing, TCP and even TLS all worked to reach something. A Could not resolve host tells you to stop looking at the app, since no packet was even sent.

We will go through the tools in this order, then collect them in a checklist.

curl: the tool you will use most

curl speaks HTTP, but it also tells you what happened underneath. Three flags matter most: -v (verbose), -w (write out timings and facts) and -o /dev/null (throw away the body so you can see the facts).

curl -v: see the conversation

$ curl -v http://127.0.0.1:8090/fast*   Trying 127.0.0.1:8090...* Connected to 127.0.0.1 (127.0.0.1) port 8090> GET /fast HTTP/1.1> Host: 127.0.0.1:8090> User-Agent: curl/8.5.0> Accept: */*>< HTTP/1.1 200 OK< Date: Sat, 17 Oct 2026 13:30:04 GMT< Connection: keep-alive< Keep-Alive: timeout=5< Content-Length: 8<fast ok* Connection #0 to host 127.0.0.1 left intact

(I removed the progress meter and the { [8 bytes data] lines to keep it short.) The marks are the key:

• Lines that start with * are curl's own notes: which address it tried, whether it connected, what TLS version it got.
• Lines that start with > are what curl sent (the request).
• Lines that start with < are what the server sent back (the response).

So in one command you can answer: did DNS work (it printed an address), did TCP connect (Connected to), what exactly did I send (> lines), what status came back (< first line). When you are unsure whether your code sends the right headers, send the same request with curl -v and compare.

curl -w: measure where the time goes

The -w flag prints values after the transfer. These are the ones to know:

Each value counts from the very start, so they only go up. To get the time of one step, subtract the one before it. Here is the fast page and the slow page, with the same command:

$ curl -s -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code} ip=%{remote_ip}:%{remote_port}\n' http://127.0.0.1:8090/slowdns=0.000019 connect=0.000279 tls=0.000000 ttfb=1.502215 total=1.502338 code=200 ip=127.0.0.1:8090$ curl -s -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' http://127.0.0.1:8090/fastdns=0.000018 connect=0.000132 ttfb=0.001004 total=0.001045 code=200

Read the first line like a doctor reads a chart. DNS took almost nothing. The connection opened in 0.3 ms. Then nothing happened for about 1.5 seconds, and the first byte arrived at 1.502. The body then took 0.1 ms (total minus ttfb). So the time is inside the server, between "request received" and "first byte sent". The network is not the problem, and it would be a waste to tune DNS or TLS. That one reading saves hours.

Compare this with the patterns you will meet on real systems:

I used the "real" lab numbers above, but the table is the general rule. Note that on loopback every network number is tiny. Against a real remote server you will see connect close to one round trip time, and appconnect one more (TLS 1.3) or two more (TLS 1.2).

curl exit codes tell you the layer

When a curl command fails, its exit code is a fast clue. I triggered each of these on purpose:

$ curl -sS http://no-such-host.invalid/curl: (6) Could not resolve host: no-such-host.invalid          # exit=6$ curl -sS http://127.0.0.1:8099/                                 # nothing listens on 8099curl: (7) Failed to connect to 127.0.0.1 port 8099 after 0 ms: Couldn't connect to server    # exit=7$ curl -sS --max-time 0.5 http://127.0.0.1:8090/slow             # server waits 1.5 scurl: (28) Operation timed out after 501 milliseconds with 0 bytes received    # exit=28

And these from the earlier TLS lesson: (60) for a certificate problem, (35) for a handshake failure, (56) for a reset while reading. A cheat sheet:

The -f flag is handy in scripts. Without it, curl treats a 500 as success (exit 0), because the HTTP conversation itself worked. With it, you get a failing exit code:

$ curl -s -w 'code=%{http_code}\n' http://127.0.0.1:8090/500boomcode=500$ curl -sf http://127.0.0.1:8090/500 ; echo "exit=$?"exit=22

More curl tricks that save time

• Follow redirects and show where you ended up. Without -L, curl shows the redirect itself. With it, you can print how many hops there were:

$ curl -sS -o /dev/null -D - http://127.0.0.1:8090/redir | head -3HTTP/1.1 302 Foundlocation: /fastDate: Sat, 17 Oct 2026 13:30:41 GMT$ curl -sL -o /dev/null -w 'code=%{http_code} redirects=%{num_redirects} url=%{url_effective}\n' http://127.0.0.1:8090/redircode=200 redirects=1 url=http://127.0.0.1:8090/fast

• Test a name before DNS is changed, with --resolve. It makes curl use an address you choose for a name, while still sending the right Host header and (for HTTPS) the right SNI. This is how you test a new server before you move DNS to it:

$ curl -s --resolve app.lab.test:8090:127.0.0.1 -w 'code=%{http_code} ip=%{remote_ip}\n' http://app.lab.test:8090/fastfast okcode=200 ip=127.0.0.1

• Always set timeouts in scripts: --connect-timeout 3 --max-time 10, or a hung connection can block a deploy for minutes.

dig: ask DNS directly

curl hides DNS behind the system resolver. dig talks to a DNS server directly and shows the full answer, so you can tell which server said what. The lab DNS server runs on port 5354 on my machine, so I add -p 5354 and @127.0.0.1 (the server to ask). In real life you leave out -p and often leave out @server.

$ dig @127.0.0.1 -p 5354 app.lab.test;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63281;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0;; QUESTION SECTION:;app.lab.test.			IN	A;; ANSWER SECTION:app.lab.test.		300	IN	A	10.1.2.3;; Query time: 0 msec;; SERVER: 127.0.0.1#5354(127.0.0.1) (UDP);; WHEN: Sat Oct 17 13:30:17 UTC 2026;; MSG SIZE  rcvd: 46

(The ; <<>> DiG ... banner and a few empty lines are trimmed.) What to read here:

• status: NOERROR is the result code. NXDOMAIN means the name does not exist. SERVFAIL means the server could not get an answer (often a broken upstream or a bad DNSSEC setup).
• flags: qr is "this is a response". aa means an authoritative answer, from the server that owns the name. rd and ra mean recursion was asked for and is available. A normal answer from your provider's resolver shows ra but no aa, since it is passing along something it cached or fetched.
• ANSWER SECTION: name, TTL (300 seconds here), class IN, type A, and the value. The TTL is how long a cache may keep it. If you ask a caching resolver twice, the TTL counts down, which proves you got a cached answer.
• Query time and SERVER: how long the lookup took, and which server really answered. This is how you find out whether your machine uses the server you think it does.

A name that does not exist:

$ dig @127.0.0.1 -p 5354 missing.lab.test | grep -E "status|flags";; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54930;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

And a DNS server that is not there. Notice that dig tells you in plain words:

$ dig @127.0.0.1 -p 5399 +time=1 +tries=1 app.lab.test;; no servers could be reached

That is a DNS timeout, and it is the DNS twin of a firewall drop: UDP packets went out, and nothing answered. The system resolver would retry and wait, and your app would show a slow first request.

For scripts, +short prints only the value:

$ dig @127.0.0.1 -p 5354 +short api.lab.test10.1.2.4

The dig options I use most, in real work:

The most useful pair is the last two. If dig @your-authoritative-server name shows the new record but dig name still shows the old one, the answer is cached somewhere, and the TTL tells you how long to wait. If both show the old one, the change was never published. The first case is waiting. The second case is a bug in your DNS config.

Also remember that dig does not use the same path as your program. Your program calls the system resolver, which can read /etc/hosts, apply search domains from /etc/resolv.conf, use a local cache, and apply rules like nsswitch. So "dig works but my app cannot resolve" is a real thing. When it happens, compare with getent hosts name (which uses the system path), or with curl -v, which does what your app does.

ss: who is listening, who is connected

ss (socket statistics) lists the sockets on the machine. It replaced the old netstat. Two questions cover most uses: "is anything listening on this port?" and "what connections exist?"

$ ss -ltnp | grep 8090LISTEN 0      511        127.0.0.1:8090       0.0.0.0:*    users:(("node",pid=849,fd=21))

The flags: -l listening sockets only, -t TCP, -n show numbers (do not resolve names, which is faster and clearer), -p show the process (you may need sudo for other users' processes). The columns:

• LISTEN is the state. 127.0.0.1:8090 is the local address and port.
• The address is the thing people miss. 127.0.0.1:8090 means only this machine can connect. 0.0.0.0:8090 or *:8090 means every interface. [::]:8090 is the same in IPv6. If a container service works inside the container but not from outside, check this first. A server bound to 127.0.0.1 inside a container is invisible from outside it. We saw the same fix in lesson 0.
• users:(("node",pid=849,...)) names the program that owns the socket. This answers "what is using port 8090?" when you get EADDRINUSE.

Show the established connections for one port, with extra TCP details (-i) and timers (-o):

$ ss -tnoi state established dport = :8090Recv-Q Send-Q Local Address:Port  Peer Address:Port0      0          127.0.0.1:52176    127.0.0.1:8090	 ts sack bbr wscale:10,10 rto:204 rtt:0.186/0.093 mss:32741 pmtu:65535 cwnd:10	 bytes_acked:1 segs_out:2 segs_in:1 ... minrtt:0.186

(Shortened; the real line has more fields.) The interesting part is the second line, which comes straight from the kernel's TCP state: rtt:0.186/0.093 is the smoothed round-trip time and its variation in milliseconds, cwnd:10 is the congestion window (lesson 2), rto:204 is the retransmit timeout. On a real remote connection, a large rtt, a growing retrans field or a small cwnd tells you the path itself is the problem, with no need for a packet capture.

Also look at the summary:

$ ss -s | head -3Total: 91TCP:   517 (estab 63, closed 446, orphaned 0, timewait 446)

This sandbox shows 446 sockets in TIME_WAIT, because my lab made many short connections. TIME_WAIT is normal. It is the side that closed first waiting a short time to be safe (lesson 2). It only becomes a worry when a client makes thousands of new connections per second to the same address and runs out of local ports. The cure is connection reuse (keep-alive), not a kernel tweak.

Three states are worth recognising by name:

CLOSE_WAIT is the one that points at your code. The kernel is waiting for your program to call close(). If the count grows without stopping, you have a leak, and the process will eventually run out of file descriptors. I describe this from the TCP state machine; I did not build a leak in this lab.

For old habits: netstat -tlnp shows nearly the same as ss -ltnp. On macOS, ss does not exist; use lsof -iTCP -sTCP:LISTEN -n -P.

Reach checks: ping, nc and traceroute

Three small tools check the middle layers.

nc -zv host port (netcat) tries to open a TCP connection and says whether it worked. It is the cleanest "is the port open?" test, because it involves no HTTP and no TLS. -z means "just scan, send nothing", -v means "talk to me".

$ nc -zv 127.0.0.1 8090Connection to 127.0.0.1 8090 port [tcp/*] succeeded!$ nc -zv 127.0.0.1 8099 ; echo exit=$?nc: connect to 127.0.0.1 port 8099 (tcp) failed: Connection refusedexit=1

A connect that hangs for a long time and then fails with a timeout would tell you the packets are being dropped. With nc you can limit the wait: nc -zv -w 3 host port.

ping host sends ICMP echo packets and times the reply (lesson 0). If ping works, the route and the machine are fine. If ping fails, it proves nothing by itself: many networks and cloud security groups block ICMP while TCP works fine. So "ping fails" is not a diagnosis. "The TCP port test fails" is.

traceroute -n host shows the routers on the way, using the TTL trick from lesson 0. The -n flag skips reverse lookups, which makes it much faster.

$ traceroute -n -m 2 127.0.0.1traceroute to 127.0.0.1 (127.0.0.1), 2 hops max, 60 byte packets 1  127.0.0.1  0.351 ms  0.298 ms  0.260 ms

On loopback it is one boring hop. On a real path, read it like this: the hop where the time jumps and stays high is where the long link is (an ocean, for example). A row of * * * means that router sent no reply, which is often by design and does not mean the path is broken. If the trace stops and never reaches the target, but the later hops stay silent for everything, the packet may be dropped at the last visible hop. mtr combines ping and traceroute in a live view and is better for finding loss on a hop; it is not installed in this sandbox, so I did not run it.

tcpdump: look at the real packets

When the higher-level tools disagree with each other, or when you need proof, you read the packets. tcpdump is installed on nearly every Linux box and shows each packet as one line. It needs root (sudo).

A good first command has four parts:

sudo tcpdump -i lo -nn -c 12 'tcp port 8090'

• -i lo is the interface (lo is loopback; on a real machine it might be eth0 or ens5; -i any captures on all of them).
• -nn means show numbers for addresses and ports instead of looking up names. Name lookups slow the output and can create DNS traffic of their own.
• -c 12 stops after 12 packets, so it cannot run forever.
• 'tcp port 8090' is the filter, in BPF syntax. Without a filter on a busy server you get a flood.

Here is what it showed while curl made one request (this is a real capture; timestamps cut to the second part). Read the Flags column:

13:30:18.717230 IP 127.0.0.1.37700 > 127.0.0.1.8090: Flags [S],  seq 3234883332, win 65495, options [mss 65495,sackOK,TS val 3633403536 ecr 0,nop,wscale 10], length 013:30:18.717254 IP 127.0.0.1.8090 > 127.0.0.1.37700: Flags [S.], seq 3572550400, ack 3234883333, win 65483, options [...], length 013:30:18.717270 IP 127.0.0.1.37700 > 127.0.0.1.8090: Flags [.],  ack 1, win 64, length 013:30:18.717325 IP 127.0.0.1.37700 > 127.0.0.1.8090: Flags [P.], seq 1:82, ack 1, win 64, length 8113:30:18.717329 IP 127.0.0.1.8090 > 127.0.0.1.37700: Flags [.],  ack 82, win 64, length 013:30:18.719153 IP 127.0.0.1.8090 > 127.0.0.1.37700: Flags [P.], seq 1:131, ack 82, win 64, length 13013:30:18.719187 IP 127.0.0.1.37700 > 127.0.0.1.8090: Flags [.],  ack 131, win 64, length 013:30:18.719403 IP 127.0.0.1.37700 > 127.0.0.1.8090: Flags [F.], seq 82, ack 131, win 64, length 013:30:18.719637 IP 127.0.0.1.8090 > 127.0.0.1.37700: Flags [F.], seq 131, ack 83, win 64, length 013:30:18.719665 IP 127.0.0.1.37700 > 127.0.0.1.8090: Flags [.],  ack 132, win 64, length 0

The flags, in order: [S] is SYN (the client asks to open), [S.] is SYN-ACK (the server agrees), [.] is a plain ACK, so the first three lines are the three-way handshake from lesson 2. [P.] means PUSH plus ACK: data. The first data packet has length 81, and that is the HTTP request. The server's length 130 data packet is the response. Then [F.] (FIN) packets close the connection from both sides. The whole exchange took about 2.4 ms on loopback.

The common things you can prove from a capture:

To read HTTP in plain text, add -A (print the payload as ASCII). On unencrypted HTTP you can read the request and the response straight from the packets:

$ sudo tcpdump -i lo -nn -A -s0 'tcp port 8090 and tcp[tcpflags] & tcp-push != 0'13:30:28.865482 IP 127.0.0.1.52186 > 127.0.0.1.8090: Flags [P.], ... length 81...GET /fast HTTP/1.1Host: 127.0.0.1:8090User-Agent: curl/8.5.0Accept: */*13:30:28.866565 IP 127.0.0.1.8090 > 127.0.0.1.52186: Flags [P.], ... length 130...HTTP/1.1 200 OKDate: Sat, 17 Oct 2026 13:30:28 GMTConnection: keep-aliveKeep-Alive: timeout=5Content-Length: 8fast ok

(Binary bytes before each text block are trimmed.) The filter tcp[tcpflags] & tcp-push != 0 keeps only packets with the PUSH flag, which are the ones that carry data, so the handshake noise is gone. This is a great way to see the actual bytes when "my client says it sends X but the server says it got Y". With HTTPS you will see only scrambled bytes (lesson 5), so for HTTPS debug at the application level, or use a proxy tool, or the SSLKEYLOGFILE feature described below.

DNS is on UDP and is just as easy to watch:

$ sudo tcpdump -i lo -nn -c 4 'udp port 5354'13:30:32.883603 IP 127.0.0.1.57263 > 127.0.0.1.5354: UDP, length 5313:30:32.883821 IP 127.0.0.1.5354 > 127.0.0.1.57263: UDP, length 46

One small packet out (53 bytes: the question), one back (46 bytes: the answer). If you see the question leave and nothing return, the DNS server is not answering, and you have found your delay. (tcpdump 4.99 can also decode DNS names with -v; I did not use that here.)

Save to a file, read it later

On a server you rarely want to stare at live output. Write to a file with -w, then read it with -r on any machine, including in Wireshark:

$ sudo tcpdump -i lo -nn -c 12 -w cap.pcap 'tcp port 8090'$ tcpdump -nn -r cap.pcap | headreading from file cap.pcap, link-type EN10MB (Ethernet), snapshot length 26214413:30:18.717230 IP 127.0.0.1.37700 > 127.0.0.1.8090: Flags [S], ...

You can even filter the saved file again. I counted the SYN packets in my file with tcpdump -nn -r cap.pcap 'tcp[tcpflags] & tcp-syn != 0' | wc -l, and got 2 (one SYN and one SYN-ACK, both have the SYN bit set). That was one connection, as expected.

Wireshark and tshark: the basics

Wireshark opens a .pcap file and decodes every layer: Ethernet, IP, TCP, then TLS, HTTP or DNS. Three features give most of the value, and none of them need deep knowledge:

1. Display filters (not the same language as tcpdump's capture filters). Examples: ip.addr == 10.0.0.5, tcp.port == 8090, http.request, dns.qry.name == "app.lab.test", tcp.analysis.retransmission, tls.handshake.type == 1 (client hellos), tcp.flags.reset == 1.
2. Follow TCP Stream (right-click a packet). It glues the data of one connection back together and shows the whole conversation as text, like a transcript. For plain HTTP that is the request and response.
3. Expert Information (menu Analyze). Wireshark flags the things it found by itself: retransmissions, duplicate ACKs, zero windows, resets. It is like having a junior engineer read your capture first.

Also useful: Statistics, then Conversations, to see which connections moved the most bytes, and Statistics, then I/O Graph, to see bursts and stalls on a timeline.

The command-line twin, tshark, does the same on servers without a screen (for example tshark -r cap.pcap -Y 'http.request' or -Y 'tcp.analysis.retransmission'). I could not run tshark here (not installed), so check tshark --help on your system. For your own HTTPS traffic, browsers, curl and Node can write TLS session secrets to a file named by SSLKEYLOGFILE, and Wireshark can read it to show the decrypted HTTP. I did not run this either.

Checking TLS from outside: openssl s_client

For TLS, one command from lesson 5 is your first stop:

echo | openssl s_client -connect host:443 -servername host

It prints the certificate chain, the protocol, the cipher, and Verify return code. Use -servername so that SNI is sent. Common reading: Verify return code: 0 (ok) is good, 10 (certificate has expired), 18 or 19 (self-signed), 20 or 21 (cannot get the issuer, often a missing intermediate). Check the dates directly with openssl x509 -noout -dates. And for monitoring, openssl x509 -checkend returns exit code 1 if a certificate expires within the given seconds. The lab output for these is in lesson 5, so I will not repeat it.

Common failures and what they mean

Here is a field guide that links what you see to a cause. The first column is the symptom as the user or log shows it.

The 502 versus 504 split deserves one more sentence. Both come from a proxy or load balancer (lesson 6). A 502 means the backend answered badly or closed the connection. A 504 means the backend did not answer in time. They point in different directions: 502 means look for crashes and protocol mismatches, 504 means look for slowness. And the key test for both is to bypass the proxy and call the backend directly with curl -w.

The Node-specific error ECONNRESET on a reused connection is worth a second look. HTTP keep-alive (lesson 4) holds a connection open. If the server's idle timeout is shorter than the client's, the server closes the connection while the client thinks it is still good. The next request on it fails with a reset. The fix is to make the client's idle timeout shorter than the server's (and the load balancer's), or to retry safe requests once.

A troubleshooting checklist, layer by layer

Print this, or keep it in your notes. It assumes you are on the client, and that "the service" is https://api.example.com/health.

1. Name (DNS).

• dig +short api.example.com returns an address? If not, DNS is the problem.
• Compare resolvers: dig @1.1.1.1 +short api.example.com. If they differ, a cache or a split-horizon setup is involved.
• Check TTLs with dig api.example.com +noall +answer.
• If dig works but the app fails, test the app's path: getent hosts api.example.com, and look at /etc/resolv.conf and /etc/hosts.

2. Address and route (IP).

• Does the client have an address and a default route? ip -br addr, ip route.
• Is the destination private or public, and is the client on a network that can reach it? (Lesson 1: CIDR, NAT.)
• traceroute -n host to see where the path ends. Remember that blocked ICMP is common, so ping alone proves little.
• Mixed IPv4 and IPv6: curl -4 and curl -6 to try each.

3. Port (TCP).

• nc -zv -w 3 host 443. Success means TCP works end to end. Refused means the server machine answers, but nothing listens (or a rule sends a reset). A timeout means silence: look at security groups, firewalls, network ACLs and routes.
• On the server: ss -ltnp | grep :443. Is the program listening, and on which address? Is it 127.0.0.1 only?
• On the server: is the machine's own firewall blocking? (iptables -S, nft list ruleset, ufw status, depending on the system.)
• Cloud: is the security group open for this source and port? Are the network ACLs open both ways? (An ACL is stateless: the reply direction needs its own rule.)

4. Secure channel (TLS).

• echo | openssl s_client -connect host:443 -servername host: look at Verify return code, the chain, the dates and the protocol.
• Compare the client's clock: date -u.
• Names in the SAN list match what the client uses? Intermediate included?
• A corporate proxy that re-signs certificates? Check the issuer you actually receive.

5. Request and response (HTTP).

• curl -v https://api.example.com/health: status, redirects, headers (Location, Content-Type, Cache-Control, Via, Server).
• Same request, different layer: add -H 'Host: ...' or use --resolve to hit each backend address directly.
• Is a redirect looping? curl -sL -o /dev/null -w '%{num_redirects}\n' --max-redirs 10 url.
• Is the answer cached by a CDN? Look for Age, X-Cache style headers (the names depend on the provider).

6. Time.

• curl -w with the timing variables, 5 to 10 runs. Which gap is large?
• If the gap is before the first byte and the network numbers are small: go to the server (logs, traces, database). The Scenario Debugging series shows how to trace a slow backend.
• If connect is large: distance or loss. ss -ti for retrans, or tcpdump for repeated sequences.

7. Capture the packets if two tools disagree. tcpdump -i any -nn -w cap.pcap 'host X and port Y' on the client, and on the server, if you can. Compare: did the SYN leave the client? Did it arrive at the server? Did the reply leave? Where does the packet disappear? Captures at both ends tell you which side of a firewall to blame.

Try it

Use any machine with curl, dig, ss, nc and (with sudo) tcpdump. If you want my exact lab, a 10-line Node server with a /slow route that waits 1.5 seconds is enough.

1. Start any local HTTP server. Run ss -ltnp and find it. What address does it listen on?
2. Run curl -s -o /dev/null -w 'connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total}\n' http://127.0.0.1:PORT/ for a normal route and for a slow one. Which number differs, and what does that tell you about where the delay lives?
3. Run curl -sS http://127.0.0.1:59999/ (a port where nothing listens). What exit code and message do you get? Is it a refusal or a timeout? How can you tell from the time it took?
4. Run curl -sS http://does-not-exist.invalid/. What is the exit code? Which layer does it name?
5. In one terminal run sudo tcpdump -i lo -nn -c 12 'tcp port PORT'. In another, run one curl request. Match each packet to the handshake, the request, the response and the close.
6. A user says "the site is down". Using the table in this lesson, write down the first five commands you would run, in order, and what each result would mean.

Answers

1. If you bound to 127.0.0.1 you see 127.0.0.1:PORT. If you bound to 0.0.0.0 you see 0.0.0.0:PORT or *:PORT. Only the second one is reachable from other machines.
2. time_connect is nearly the same (tiny). time_starttransfer (TTFB) and total jump on the slow route. The network and TCP are fine. The delay is in the server's handling of the request.
3. Exit code 7, Failed to connect ... Couldn't connect to server. It is a refusal. It returned immediately (I saw after 0 ms). A timeout would have taken seconds and given exit code 28 or a long connect wait.
4. Exit code 6, Could not resolve host. It is DNS. No packet to the target was ever sent. (.invalid is a reserved name that never resolves.)
5. Expect [S], [S.], [.] (handshake), then [P.] with length around 80 (request), [.] ack, [P.] with length around 130 (response), ack, and [F.] packets (close). Exact lengths depend on the headers.
6. A good answer: (1) dig +short name (DNS), (2) nc -zv -w 3 host 443 (route and port), (3) echo | openssl s_client -connect host:443 -servername host (TLS), (4) curl -v https://name/ (HTTP status), (5) curl -w timings plus ss -ltnp on the server. Each result names the layer where to dig deeper.

Interview questions

Networking questions come in two forms: "explain how X works" and "something is broken, what do you do?". The answers below are written the way I would say them. The parts I actually tested are marked in the text. Where an answer depends on tools or numbers I did not run, I say so.

Key takeaways

• Debug one layer at a time, from the bottom up: name, route, port, listener, TLS, HTTP, time. The error message usually names the layer.
• Refused (immediate reset) means a machine answered and nothing listens. Timed out means silence, which usually means a firewall, a wrong address or a dead host. Telling these apart is the most useful first step.
• curl -v shows what was sent (>) and received (<). curl -w with time_namelookup, time_connect, time_appconnect, time_starttransfer and time_total tells you which step owns the delay. Run it several times.
• curl exit codes name the layer: 6 DNS, 7 connect, 28 timeout, 35 and 60 TLS, 22 HTTP error with -f.
• dig shows the status (NOERROR, NXDOMAIN, SERVFAIL), the TTL and which server answered. Ask the authoritative server directly to bypass caches. dig is not the same path as your app.
• ss -ltnp shows what listens and on which address (127.0.0.1 versus 0.0.0.0). ss -ti shows RTT and retransmissions. A growing CLOSE_WAIT count is a bug in your code.
• nc -zv is the cleanest port test. Ping failing proves little, because ICMP is often blocked.
• tcpdump with a narrow filter shows the handshake, the data and the closing, and proves where a packet disappears. Capture at both ends when tools disagree. Treat captures as sensitive data.
• Wireshark and tshark add decoding, display filters, Follow TCP Stream and expert warnings. SSLKEYLOGFILE lets you read your own HTTPS traffic without weakening security.
• 502 means a bad answer from the backend, 503 means unavailable, 504 means the backend was too slow. Bypass the proxy and test the backend directly.

What's next

You have finished the networking series. If you read all nine lessons, you can now explain the path of a request from the first DNS lookup to the last byte, and you have the tools to prove where it went wrong. The best next step is to use these skills in the area you work in:

• System Design takes the building blocks from lessons 6 and 7 (load balancers, caches, CDNs, long-lived connections) and shows how they fit into large systems that must scale, stay up and stay fast. It is the natural follow-up for interviews.
• DevOps is where you apply this to real infrastructure: servers, virtual networks and subnets, security groups, DNS records and deployment. The networking lesson in that series covers the cloud side of the same ideas.
• Linux and the Shell teaches the command line that all of the tools in this lesson run in: files, processes, pipes and scripts, so you can chain curl, dig and ss into your own checks.
• Scenario Debugging practises the "measure, isolate, fix, check" method on slow-API and slow-UI cases, and picks up exactly where the curl -w timings leave off.
• Docker and Kubernetes shows container networking, where "bound to 127.0.0.1" and published ports cause the classic problems from this lesson.
• Security covers the application side of what we built here, such as secrets, headers and attacks that go through the network.

To practise right now, take any service you run or use and write the first five commands you would run if it failed, in order, with what each result would tell you (Try it, number 6). Then break something on purpose, such as a wrong port, a wrong name or a stopped server, and check that your commands name the right layer. Going back one step, lesson 7 covers WebSockets and server-sent events, which are the long-lived connections that make several of the failure modes above (idle timeouts, resets, proxy buffering) show up more often.