Packet Flow for a Web Request: Following the Path to Find the Break

What “packet flow” means for a web request

When someone reports “the site is down,” you can avoid guesswork by tracing the request as a sequence of dependent steps. Each step has a small set of observable signals (client output, packet captures, logs) and a small set of common failure modes. Your goal is to identify the first step that fails, then focus troubleshooting there.

A complete web request path typically looks like this: (1) DNS resolution returns an IP, (2) packets route to that IP and back, (3) TCP establishes a session, (4) TLS negotiates encryption (for HTTPS), (5) HTTP request is processed and an HTTP response returns. You will walk this path with checkpoints you can verify in order.

Guided walkthrough: trace a request end-to-end with checkpoints

Checkpoint 0: Define the target and expected behavior

Before capturing packets, write down what “working” means so you can detect partial failures. Identify: the hostname (e.g., www.example.com), the scheme (https vs http), the expected port (443 vs 80), and whether a CDN/WAF/load balancer is expected in front. Also note whether the report is from one user/network or many.

• Expected URL: https://www.example.com/
• Expected port: 443
• Expected IP ownership: CDN? cloud load balancer? direct origin?
• Scope: single client vs multiple regions/ISPs

Checkpoint 1: DNS resolution (name → IP)

At this checkpoint you are verifying that the client can obtain the correct IP address for the hostname, and that the answer is plausible for the environment (CDN anycast IPs, load balancer VIPs, etc.).

What to do (client-side):

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

• Query DNS explicitly and compare results from multiple resolvers.
• Confirm you are querying the intended record type (A/AAAA) and that the returned TTL and IPs look expected.

# Query using the system resolver (quick check)
nslookup www.example.com

dig www.example.com A +noall +answer
dig www.example.com AAAA +noall +answer

# Compare with a known public resolver
dig @1.1.1.1 www.example.com A +noall +answer
dig @8.8.8.8 www.example.com A +noall +answer

What to look for (signals):

• NXDOMAIN: the name does not exist (or you are querying the wrong zone/hostname).
• No answer / SERVFAIL: resolver cannot complete recursion or DNSSEC validation, or upstream is failing.
• Wrong IP: stale cache, incorrect record, wrong environment (prod vs staging), or unexpected CDN mapping.
• Only AAAA fails: IPv6 path issues can appear as “site down” for IPv6-preferred clients.

Packet view (if capturing): you should see UDP/53 (or TCP/53 for large responses/DNSSEC) queries and responses. If you see repeated queries with no responses, suspect local firewall, resolver reachability, or upstream DNS outage.

Checkpoint 2: Routing and reachability (IP path exists)

Once you have an IP, verify that packets can reach it and return. This is not “does the app work,” it is “can we exchange packets with the destination network.”

What to do:

• Test basic reachability with ICMP where allowed (some CDNs and firewalls drop ICMP; lack of ping is not definitive).
• Trace the path to see where packets stop (use TCP-based traceroute if ICMP is filtered).
• Verify the client has a valid default route and that the next hop is reachable.

# Basic reachability (may be blocked by policy)
ping -c 3 203.0.113.10

traceroute 203.0.113.10

# TCP-based traceroute can be more representative for web traffic
traceroute -T -p 443 203.0.113.10

# Quick route check (Linux)
ip route get 203.0.113.10

What to look for:

• Timeouts early in traceroute: local network, gateway, or ISP issue.
• Timeouts near destination: destination network filtering, DDoS mitigation, or upstream routing issue.
• Asymmetric routing symptoms: SYN leaves but SYN-ACK never returns; often shows as TCP timeout even though the server is up.

Packet view: if you capture on the client, you may see outbound packets but no replies. If you capture on the server side (or load balancer), you might see inbound SYNs but no outbound responses (or responses leaving a different interface/path).

Checkpoint 3: TCP handshake (session establishment)

For HTTP(S), the client must establish TCP to the destination IP and port. The handshake is SYN → SYN-ACK → ACK. If this fails, the application never gets a chance.

What to do:

• Attempt a TCP connect to the target port.
• Observe whether it connects, times out, or is actively refused/reset.

# Test TCP connectivity (Linux/macOS)
nc -vz www.example.com 443
nc -vz www.example.com 80

# More verbose timing and handshake details
curl -v --connect-timeout 5 https://www.example.com/

What to look for:

