502 Bad Gateway

502 Bad Gateway comes from a proxy — a load balancer, reverse proxy or CDN — that asked an upstream server for the response and got garbage back: a refused connection, a reset, a malformed reply, or nothing usable. The proxy is fine; the thing behind it isn't.

Whenever you see a 502, mentally add the missing words: "I, the proxy, got a bad response from the origin."

Common causes

• The app process is down — crashed, OOM-killed, or mid-restart during a deploy; nginx can't reach the socket and 502s
• Deploys without graceful handoff — old workers killed before new ones listen; the seconds-long gap is a burst of 502s on every release
• Upstream connection limits — backend at max connections refuses new ones
• Wrong upstream config — proxy pointed at a dead port/IP after an infrastructure change
• Response too large for proxy buffers — oversized headers from the backend (nginx upstream sent too big header)
• HTTPS mismatch — proxy speaks plain HTTP to an origin expecting TLS, or can't validate the origin certificate (Cloudflare shows 525/526 for these)
• Keep-alive races — origin closes idle connections a hair before the proxy reuses them; sporadic, low-rate 502s that vanish when keep-alive timeouts are aligned

Debugging

1. Find the failing layer. Hit the origin directly (bypassing the CDN/LB) — if it answers, the problem is between the proxy and origin: security groups, certificates, connection limits.
2. Read the proxy's error log, not the app's — the app may have never received the request. nginx's connect() failed vs upstream prematurely closed distinguish "down" from "crashed mid-response".
3. Correlate with deploys. 502 bursts aligned with releases mean the rollout isn't graceful — fix the handoff, don't tune the proxy.

A multi-region HTTP monitor timestamps every 502 precisely, which makes the deploy correlation obvious, and confirmed alerting separates a one-request blip from a dead backend. If only one region sees 502s, suspect the CDN PoP, not your origin.