2026-06-02

HTTP 502 vs 504: PCAP Gateway Timeout Analysis

Use packet captures to separate HTTP 502 Bad Gateway from 504 Gateway Timeout: trace client, proxy, and upstream TCP, TLS, request timing, resets, and timeout policy.

An HTTP 502 Bad Gateway or 504 Gateway Timeout tells you that a proxy, gateway, CDN edge, or load balancer returned an error to the client. It does not by itself prove that the client network failed, that the origin was down, or that the application was slow. Those status codes are the visible end of a multi-hop conversation. The useful question is: what did the proxy observe on its upstream connection before it produced the response?

A packet capture can answer many parts of that question when it covers the relevant leg: TCP connect timing, TLS negotiation, SNI, request transmission, response bytes, retransmissions, FIN/RST, window pressure, and the elapsed interval before the gateway gave up. It cannot see an application queue, database lock, or load-balancer health decision that never reaches the wire. A good diagnosis keeps that boundary explicit.

PCAP Surgery is designed for keeping the narrow, time-aligned evidence needed for this work: define the capture scope, isolate the failing flow, retain the relevant packets and timing, then export a reviewable case rather than a vague status-code screenshot.

502 and 504 answer different questions

The two codes are often grouped together as “gateway errors,” but the evidence pattern should be different.

Status observed by client	What it normally means	Packet evidence to look for	What it does not prove
`502 Bad Gateway`	Gateway received an invalid, incomplete, or failed upstream exchange	Upstream RST/FIN, TLS failure, malformed response, no viable upstream	That the browser-to-proxy path failed
`504 Gateway Timeout`	Gateway waited for an upstream result longer than policy allowed	Request sent, no complete upstream response before deadline	That the origin application itself is definitely slow
`499` or client disconnect (where logged)	Client ended its side while gateway was working	Downstream FIN/RST before gateway response	Why the client abandoned the request
`503 Service Unavailable`	Service or proxy policy refused/has no capacity	Health/routing evidence plus any upstream attempt	A packet-level root cause on its own

Vendors can customize behavior, so treat the table as a hypothesis guide rather than a universal decoder. The HTTP response headers, proxy logs, and capture position are part of the interpretation. The important discipline is not to infer the upstream story from the downstream status alone.

Draw the request path before opening Wireshark

Write the path in the case notes first:

Client → CDN or edge → reverse proxy / load balancer → upstream service → dependencies

Then state where each capture was taken. A client-side capture can show the final 502 or 504, DNS result, and client-to-edge TCP/TLS exchange. A proxy upstream-interface capture can show whether it connected to the origin and what returned. A capture on the application host adds another independent observation point. These are not interchangeable.

The best incident evidence usually includes both sides of the proxy when policy permits:

client-facing interface on the proxy or load balancer;
upstream-facing interface on the same proxy;
upstream host capture for disputed or intermittent failures.

If only the client-side leg is available, write the conclusion narrowly: “the gateway returned a 504 at this time.” Do not state “the upstream never responded” unless you observed the upstream connection or have corroborating server evidence.

Use the capture-scope guide before collecting traffic. A capture that omits the proxy’s upstream NIC may be perfectly valid for client-experience analysis but insufficient for a root-cause claim.

Establish a timeline, not a pile of packets

Every gateway-timeout investigation should start with a simple timeline. For HTTPS upstreams, the phases are usually DNS or routing context, TCP handshake, TLS handshake, HTTP request bytes, first response byte, completed response, and gateway error. For HTTP/2 or HTTP/3, stream-level interpretation is needed as well, but the same high-level chronology still applies.

Timeline event	What to record	Interpretation risk
Client request reaches gateway	Time, request correlation ID if visible, downstream 5-tuple	Do not assume this identifies the upstream flow
Gateway opens upstream connection	SYN, SYN-ACK, ACK timing and endpoint	Connection reuse may mean no new SYN
TLS begins	ClientHello/SNI, ServerHello, alerts, certificate path if decrypted/visible	Encrypted payload does not make TCP timing invisible
Request is sent upstream	First application bytes or proxy trace correlation	One capture leg may be missing payload visibility
Upstream begins response	First byte and response progress	First byte is not a completed response
Gateway returns error	Exact downstream `502`/`504` time	It may be governed by an independent timeout policy