• Timeout: SYN sent, no SYN-ACK received. Common causes: security group/firewall drop, routing return-path issue, service not listening behind a load balancer, DDoS mitigation, or upstream ACLs.
• Connection refused: destination sends RST immediately. Common causes: nothing listening on that port, wrong IP, wrong port, or a firewall actively rejecting.
• Immediate reset after handshake: middlebox or server closes quickly; can indicate policy blocks, proxy requirements, or application-level rejection that manifests as TCP reset.

Packet view: in a capture you should see SYN, SYN-ACK, ACK. Repeated SYN retransmissions indicate a timeout. A RST in response to SYN indicates refusal.

Checkpoint 4: TLS negotiation (HTTPS encryption and identity)

If TCP connects on 443, the next dependency is TLS. TLS failures often look like “site down” to users, but they are distinct from routing or TCP problems. Here you verify that the server presents a valid certificate for the hostname and that negotiation completes.

What to do:

• Use a TLS client to inspect the certificate chain, SNI behavior, and negotiated protocol/cipher.
• Confirm the certificate matches the hostname and is not expired.

# Inspect TLS handshake and certificate chain
openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts

# See what curl reports during TLS
curl -vk https://www.example.com/

What to look for:

• Certificate name mismatch: wrong certificate presented (often missing/incorrect SNI on the server or misconfigured listener).
• Expired certificate: client errors immediately; browsers show a certificate warning.
• Unknown CA / incomplete chain: intermediate cert missing; some clients fail while others succeed depending on cached intermediates.
• TLS alert / handshake failure: protocol/cipher mismatch, TLS inspection device, or server misconfiguration.

Packet view: you should see ClientHello and ServerHello/Certificate messages. If the server sends an alert and closes, you’ll see a TLS Alert followed by FIN/RST.

Checkpoint 5: HTTP request/response (application behavior)

Once TLS is established (or for plain HTTP on port 80), the client sends an HTTP request and expects an HTTP response. Here you distinguish “network path is fine” from “backend is unhealthy,” and you interpret status codes and proxy errors.

What to do:

• Send a simple request and capture headers, status code, and timing.
• Test a known static path (e.g., /health or a small asset) to separate app logic from connectivity.

# Show request/response headers and status
curl -v https://www.example.com/

# Capture timing breakdown (DNS, connect, TLS, TTFB)
curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://www.example.com/

# Force Host header to test a specific IP (useful behind CDNs/LBs)
curl -v --resolve www.example.com:443:203.0.113.10 https://www.example.com/

What to look for:

• 200/301/302: request succeeded (or redirected). If users still report issues, it may be content-specific, auth-related, or regional.
• 4xx: client-side or policy issue (auth, WAF block, missing resource). Not typically “network down,” but can be perceived as outage.
• 502 Bad Gateway: proxy/load balancer could not get a valid response from upstream (backend down, wrong upstream port, upstream resets, misconfigured target group).
• 504 Gateway Timeout: proxy/load balancer waited too long for upstream (backend overloaded, slow DB, network path between proxy and backend, health checks passing but requests timing out).

Packet view: for HTTP/1.1 you can read the request/response in plaintext on port 80, and encrypted on 443 unless you decrypt. Even without decryption, you can still correlate timing and connection reuse patterns.

Where it can fail: symptoms → likely causes mapping

DNS symptoms

• NXDOMAIN: wrong hostname, missing record, wrong zone delegation, typo, or querying a split-horizon view that lacks the record.
• SERVFAIL: resolver cannot reach authoritative servers, DNSSEC validation failure, or upstream outage.
• Intermittent resolution: multiple authoritative servers with inconsistent data, packet loss to DNS, or caching differences across resolvers.

Routing/reachability symptoms

• Timeout (no response) to TCP connect: firewall/security group drop, return-path routing issue, upstream ACL, DDoS mitigation, or destination blackhole.
• Works from some networks but not others: ISP routing issue, geo-based blocking, anycast/CDN edge problem, or MTU/PMTUD issues on certain paths.

TCP symptoms

• Connection refused: service not listening, wrong port, wrong IP, or firewall actively rejecting.
• Reset during/after handshake: middlebox interference, proxy requirement, server overload causing aborts, or policy enforcement.
• Very slow connect: packet loss causing retransmissions, SYN cookies under load, or path congestion.

TLS symptoms

