HTTP 502 and 504 Gateway Timeout PCAP Analysis: Proxy, Load Balancer, Upstream, or Network?

HTTP 502 Bad Gateway and 504 Gateway Timeout errors are proxy-layer symptoms. A browser or API client sees the proxy's response, but the real problem may be between the proxy and upstream server, inside the upstream application, in TLS negotiation, in TCP reachability, or in timeout policy. Users search for "502 pcap analysis", "504 gateway timeout packet capture", "proxy upstream reset", "load balancer timeout Wireshark", and "Bad Gateway network troubleshooting" when logs are not enough.

PCAP Surgery is useful because proxy failures need the packet story on both sides if possible: client-to-proxy and proxy-to-upstream.

What 502 usually means

502 Bad Gateway usually means the proxy received an invalid, incomplete, or failed response from upstream. Causes include:

• Upstream TCP reset.
• Upstream TLS handshake failure.
• Upstream closed connection early.
• Proxy connected to wrong port.
• Backend returned malformed HTTP.
• Load balancer had no healthy upstream.
• Protocol mismatch, such as HTTPS expected but HTTP sent.

The client only sees the proxy's 502. The packet trace can show what happened upstream.

What 504 usually means

504 Gateway Timeout usually means the proxy forwarded the request but did not receive a complete upstream response before its timeout.

Causes include:

• Upstream application slow.
• TCP connection to upstream stalls.
• Server accepts connection but never responds.
• Large response blocked by MTU or packet loss.
• Database or dependency delay behind upstream.
• Proxy timeout too short.
• Firewall or NAT idle timeout.

The key evidence is timing: when the proxy sent the upstream request and when it gave up.

Capture placement

Best evidence comes from:

• Client side: sees final 502/504.
• Proxy side client-facing interface.
• Proxy side upstream-facing interface.
• Upstream server side.

If you capture only at the client, you can prove the proxy returned 502/504 but not why. If you capture at the proxy, you can inspect upstream behavior.

TCP and TLS before HTTP

Before diagnosing HTTP, check:

• Did proxy establish TCP to upstream?
• Did TLS handshake complete?
• Did SNI match upstream expectation?
• Did upstream reset?
• Did packets retransmit?

If TCP or TLS fails, HTTP status may be only the proxy's translation of lower-level failure.

Request sent, no response

For 504, look for:

Proxy -> Upstream: HTTP request
No upstream response for timeout interval
Proxy -> Client: HTTP/1.1 504 Gateway Timeout

If upstream later responds after the proxy timeout, the application is slow or timeout is too short. If upstream never sees the request, routing or proxy-to-upstream path is suspect.

Checklist

Use this workflow:

1. Identify client, proxy, and upstream.
2. Capture both sides of proxy if possible.
3. Confirm final status returned to client.
4. Inspect proxy-to-upstream TCP handshake.
5. Inspect TLS handshake if HTTPS upstream.
6. Check whether upstream request was sent.
7. Check whether upstream sent any response.
8. Look for RST, FIN, retransmission, zero window, or idle timeout.
9. Measure time from upstream request to proxy error.
10. Preserve packet timing when trimming.

Final diagnosis

HTTP 502 and 504 are not root causes. They are proxy reports. Packet evidence can distinguish upstream reset, TLS failure, no healthy backend, slow upstream, network stall, MTU issue, or timeout policy.

PCAP Surgery helps isolate the exact proxy/upstream conversation so the status code can be tied to packet-level behavior.