How to Fix 502 Bad Gateway (7 Proven Solutions)
The reverse proxy got nothing valid back. Here's where to look.
A 502 Bad Gateway means your reverse proxy can't reach the upstream server. Work through these 7 fixes from most to least common.
What a 502 actually means
A 502 Bad Gateway is returned by a reverse proxy (Nginx, Apache, a CDN, a load balancer) when it forwards a request to an upstream server and gets an invalid or no response. The proxy is fine; the thing behind it isn't. Your job is to find the break between the proxy and the origin.
Unlike a 500 (the origin app threw an error), a 502 usually means the origin didn't respond at all, crashed mid-response, or returned something the proxy couldn't parse. The fix depends on which of those happened, so work the list below in order — the common causes come first.
Fix 1-3: upstream service, restart, firewall
First, check whether the upstream service is running. SSH in and run `systemctl status` (or your process manager's equivalent) on the app server, PHP-FPM, Node process, or whatever sits behind the proxy. A crashed or OOM-killed process is the most common cause. If it's down, start it and check the logs for why it died.
Second, restart the service even if it appears up. A hung process that's accepting connections but not responding will produce 502s and won't show as failed in a status check. A restart clears the hang; the logs will tell you what caused it. Third, check the firewall on the origin — a rule change (often from an automated security tool or a cloud provider's network policy) can block the proxy's IP from reaching the upstream port.
Fix 4-7: DNS, PHP limits, timeouts, proxy config
Fourth, check DNS. If the proxy resolves the upstream by hostname and that DNS record changed or expired, the proxy is trying to reach the wrong IP. Verify the upstream hostname resolves correctly from the proxy host. Fifth, for PHP stacks, check PHP-FPM limits: `pm.max_children` being exhausted returns 502s under load because FPM has no free workers. Raise the limit or fix the memory leak driving it.
Sixth, check proxy timeouts. Nginx's `proxy_read_timeout` defaults to 60s; if your origin takes longer, Nginx returns 502. Raise the timeout or speed up the origin. Seventh, review the proxy's upstream config — wrong port, wrong protocol (HTTP vs HTTPS), or a `proxy_pass` pointing at a stale socket file. SurePing's HTTP monitoring will catch 502s the moment they start; set up an alert so you know before your users do.