• Certificate error (expired): certificate renewal failure or deployment missed some endpoints.
• Certificate name mismatch: wrong certificate bound to listener, missing SNI configuration, or connecting to the wrong IP/edge.
• Handshake failure: incompatible TLS versions/ciphers, TLS inspection device, or misconfigured server chain.

HTTP/proxy symptoms

• 502: upstream not reachable from proxy, upstream resets, wrong upstream protocol/port, unhealthy targets, or misconfigured routing rules.
• 504: upstream slow/unresponsive, backend saturation, long-running requests exceeding proxy timeouts, or network issues between proxy and backend.
• Blank page / partial content: mixed content blocked, large asset timeouts, CDN cache issues, or specific path failing while root works.

Repeatable packet-flow worksheet for any “site down” report

Use this worksheet as a consistent runbook. Fill it out in order; stop at the first failing checkpoint. The key is to record observable facts (outputs, timestamps, IPs) so you can hand off cleanly or compare across environments.

1) Intake

• Reported URL(s):
• Reporter location/network (ISP/VPN/corporate):
• Time observed (with timezone):
• Is it all users or some users?
• Is it all pages or a specific path?

2) DNS checkpoint

• Hostname queried:
• A record result(s) + TTL:
• AAAA record result(s) + TTL:
• Resolver used (system / 1.1.1.1 / 8.8.8.8 / corporate):
• Outcome: OK / NXDOMAIN / SERVFAIL / No answer
• Notes (unexpected IP? inconsistent answers?):

3) Routing/reachability checkpoint

• Target IP chosen for test:
• traceroute last responding hop:
• Any evidence of asymmetric routing (seen on server side but not client side)?
• Outcome: OK / Suspect path issue / Unclear (ICMP filtered)

4) TCP checkpoint

• Port tested: 443 and/or 80
• Result: Connected / Timed out / Refused / Reset
• If timed out: do you see SYN retransmits in capture?
• If refused/reset: source of RST (server IP vs intermediate device if known):

5) TLS checkpoint (if HTTPS)

• SNI used: yes/no (should be yes for name-based hosting)
• Certificate CN/SAN matches hostname: yes/no
• Certificate expiry date:
• Chain complete and trusted: yes/no
• Negotiated TLS version:
• Outcome: OK / Name mismatch / Expired / Chain issue / Handshake failure

6) HTTP checkpoint

• Request method/path tested:
• Status code:
• Response headers that identify edge/proxy (if present):
• Timing (dns/connect/tls/ttfb/total):
• Outcome: OK / 4xx / 502 / 504 / Other:

7) Minimal evidence bundle (for escalation)

• dig outputs (A/AAAA) from at least two resolvers
• curl -v output including timing line
• One packet capture snippet or summary: SYN retransmits? TLS alert? RST?
• Exact IP tested and timestamp

Practical walkthrough example: isolate the first failing checkpoint

Use this sequence when you are on a client machine (or a troubleshooting VM) and need a fast, repeatable path trace.

Step 1: Resolve and pick an IP

dig www.example.com A +short
dig www.example.com AAAA +short

• If A/AAAA returns nothing or errors, stop and fix DNS before continuing.
• If multiple IPs return (CDN/LB), pick one IP to test and record it.

Step 2: Test TCP connect to the chosen IP and hostname

# Test by name (uses DNS result and SNI automatically in many tools)
curl -v --connect-timeout 5 https://www.example.com/

# Test a specific IP while keeping the Host/SNI correct
curl -v --connect-timeout 5 --resolve www.example.com:443:203.0.113.10 https://www.example.com/

• If connect times out, focus on routing/firewall/return path.
• If connect succeeds but TLS fails, focus on certificate/SNI/chain.
• If TLS succeeds but you get 502/504, focus on proxy-to-backend and backend health/performance.

Step 3: If needed, confirm TLS details directly

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

• If the certificate differs from expectations, you may be hitting the wrong edge, wrong listener, or missing SNI configuration.

Step 4: If HTTP is failing, separate edge vs origin (when applicable)

If you have an origin IP or an internal endpoint, test it directly (from an allowed network) to determine whether the edge is failing or the backend is failing. Keep the Host header consistent so the application routes correctly.

# Example: test origin while preserving hostname routing
curl -v --resolve www.example.com:443:198.51.100.20 https://www.example.com/health