5xx Server error · RFC 9110 §15.6.3

502 Bad Gateway

A proxy or load balancer got an invalid response from the upstream server.

What 502 means

The component you reached (nginx, a CDN, a cloud load balancer) tried to contact the real application and got a connection refused, a reset, or a garbled response. The application is usually down, restarting, or listening on the wrong port.

Look at the proxy error log first: "connect() failed (111: Connection refused) while connecting to upstream" names the exact upstream address.

Common causes

  • Application process crashed or is still starting.
  • Wrong upstream host or port in the proxy config.
  • Upstream closed the connection (out of memory, worker killed).
  • TLS mismatch between proxy and upstream.
  • Response headers too large for the proxy buffers.

How to fix it

  • Check the app is running and listening: ss -ltnp or the container logs.
  • Fix the upstream address in the proxy config and reload.
  • Increase proxy_buffer_size if the upstream sends large headers.
  • Add health checks so the balancer stops sending traffic to dead instances.

What it looks like

A typical response:

HTTP/1.1 502 Bad Gateway
Server: nginx
Content-Type: text/html

<html><head><title>502 Bad Gateway</title></head>…

The same event in an nginx access log (the status is the number after the request line):

203.0.113.7 - - [10/Sep/2026:10:12:01 +0000] "GET / HTTP/1.1" 502 153 "-" "Mozilla/5.0"

Check it with curl

-i prints the status line and headers, and -w '%{http_code}' prints only the number, which is handy in scripts and health checks. Replace the URL with yours:

curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' https://example.com/api/orders

Compare what curl sees with what the browser sees. A different status from the same URL usually means a cache, a CDN edge or a cookie is in the way.

Investigating a run of 502s? Paste the log excerpt into Log Share to get line numbers, highlighting and an expiring link for whoever is on call with you.

FAQ

502 vs 504?

502: the upstream answered but wrongly, or refused the connection. 504: the upstream did not answer in time.

Why do I get 502 for a few seconds after every deploy?

The old process is gone before the new one listens. Use a rolling restart, a readiness check, or a process manager that overlaps old and new workers.