Nginx Server Errors
Bad Gateway (Nginx)
Reviewed for reference consistency: August 11, 2026
the reverse proxy received an invalid response
What 502 Means
The 502 error on the Nginx Server Errors indicates bad gateway (nginx) — the reverse proxy received an invalid response. This typically occurs due to upstream application like php-fpm or node.js crashes unexpectedly.
An Nginx 502 Bad Gateway means Nginx, acting as a reverse proxy, could not get a usable response from the application behind it. The connection may fail outright, the upstream may close early, or the answer may come back empty or malformed — nginx classifies all three as upstream failures, and they surface to the client as this status. RFC 9110 defines the invalid-response core: a gateway received an invalid response from the server it accessed. For an Nginx deployment that localizes the fault precisely: Nginx itself answered, so the problem sits in the upstream connection or the upstream application.
How to fix 502
General informational guidance, not professional advice. Commands can affect your system or data — back up first and proceed at your own risk. FixerCode is an independent reference, not affiliated with any vendor mentioned.
Ask the upstream directly
Point curl at the exact address and port your proxy_pass (or fastcgi_pass) target uses. If that request refuses, hangs, or returns junk, the fault is behind nginx, not in the proxy itself.
curl -sI http://127.0.0.1:8080/
Technical Background
While 502 is a standard HTTP code, its context within Nginx is intensely specific. It proves definitively that Nginx itself is healthy and routing correctly, placing the entirety of the blame on the upstream application layer behind the proxy.
The mechanical nature of an Nginx 502 involves broken sockets. Either the upstream service closed the connection prematurely, or it responded with an HTTP header string so malformed that Nginx refused to pass it downstream to the user.
This status is radically different from an Nginx 504. A 502 means the upstream exchange failed outright and abruptly. A 504 means the upstream service stayed silent until a configured timeout window finally expired.
Nginx also shields clients from some upstream failures automatically. When a request fails on one upstream, the proxy_next_upstream default (error, timeout) makes Nginx retry the next server in the group, but only while nothing has been sent to the client yet — which is why 502s are often intermittent with several backends and constant with just one.
Common Causes
- Upstream application like PHP-FPM or Node.js crashes unexpectedly
- Firewall rules block Nginx from communicating with internal Docker containers
- The backend returns malformed HTTP headers causing parsing failures
- Memory exhaustion kills the upstream worker process mid-flight
- An upstream header block larger than the proxy buffer, which nginx classifies as an invalid response
Typical Scenarios
- A Node.js process crashes suddenly while Nginx waits for the page render
- A PHP-FPM pool exhausts its children and drops the connection
- A Python worker hits an Out Of Memory killer during a database query
- An upstream response header block that exceeds the proxy buffer size, so nginx treats the response as invalid
What to Know
Resolution involves backend worker pool maintenance, memory limit audits, and container health scrutiny within the upstream application layer.
Frequently Asked Questions
Common questions about Nginx 502 error
It means Nginx tried to fetch the page from your application backend, but the backend crashed or responded with garbage data.
Rarely. Because Nginx is simply the messenger in a 502 scenario, resolution typically involves repairing or restarting the backend application service.
A 502 essentially means the backend crashed or disconnected you immediately. A 504 exclusively means the backend took unacceptably long to process.
With several upstream servers, Nginx retries a failed attempt on the next one automatically — the default covers connection errors and timeouts — so a transient failure on one backend usually never reaches the client. A single-backend setup has no such fallback: one dead worker is a hard 502.
It is the case where the upstream answered but the answer was empty or unusable — including a header block that does not fit nginx's proxy buffer. The connection itself worked, so the fix moves from network reachability to whatever produced the malformed response.
Related Error Codes
Related Errors From Other Categories
Similar error codes documented across different platforms and systems
Process Killed — the process was terminated by a SIGKILL signal
Signal 11 (SIGSEGV) — kernel signal for invalid memory reference segmentation fault
Exit Code 139 — process terminated by segmentation fault (Signal 11 / SIGSEGV)
Input/output error EIO — a read or write operation could not complete