Troubleshooting Lab: The Site That Never Loads

Read the evidence. Name the culprit.

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

▸Analyse a failing connection using only its packet capture
▸Distinguish silent drops from refusals, latency, and DNS problems by their signatures
▸Read retransmission timing to reconstruct what the client experienced

Before this lesson — it builds directly on:

When someone says 'the site is down', there are a dozen plausible causes and arguing about them wastes hours. A packet capture ends the argument, because TCP's failure modes have distinct, recognisable shapes. A blocked path looks different from a closed port, which looks different from a slow server, which looks different from a broken application. Learning those shapes converts a debate into a lookup.

✗ Common misunderstanding: A successful three-way handshake means the application is up and ready.

Why that's wrong: The handshake is completed by the operating system's TCP stack. A listening socket can be accepted by the kernel while the application behind it is hung, still starting, or broken.

Correct model: The handshake proves a socket is listening and the path works in both directions — nothing about application health.

The packets prove it: The handshake trace reaches ESTABLISHED with zero application bytes exchanged; the server's process is never consulted.

Watch these fields in the lab: tcp.flags.syn · tcp.flags.rst

A doctor's differential diagnosis, ruling things out rather than in

a test coming back negative: → a packet that should be there and is not
narrowing to one cause by elimination: → the deepest layer that succeeded
a symptom that fits several conditions: → "the site does not load"

Where it breaks down: A doctor can order a new test. You have the capture you have — and if the evidence you need was not recorded, the honest answer is to capture again at a different point rather than to reason further from what is missing.

1SYN, then total silence, retried at doubling intervals — the packets are being discarded without notification. Almost always a firewall or security group configured to DROP. The give-away is that no error of any kind comes back.
2SYN answered immediately by RST — the host is alive and reachable; nothing is listening on that port. The service is down or bound to a different address. This fails in milliseconds, not seconds.
3Handshake completes, then nothing — the network is fine and proven fine. The problem is the application: hung, still starting, or waiting on something else. Stop looking at the network.
4Handshake completes, data flows, then a mid-stream RST — someone aborted deliberately: an application error, a proxy idle timeout, or an inline device. Check the RST's TTL against the peer's normal traffic to see whether it even came from the peer.

Watch these fields in the lab: tcp.flags.syn · tcp.flags.rst

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

Which single observation most cleanly separates 'a firewall is dropping traffic' from 'nothing is listening on that port'?

A capture shows the three-way handshake completing normally, then thirty seconds of silence before the client gives up. What have you already ruled out?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.