Chapter 18 — Capstone: diagnose a slow, broken, or unsafe HTTPS request end to end

Scenario

Users in one region report that https://www.example.com/app is slow and occasionally shows an old UI after deployment. Security also reports that a new subdomain is missing expected headers.

Investigation plan

1. Scope:
   affected region, browser, network, time window, URL, account type

2. DNS/routing:
   A/AAAA answers, resolver differences, CDN POP, anycast path

3. Transport/protocol:
   TCP vs QUIC, HTTP/2 vs HTTP/3, packet loss, fallback behavior

4. TLS:
   certificate SAN, chain, expiry, SNI, ALPN, edge certificate inventory

5. HTTP:
   status, redirects, cache headers, Vary, cookies, compression, content type

6. CDN/cache:
   hit/miss, age, surrogate key, purge status, service-worker cache

7. Browser:
   LCP, CLS, INP, render-blocking resources, main-thread long tasks

8. Security:
   HSTS, CSP, CORS, cookie flags, frame policy, referrer policy

9. Fix:
   smallest safe change, rollback path, validation, monitoring, postmortem

The toolbox you've built

Every step in the plan has a tool from this series:

A worked diagnosis

Here's how the scenario resolves when you run the tools in order. (The findings are illustrative, but each one is a pattern this guide has shown for real.)

1. dnsdiff www.example.com
   -> all resolvers agree on the CDN's anycast addresses           NOT DNS

2. httptrace -n 5 https://www.example.com/app   (from the affected region)
   -> dns 3ms, tcp 140ms, tls 150ms, ttfb 900ms, X-Cache: MISS every time
   -> high RTT (140 ms) means the user is far from the POP serving them;
      MISS on every request means the edge isn't caching /app at all

3. curl -sI https://www.example.com/app
   -> Cache-Control: no-store                     on the HTML (fine: personalised)
   -> the HTML references /static/app.js?v=2      (NOT content-hashed)
   -> curl -sI .../static/app.js?v=2  ->  Cache-Control: public, max-age=86400

4. Root cause of "old UI": the deploy changed app.js but kept the query string
   "v=2", so browsers and the CDN served yesterday's file for up to 24 h
   (Chapter 15: version by content hash, not by hand).

5. Root cause of "slow": the region's DNS steering sends users to a distant
   POP; and /app's HTML is uncacheable, so every request pays a full origin
   round trip. Mitigation: enable the nearer POP; cache the static shell and
   fetch the personalised data via an API call.

6. certcheck new.example.com; curl -sI https://new.example.com
   -> certificate fine, but no Strict-Transport-Security or CSP:
      the new subdomain bypasses the edge configuration that adds them.
   -> fix: add headers in the application (Chapter 19's middleware), not only at the edge.

Deliverable

Write a short incident note:

Impact:
Root cause:
Evidence:
Mitigation:
Permanent fix:
How we will detect this next time:

For the worked diagnosis, "how we will detect this next time" might read: a synthetic httptrace probe per region alerting on TTFB p95; a CI check that fails if a static asset URL isn't content-hashed; and a curl -sI check in the deploy pipeline that fails if any public hostname lacks HSTS or CSP.

If you can do this calmly for an unfamiliar URL, you understand the HTTPS lifecycle at a genuinely practical level.