HTTP 502 Bad Gateway - What It Means and How to Fix It

A 502 Bad Gateway means a server acting as a gateway or proxy received an invalid response from the inbound server it contacted while trying to fulfill the request. That is the RFC 9110 definition (section 15.6.3). In everyday terms: nginx, your load balancer or your CDN tried to reach your application, and what came back was a refused connection, a dropped connection or something that was not valid HTTP. The application is the usual suspect; the proxy is just the messenger.

Who returns a 502

A 502 is only ever produced by something sitting in front of another server:

• Reverse proxies such as nginx, Apache with mod_proxy, HAProxy, Caddy or Traefik, in front of an app server like Gunicorn, uWSGI, Puma, PHP-FPM or a Node.js process.
• Load balancers such as AWS Application Load Balancer, Google Cloud Load Balancing or Kubernetes ingress controllers.
• CDNs such as Cloudflare, Fastly or CloudFront when the origin returns something they cannot use.

When there are several layers (CDN, then load balancer, then nginx, then the app), the 502 can come from any of them. The Server response header and the style of the error page usually tell you which layer generated it.

curl -sS -D - -o /dev/null https://example.com/

A response with server: cloudflare and a Cloudflare-branded page came from Cloudflare. A plain page with "nginx" at the bottom came from your nginx.

Common causes

1. The app process is not running. It crashed, was killed by the out-of-memory killer, or failed to start after a deploy. The proxy's connection is refused.
2. Wrong upstream address. The app listens on port 8000 but nginx points to 8080, or a Unix socket path changed after a PHP version upgrade.
3. The app crashed mid-response. A worker died while handling the request (a segfault, a worker timeout, a memory limit), so the proxy saw the connection close before a full response arrived.
4. Response headers too large. Large cookies or many Set-Cookie headers can exceed nginx's proxy_buffer_size, and nginx treats that as an invalid upstream response.
5. Protocol mismatch. The proxy speaks plain HTTP to an upstream expecting HTTPS, or vice versa, or the upstream does not speak HTTP at all on that port.
6. All backends marked unhealthy. A load balancer has no healthy targets, or nginx has marked every server in an upstream block as failed.
7. Firewall or security group changes that block the proxy from reaching the app.

How to diagnose a 502

Read the proxy's error log first

On nginx, the error log usually states the cause in one line:

sudo tail -n 50 /var/log/nginx/error.log

What the common lines mean:

Check the upstream directly

Bypass the proxy and talk to the app on the server itself:

sudo systemctl status myapp
sudo ss -ltnp | grep 8000           # is anything listening on the port?
curl -sS -i http://127.0.0.1:8000/  # does the app answer locally?

If the local request also fails, the problem is the app. If it succeeds, compare the address and protocol with the proxy_pass or fastcgi_pass line in your nginx config.

Look at the app's own logs

sudo journalctl -u myapp --since "15 minutes ago"
sudo dmesg -T | grep -i "killed process"   # out-of-memory kills

For Gunicorn, a line such as WORKER TIMEOUT means the worker was killed by Gunicorn's own timeout (30 seconds by default) and the proxy received a closed connection. For PHP-FPM, server reached pm.max_children setting means requests are queuing for workers.

How to fix it

• Start or restart the app, then find out why it stopped. Set Restart=on-failure in the systemd unit so a crash does not leave you down until someone notices.
• Correct the upstream address. Make proxy_pass or fastcgi_pass match what the app actually listens on, then run sudo nginx -t && sudo systemctl reload nginx.
• Fix socket permissions. Set listen.owner, listen.group and listen.mode in the PHP-FPM pool so the nginx user can read the socket.
• Raise buffers for large headers only if headers are legitimately large:

proxy_buffer_size 16k;
proxy_buffers 8 16k;

• Give workers memory and time. Reduce memory per request, increase the worker's own timeout only if the slow requests are expected, and move long jobs to a background queue.
• Make deploys graceful. Use a rolling restart, a reload signal your app server supports, or start the new instance and switch traffic only when it passes a health check.
• Fix health checks. If a load balancer marks every target unhealthy, confirm the health check path returns 200 and is not behind authentication.

Cloudflare 52x codes

Cloudflare uses its own non-standard codes for origin problems, which are distinct from 502:

• 520 – the origin returned an empty, unknown or unexpected response.
• 521 – the origin refused the connection.
• 522 – Cloudflare could not complete a TCP connection to the origin in time.
• 523 – the origin is unreachable, for example because of a DNS or routing problem.
• 524 – the connection was made but the origin did not send a response in time.
• 525 / 526 – the TLS handshake with the origin failed, or the origin's certificate is invalid.

Cloudflare also returns a standard 502 in some cases. Either way, the fix is usually at your origin, and the diagnosis steps above still apply.

Getting alerted on 502s

A 502 often comes and goes as a process crashes and restarts, which makes it easy to miss. An external HTTP monitor that checks your site every minute or few minutes records each occurrence and alerts you when it persists. With PingRobot, HTTP(S) monitors treat a 502 as a failure, re-check it from a second region to rule out a network blip, then alert you by email. A TCP port monitor on the app's port can also tell you whether the upstream itself is reachable, if that port is exposed to the monitor.

If the site returns a timeout instead, read the 504 Gateway Timeout guide; for application crashes that return 500, see HTTP 500 Internal Server Error.

Start monitoring free — 10 monitors, no credit card.