A 502 means "the proxy is fine but the server behind it isn't answering properly." Check whether your application server (PHP-FPM, Node, gunicorn, Puma) is actually running and reachable from the proxy. The #1 cause is an app server that crashed or is…
HTTP 502 Bad Gateway is what a proxy returns when the server behind it gives back a response the proxy can't use — empty, malformed, truncated, or no response at all. It is fundamentally a relay error: the proxy itself is healthy, but the actual application server upstream is broken, unreachable, or speaking the wrong protocol. Modern web stacks are full of proxies (Cloudflare → AWS ALB → Nginx → PHP-FPM), and 502 can come from any layer in that chain failing to talk to the next one.
Persistent 502s cause the same deindexing risk as 500s, often worse because 502 frequently affects an entire site at once (when the origin is down, every page is down). CDN-level 502s during a Googlebot crawl can cause Google to throttle the entire site's crawl rate. A repeated pattern of 502s also lowers Google's confidence in your hosting stack, which affects ranking stability over months.
LemWatch distinguishes between brief, intermittent 502s (usually a deploy or restart, low priority) and sustained 502s (an actual outage, page-immediately). We also correlate 502s across regions so you know whether the issue is your origin, a single CDN PoP, or your registrar.
HTTP 502 was defined in RFC 2616 (1999) and became dramatically more visible with the rise of reverse-proxy architectures in the 2010s. Cloudflare, AWS, and Fastly all return branded 502 pages when origins fail, which is why "Bad Gateway" is now one of the most-recognised errors on the web — users see it whenever a major site's origin briefly drops.
HTTP 502 Bad Gateway means a proxy server (Nginx, Cloudflare, a load balancer) tried to reach the actual application server behind it and got back something invalid — no response, a malformed response, or a connection refused. The proxy itself is fine; the upstream server is the problem.
Three steps: (1) confirm the upstream application server is running, (2) curl the upstream directly from the proxy host to verify it responds, (3) check the proxy error log for the specific upstream failure. The #1 cause is the upstream app being crashed or restarting; restarting it fixes most cases.
502 means the proxy got an invalid response from the upstream (or no response at all because the connection failed). 504 Gateway Timeout means the proxy connected to the upstream successfully but the upstream took too long to send a response. 502 = upstream broken; 504 = upstream too slow.
Cloudflare returns 502 when it can't get a valid response from your origin server. Most common causes: origin is down, origin firewall is blocking Cloudflare IPs, origin IP in Cloudflare DNS is wrong, or origin is overloaded. Cloudflare's 5xx error reference page in the dashboard tells you which specific failure mode triggered the 502.
It depends where the 502 originates. If your origin server is crashing under load, it's your application or capacity. If the proxy and upstream are both healthy but a firewall is blocking the connection, it's a configuration issue. If your host's shared infrastructure is failing, it's the host. The proxy error log tells you which.
Intermittent 502s usually mean either: the upstream is occasionally overloaded and missing its timeout window, the upstream restarts periodically (cron job, deploy, autoscaling), or proxy keepalive connections are being closed by the upstream before the proxy expects. Sample the error log timestamps to spot the pattern.
Brief 502s during a deploy are fine. Sustained 502s (hours+) cause Googlebot to deindex affected pages and reduce crawl rate sitewide. Because 502s often hit every page at once (when the origin is down), they can be more damaging than scattered 500s. Use sub-5-minute uptime monitoring to catch them fast.
Use a zero-downtime deploy strategy: blue/green, rolling, or canary. The principle is the same — never restart all upstream workers simultaneously. Tools like PM2 (--update-env), Kubernetes rolling updates, and AWS CodeDeploy in-place strategies all handle this automatically when configured right.