In modern web infrastructure, requests travel through reverse proxies, load balancers, and API gateways before reaching backend application services.

When communication breaks down between the proxy and the upstream service, the proxy generates either an HTTP 502 Bad Gateway or an HTTP 504 Gateway Timeout response.

Core distinction: response integrity versus timing

The distinction lies in response integrity versus response timing:

  • HTTP 502 Bad Gateway: The proxy received a response from the upstream server, but the response was invalid, corrupted, or abruptly closed (e.g., the backend crashed mid-request).
  • HTTP 504 Gateway Timeout: The proxy received no response at all before its configured timeout deadline expired (e.g., a query took longer than the 30-second proxy limit).

What HTTP 502 means

An HTTP 502 Bad Gateway response indicates that the server, while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request.

Common reasons for a 502 response include:

  • Backend application process crashing or throwing a fatal exception during request handling.
  • TCP connection reset by the upstream service before sending complete HTTP headers.
  • Upstream server emitting headers that exceed proxy buffer limits.
  • TLS handshake or protocol negotiation failure between proxy and upstream.
HTTP/1.1 502 Bad Gateway
Date: Thu, 10 Sep 2026 10:00:00 GMT
Content-Type: application/json
Via: 1.1 gateway.example.test

{"error": "bad_gateway", "message": "Upstream server terminated the connection unexpectedly."}

What HTTP 504 means

An HTTP 504 Gateway Timeout response indicates that the server, while acting as a gateway or proxy, did not receive a timely response from an upstream server.

Common reasons for a 504 response include:

  • Long-running database queries without proper indexing.
  • Upstream worker thread exhaustion causing incoming requests to sit in a queue.
  • Unresponsive downstream external APIs that block synchronous execution.
  • Heavy computational tasks that exceed the proxy read-timeout setting.
HTTP/1.1 504 Gateway Timeout
Date: Thu, 10 Sep 2026 10:00:00 GMT
Content-Type: application/json
Via: 1.1 gateway.example.test

{"error": "gateway_timeout", "message": "Upstream server failed to respond within 30 seconds."}

Invalid upstream response vs. no timely upstream response

The key architectural difference is how the proxy terminates the communication:

  1. In 502 Bad Gateway: The proxy receives an immediate or mid-stream signal from the upstream socket indicating an error (such as a TCP RST, an empty reply, or corrupted HTTP bytes).
  2. In 504 Gateway Timeout: The proxy maintains an active timer. The upstream socket remains open, but silent. When the timer reaches zero, the proxy forcibly cuts the connection.

Practical comparison table

Dimension HTTP 502 Bad Gateway HTTP 504 Gateway Timeout
Failure Mode Invalid or terminated response Deadline / timeout expiration
Upstream State Process crashed, killed, or returned bad data Process is running slowly or hanging
Duration Before Error Can happen in milliseconds Equals the proxy timeout duration (e.g. 30s/60s)
Origin Node Intermediary Gateway / Reverse Proxy Intermediary Gateway / Reverse Proxy
Primary Remediation Fix backend crashes and unhandled exceptions Optimize slow queries or switch to async jobs

What to check before changing code

  1. Inspect proxy error logs: Does the log state connection reset by peer (502) or upstream timed out (504)?
  2. Review execution duration: Did the request fail instantly (502) or take exactly 30/60 seconds (504)?
  3. Check application crash dumps: Look for out-of-memory (OOM) kills or segmentation faults on the backend service.
  4. Profile database performance: Use query profiling to locate long-running joins and unindexed table scans.

Key takeaway

HTTP 502 Bad Gateway means the upstream server failed to produce a valid HTTP response. HTTP 504 Gateway Timeout means the upstream server took too long to respond. Use proxy logs and response timings to identify whether you are debugging a crash (502) or a latency bottleneck (504).