HTTP 502 — Bad Gateway

What 502 actually means

Your request reached a server acting as an intermediary — a CDN, load balancer, or reverse proxy such as Nginx — and that intermediary could not get a usable answer out of the machine actually running the site. The front door is working; the thing behind it is not. Because the proxy is healthy enough to generate an error page, a 502 almost always means the application process has crashed, is still starting up, or is not listening where the proxy expects it to be.

Common causes

• The application process crashed or was killed, often by the out-of-memory killer
• The app is listening on a different port or socket than the proxy configuration points at
• The upstream returned a malformed response the proxy could not parse
• A PHP-FPM pool with no free workers, so connections are refused
• A firewall or security group blocking traffic from the proxy to the application
• DNS for the upstream host failing or resolving to a stale address
• The application restarting during a deploy, with no connection draining

If you're just trying to view the page

1. Wait a minute and reload — deploys and restarts produce short bursts of 502s that clear by themselves
2. Hard refresh (Ctrl+F5 or ⌘ + Shift + R) in case a broken response was cached
3. Check the site's status page or Downdetector to confirm it is not just you
4. Nothing else — this is entirely a server-side fault

If it's your site

1. Confirm the application process is actually running, and read its log for the crash that preceded the 502
2. Check the proxy's error log for the specific reason — Nginx will say "connect() failed (111: Connection refused)" or "upstream prematurely closed connection", and those point at different problems
3. Verify the upstream host and port in the proxy config match where the app is bound; binding to 127.0.0.1 when the proxy is on another host is a classic
4. Look for OOM kills in `dmesg` or `journalctl -k`; a memory leak shows up as periodic 502s
5. For PHP-FPM, check `pm.max_children` and the slow log — an exhausted pool refuses connections
6. Increase `proxy_read_timeout` only if the upstream is slow rather than dead; otherwise you are hiding a 504
7. Use health checks and connection draining so deploys do not drop in-flight requests

Reference

Status code

502

Reason phrase

Bad Gateway

Category

5xx — Server Error

Cacheable by default

No

Defined in

RFC 9110 §15.6.3