502 Bad Gateway
What a 502 means, how it differs from 503 and 504, and what to check when your own server returns one.
Runs in your browser
Click a code to copy it.
The request was fine. The server failed to handle it.
| Code | Meaning |
|---|---|
| Internal Server Error | Something broke and the server has nothing more specific to say. |
| Not Implemented | The server does not support what was asked of it at all. |
| Bad Gateway | A proxy asked something upstream and got an answer it could not use.The upstream answered badly. 504 means it did not answer in time, and 503 means this server chose not to try. |
| Service Unavailable | Temporarily refusing to serve — overloaded or in maintenance. |
| Gateway Timeout | A proxy waited for something upstream and gave up. |
No status code matches that.
Something in the middle got a bad answer
A 502 comes from a machine that is not the one meant to answer you. A proxy, load balancer or CDN passed your request upstream, got a reply back, and could not make sense of it.
So a 502 is never really about the server you asked. It is about the conversation between two servers behind it — which is why it is so often invisible from the outside and obvious in the logs.
502, 503 and 504 are three different failures
| Code | What happened |
|---|---|
| 502 | The upstream answered badly — malformed, or the connection dropped mid-reply |
| 503 | This server chose not to try — overloaded, or in maintenance |
| 504 | The upstream did not answer in time |
Getting these right in your own services matters more than it seems: a 503 with
a Retry-After header tells a client exactly when to come back, where a 502
tells it nothing useful.
If you are seeing one on someone else’s site
There is very little you can do, and it is almost never your end. Refresh after a minute. If it persists across networks and devices, it is theirs.
Worth ruling out once: a stale cached redirect or a corporate proxy of your own can produce a 502 that nobody else sees.
If your own server is returning one
The usual causes, roughly in order:
- The application behind the proxy is not running, or crashed and has not restarted. Check the process first, before anything else.
- It is listening somewhere else — wrong port, or bound to
127.0.0.1when the proxy expects0.0.0.0, which is extremely common in containers. - It died mid-response. An out-of-memory kill during a large reply produces a 502 rather than a 500, because the proxy sees a truncated answer.
- A timeout mismatch. If the proxy’s timeout is shorter than the application’s, slow requests surface as 502 or 504 under load and never in testing.
- Headers too large. An oversized cookie or
Authorizationheader can exceed the proxy’s buffer, and the reply is rejected as malformed.
The application log is nearly always more informative than the proxy log here. The proxy only knows that the answer was unusable; the application knows why.