http-debugginglisted

# HTTP Debugging Work out which hop generated the response, then what it was reacting to. ## Purpose **Use this when:** - A request returns 502, 503, 504, 499, 413, 431, or an unexpected redirect. - Requests work directly against the backend but fail through the proxy. - Requests fail intermittently at a regular interval. - Latency is high with no errors, or a response is truncated. **Do not use this when:** - The name does not resolve — use `dns-troubleshooting`. - The TLS handshake fails — use `tls-debugging`. A handshake failure never produces an HTTP status. - The problem is Kubernetes Service or endpoint routing — use `kubernetes-networking`. **What this skill assumes:** `curl`, and ideally access to the proxy's access log. The access log is the authority on what the proxy did; client-side evidence alone is often ambiguous. ## Operating Procedure 1. **Identify which hop answered.** A 502 from your CDN and a 502 from your ingress are different incidents. Response headers usually name the responder. 2. **Reproduce with `curl`**, with timings. The timing breakdown localises the phase immediately. 3. **Bypass hops one at a time.** Client → CDN → load balancer → ingress → service → pod. Test directly against each and find where behaviour changes. 4. **Read the status code for what it actually means**, not for what it is commonly assumed to mean. 5. **Check both ends of any timeout or keepalive pair.** Most intermittent HTTP failures are a mismatch between tw