What is 502 Bad Gateway?
Definition
502 Bad Gateway is the HTTP status code a server returns when, acting as a gateway or proxy, it receives an invalid response from the upstream server it contacted to fulfil the request. The error is usually generated by an intermediary such as Nginx, a CDN or a load balancer, while the real fault typically lies with an application server that is down, restarting or listening on the wrong address.
Also known as: HTTP 502, 502 error, bad gateway error, 502 proxy error
Who sends it, and who is actually broken
On most production sites a request never travels straight from the browser to the application. It usually passes through a CDN, then a reverse proxy such as Nginx, and only then reaches an application process: Node.js, PHP-FPM, a Python worker. The 502 is produced by an intermediary in that chain. In the words of RFC 9110, the gateway received an invalid response from the server behind it.
That distinction drives the whole investigation. If you see a 502, the proxy or CDN is most likely fine; the layer behind it is the one that failed to answer properly. Find out which hop produced the error before you start reading application code.
Typical causes
- The app process is not running: it crashed, was killed by the out-of-memory killer, or is restarting during a deploy.
- Wrong upstream target: the port or Unix socket in the proxy config does not match where the app actually listens.
- The connection closes early: the app drops the connection before sending a complete response header.
- Malformed or oversized headers: cookies or headers larger than the proxy's buffers allow.
- CDN cannot talk to the origin: a firewall blocks the CDN's IP ranges, or the TLS settings on each side disagree.
The Nginx error log is usually explicit about which of these happened:
connect() failed (111: Connection refused) while connecting to upstream
upstream prematurely closed connection while reading response header from upstream
upstream sent too big header while reading response header from upstream500 vs 502 vs 504
A 500 is the application itself reporting that something went wrong. With a 502 the application either never answered or answered with something the proxy could not use. A 504 Gateway Timeout means the proxy reached the upstream but gave up waiting before a response arrived. Put simply: 502 is "broken or missing answer", 504 is "answer too late".
A debugging order that works
- Identify which hop produced the page. Cloudflare wraps a 502 coming from your origin in its own branded error page; a plain, unbranded page points to a problem on Cloudflare's side.
- Read the proxy's error log around the timestamp.
- Check the app process status and when it last restarted. Did the errors start with a deploy?
- Bypass the proxy and hit the app directly:
curl -I http://127.0.0.1:3000/
Short bursts of 502s during deploys disappear once traffic is switched only after the new version passes a health check; blue-green deployment formalises that. On the security side, make sure your error page does not reveal internal IP addresses, server versions or stack traces.
How search engines react
Google handles a 502 like any other 5xx response: it ignores whatever content came with it and temporarily slows down crawling of the site. Indexed URLs are kept for a while, but URLs that keep failing are eventually removed from the index. A few minutes of downtime leaves no trace; a 502 that lasts for days, or returns every night during a batch job, costs visitors and crawling alike. Google documents this in its HTTP status code reference.