Keep clock alignment in mind when comparing hosts. If the proxy and origin clocks are not synchronized, packet timestamps can appear to put the response before the request. That is a measurement problem, not necessarily a protocol anomaly. Retain capture metadata and note the time basis in the case.

Step-by-step: diagnose an HTTP 502 with a packet capture

A 502 is often associated with an upstream connection that failed, closed early, spoke an unexpected protocol, or returned something the proxy rejected. Work through the observed upstream flow in order.

1. Confirm the downstream error and the responding layer

Record the HTTP status, response headers, server identifier if exposed, and the exact time. This establishes which layer produced the final answer. A 502 from an edge CDN and a 502 generated by an internal reverse proxy are different traces to follow.

2. Find or correlate the upstream flow

At the proxy, identify the connection from proxy source address/port to upstream destination/port. Connection reuse can complicate this: a failing request may share a long-lived upstream TCP/TLS connection with other requests. Use a proxy request ID, stream timing, or log correlation where possible; do not correlate based only on matching wall-clock seconds.

3. Check TCP before HTTP semantics

Did the proxy receive a SYN-ACK? Did the upstream reset immediately? Are there repeated SYN retransmissions? A failed TCP connect can be translated into a 502 even though no HTTP request ever reached the application. If a handshake succeeds, look for reset, FIN, retransmissions, zero window, or unexpected endpoint changes before assuming a bad HTTP response.

4. Check TLS when the upstream uses HTTPS

For encrypted upstream traffic, verify whether the handshake completed and whether an alert or connection close occurred. A wrong SNI name, protocol/cipher mismatch, expired or untrusted certificate from the proxy’s perspective, or a middlebox reset can result in a gateway error. A capture may show the TLS alert or close but not the certificate-validation policy behind the proxy; state that limitation.

5. Look for an incomplete or rejected response

If the upstream accepted the request and then sent an RST or a partial response, the proxy may generate 502. Preserve the final packets rather than reporting only “reset.” The sequence matters: reset before any application bytes points in a different direction from reset halfway through a response body.

The TCP close-state analysis guide is useful when the failing exchange involves an unexpected FIN/ACK sequence rather than an obvious reset.

Step-by-step: diagnose an HTTP 504 gateway timeout

A 504 needs timing evidence. The gateway believes its upstream operation did not finish before a configured deadline. That might be an application that is slow, an upstream connection stalled in the network, a dependency wait behind the application, an idle timeout, or a deadline set too aggressively for the endpoint.

Identify the exact downstream time at which the gateway returned 504.
Establish when the proxy sent the upstream request, or when the relevant reused connection began carrying the request.
Measure the interval between that request and the gateway error.
Check whether any upstream response bytes arrived before the deadline.
Look for retransmissions, receiver zero window, path MTU symptoms, or a reset/FIN near the deadline.
Check whether the origin later responded after the gateway had already closed the downstream request.
Compare the interval with the configured proxy/read/upstream timeout from configuration or logs.

The classic capture pattern is:

Proxy → Upstream: request transmitted
Upstream → Proxy: no complete response for N seconds
Proxy → Client: HTTP/1.1 504 Gateway Timeout

That pattern supports “the gateway timed out waiting for the observed upstream exchange.” It does not, by itself, identify why the origin was silent. If the upstream process emitted no packets because it was waiting on a database, only application or dependency telemetry can close that part of the case.

Recognize the common packet patterns without overclaiming

