502 Bad Gateway
A server acting as a gateway or proxy received an invalid response from the upstream server it needed to fulfill the request.
Defined in RFC 9110 §15.6.3
What 502 means
HTTP 502 Bad Gateway means a server acting as a gateway or reverse proxy, such as nginx, an AWS Application Load Balancer, or Cloudflare's edge, successfully received the client's request but got an invalid, malformed, or empty response from the upstream server it forwarded that request to. Per RFC 9110, this is explicitly a problem between two servers, not between the client and the front-facing one: the proxy did its job correctly, but the backend it depends on did not answer properly. That distinction matters for debugging, since the fix almost never lives in the client and almost always lives in the upstream application or the network path to it.
Reverse proxies are the most common place to see 502s in production. nginx returns 502 when its upstream block cannot get a valid HTTP response from the application server it proxies to; an AWS ALB returns 502 when a target fails the health check contract mid-response or closes the connection unexpectedly; Cloudflare returns 502 when the origin server it is protecting fails to respond correctly to Cloudflare's edge. In every case, the proxy layer is a messenger reporting that the next hop in the chain misbehaved, so log correlation has to span both the proxy and the origin to find the real fault.
A large share of 502s trace back to the upstream process crashing, restarting, or being killed by the process manager, such as PM2, systemd, or a container orchestrator, while a request was in flight, which severs the connection the proxy was waiting on. Another frequent cause is a proxy configured to forward to the wrong upstream port or a stale IP address, especially after a deployment changes which port the application binds to or a container gets a new internal IP; the proxy then either connects to nothing or to a process that cannot speak HTTP, and returns 502 to the client rather than hanging indefinitely.
Cloudflare in particular generates several flavors of 502 that map to specific origin problems: error 521 means the origin refused the connection entirely, 522 means the connection timed out, and a plain 502 usually means the origin returned a response Cloudflare could not parse, such as a truncated body or invalid headers. Because Cloudflare sits in front of the real origin, its 502 page can mask what the origin actually sent, so operators need to bypass the proxy, for example by curling the origin IP directly or checking Cloudflare's own diagnostic logs, to see the raw upstream response instead of only the edge's summary.
Common causes
- The upstream application process crashed, was killed by the process manager, or restarted mid-request, dropping the connection the proxy was waiting on.
- The reverse proxy is configured to forward to the wrong upstream host or port, often after a deploy changes which port the app binds to.
- The upstream server returned a malformed, truncated, or non-HTTP response that the proxy could not parse.
- A container or backend instance was replaced, whether by a new deploy, autoscaling, or an orchestrator reschedule, and the proxy's upstream registry still points at a dead IP.
- The origin's TLS certificate is invalid or expired, causing the proxy, including Cloudflare, to refuse to trust the upstream handshake.
- The upstream server hit its own resource limits, such as running out of memory or open file descriptors, and stopped accepting new connections.
How to fix a 502
If you are the client (browser user or API caller)
- Retry the request after a brief delay, since 502s are frequently transient and resolve once the upstream process recovers.
- Use exponential backoff rather than immediate retries so repeated requests do not add load to an already-struggling upstream.
- Check the target site's or API's public status page for an ongoing incident before assuming the problem is local.
- If the 502 is intermittent, capture timestamps and any trace or request ID headers so the operator can correlate it with their proxy and origin logs.
- For CDN-fronted sites, note whether the error page is the CDN's own branded page versus a generic 502, since that narrows down whether the issue is the connection or the response itself.
If you run the server
- Check the reverse proxy's upstream or target configuration, such as an nginx upstream block, an ALB target group, or Cloudflare origin rules, to confirm it points at the correct current host and port.
- Monitor the upstream application process and configure the process manager or orchestrator to restart it automatically and register readiness only after it can accept connections.
- Increase the upstream's resource limits or connection pool size if it is failing under load, and check for memory leaks or file descriptor exhaustion in application logs.
- Validate the origin's TLS certificate chain and renewal automation so the proxy's handshake to the upstream never fails silently.
- During deploys, use a rolling or blue-green strategy so the proxy always has a healthy upstream target instead of a window where the old one is gone and the new one is not ready.
Example
GET /checkout HTTP/1.1
Host: shop.example.com
HTTP/1.1 502 Bad Gateway
Content-Type: text/html
Server: nginx
<html><body><h1>502 Bad Gateway</h1></body></html>Try it live
Our free status responder returns a real HTTP 502 you can point tests, monitors or a browser at.
GET https://mcp.httpstatus.com/status/502