---
title: "502 Bad Gateway"
canonical: "https://lemwatch.com/http-status-codes/502"
category: "server-error"
last_verified: "2026-08-11"
source: "https://lemwatch.com"
---

# HTTP 502 Bad Gateway

**TL;DR** — 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 restarting; the #2 cause is a firewall blocking the proxy → upstream connection.

## What it means

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.

## Common causes

- Upstream application server (PHP-FPM, Node, gunicorn, Puma, uwsgi) is down or crashed
- Application server is overloaded and not responding within the proxy's timeout
- Firewall or security group blocking the proxy → upstream connection
- DNS resolution failure: proxy can't resolve the upstream hostname
- Upstream returning malformed HTTP (truncated headers, bad chunked encoding)
- Proxy and upstream disagree on keepalive timeouts — proxy reuses a connection the upstream already closed
- Cloudflare origin IP changed but DNS in Cloudflare dashboard wasn't updated

## How to fix

- Check whether the upstream application server is actually running: systemctl status php-fpm / pm2 list / docker ps
- Curl the upstream directly from the proxy host, bypassing the proxy: curl -v http://127.0.0.1:9000 — this tells you whether the upstream itself works
- Check the proxy error log for the exact upstream failure: tail -100 /var/log/nginx/error.log
- Restart the upstream application server — fixes ~70% of one-off 502s
- Verify firewall / security group rules allow the proxy IP to reach the upstream port
- If using Cloudflare: confirm the origin IP in the dashboard matches the actual server IP, and that Cloudflare IP ranges are whitelisted at the origin firewall
- Tune timeouts: proxy_read_timeout, proxy_connect_timeout (Nginx) — but only after you've confirmed the upstream is the bottleneck

## SEO impact

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.

## Monitoring tip

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.

**Related:** [500](https://lemwatch.com/http-status-codes/500.md), [503](https://lemwatch.com/http-status-codes/503.md), [504](https://lemwatch.com/http-status-codes/504.md), [521](https://lemwatch.com/http-status-codes/521.md)

_Canonical HTML page: https://lemwatch.com/http-status-codes/502_