Observed pattern	Plausible explanation	Safe next check
SYN retransmissions, no SYN-ACK	Routing, firewall, security group, unavailable host	Upstream reachability and gateway routing
TCP connects; TLS alert or immediate close	TLS name, protocol, trust, or middlebox issue	Proxy TLS configuration and origin TLS logs
Request sent; upstream RST	Process reset, overload protection, protocol error	Origin logs and restart history
Request sent; no response until exact timeout	Slow application, dependency wait, stalled path, too-short policy	App latency plus timeout configuration
Response starts but stalls	Upstream streaming/body delivery issue, flow control, loss	TCP sequence/ack progress and window state
Repeated retransmissions on one leg	Packet loss, asymmetric visibility, overloaded endpoint	Capture from both sides and NIC counters
Small requests fail but health checks succeed	Different route, header, auth, body size, or upstream pool	Compare exact request properties

Avoid turning a plausible explanation into the root cause before you inspect the next source. For example, TCP retransmissions at the proxy do not automatically prove network loss; an overloaded receiver may advertise window pressure or simply fail to service its socket promptly.

Handle encrypted and multiplexed traffic carefully

TLS does not prevent useful timing analysis, but it does restrict payload interpretation. You can often still establish connection reuse, handshake completion, packet timing, response-byte onset, resets, retransmissions, and close behavior. If the request must be correlated to a particular route, use safe application logs or a proxy request ID rather than attempting to infer plaintext that is not visible.

HTTP/2 and HTTP/3 add multiplexing. One TCP connection can carry many HTTP/2 streams; one QUIC connection can carry multiple streams over UDP. A connection-level “healthy” result does not prove the failed stream was healthy. Document the protocol and the available correlation method. If the capture cannot distinguish the affected stream, say so and preserve the precise time window for engineers who can combine it with proxy telemetry.

Preserve evidence that another team can actually use

Large captures are difficult to share and easy to misunderstand. Keep the original under the appropriate retention policy, then create a focused export around the failing exchange: DNS context if relevant, handshake, request/response timing, error generation, and a short margin before and after. Do not rewrite timestamps or discard packets simply because they look unrelated until the correlation is understood.

PCAP Surgery’s overview explains the investigation and export workflow. For cases where timing itself is disputed, the timestamp evidence guide covers why capture timestamps need an explicit chain of custody.

A concise incident conclusion should answer:

Which endpoint returned the observed 502 or 504?
Which network leg was actually captured?
Did TCP and TLS complete on the observed upstream flow?
Was the upstream request sent, and were any response bytes observed?
How long elapsed before the gateway error?
What can be proven from packets, and what still requires logs or telemetry?

FAQ: HTTP 502 and 504 packet analysis

Is a 502 always an upstream server crash?

No. A 502 can follow an upstream reset, failed TLS handshake, wrong protocol/port, malformed or incomplete response, routing failure, or gateway policy. The capture has to show which exchange occurred on the observed leg.

Does a 504 prove the backend is slow?

No. It proves the gateway’s deadline expired for that request path. The backend may be computing slowly, waiting on a dependency, unreachable, blocked on a network path, or simply paired with a timeout policy that is too short. Combine packets with application and proxy telemetry.

Why did the origin return 200 in its logs while the client saw 504?

The origin may have completed after the gateway’s deadline, may have logged a different retry, or may have sent a response that did not reach the proxy. Align request IDs and timestamps before treating the entries as the same transaction.

Can a client-side PCAP alone identify the cause?

It can confirm the client-to-gateway experience and show when the error arrived. It usually cannot prove what happened between the proxy and upstream. Capture or correlate the upstream side for a root-cause claim.

Conclusion: status code first, causal claim last

HTTP 502 and 504 are gateway reports, not diagnoses. The reliable workflow is to map the request path, capture the appropriate leg, build a TCP/TLS/request/response timeline, and state only what the packets establish. That turns “the network caused a timeout” into a reviewable conclusion such as “the proxy sent the observed upstream request, received no response bytes for 30 seconds, and generated 504; origin-side application wait remains to be confirmed.”

Use PCAP Surgery to define the scope, retain the decisive packets, and export an evidence-focused case. If response delay rather than gateway policy is the question, continue with the slow HTTP request and TTFB analysis guide.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: