Interactive tool
What that status code means
Most references tell you what a code means. The more useful question during an incident is who sent it — a 502 from your load balancer and a 502 from your application call for completely different next moves, and the number does not say which you have. This says.
Runs in your browser · nothing is sent anywhere
From an access log, a browser network tab, or curl -o /dev/null -w '%{http_code}'.
502Bad Gateway
A proxy tried to reach the thing behind it and got an answer it could not use — or no answer at all.
Usually the proxy or load balancer
The proxy is reporting on somebody else. Your application may have returned nothing, crashed mid-response, or never been reachable.
First move
Ask whether the upstream is alive and whether the proxy is pointed at it. Your application logs may be silent, and that silence is evidence.
Often confused with
- — 502 means the upstream answered badly or not at all. 504 means it did not answer in time.
All 22 codes on this page
Success — it worked
Redirection — look elsewhere
Request rejected — usually, but not always, the caller
Server failed — the request may have been fine
Related troubleshooting
What a status code is
Every HTTP response opens with a three-digit number saying how it went. The first digit is the class and carries most of the meaning: 2xx worked, 3xx means look elsewhere, 4xx means the request was refused, 5xx means the server failed.
The part that trips people up is that a response passes through several pieces of software on its way back, and any of them can answer instead of the one you were trying to reach. The number does not say which did.
Using it
Type the code. You get what it means, who most likely produced it, and the first thing worth checking. Codes this page does not list still get an answer from their class, which is usually enough to know which side of the connection to look at.
Get the code without the body using curl -o /dev/null -s -w '%{http_code}\n' https://example.com.
Why “client error” is a misleading name
4xx is defined as a client error, and that framing sends people to the wrong side of the connection more or less daily. All it really says is that a server rejected a request. A 413 is usually a proxy body-size default, a 404 in a cluster is usually an Ingress with no matching rule, and a 400 is often a header too large for the front end — none of which are fixed by changing the caller.
The same ambiguity runs the other way in 5xx. A 500 really is yours: your code raised something it did not handle. A 502 or a 504 is a proxy reporting on somebody else, and your application logs may be entirely silent — which is evidence, not an absence of it.
So the first question during an incident is rarely “what does this number mean”. It is who answered. If the request never appears in your application logs and carries no trace header you issued, it did not reach you, and everything downstream of that conclusion changes.
Tools that go with this
- Container Exit Code ExplainerWhat 137, 143 and 139 mean, and the rule behind them.
- Kubernetes Manifest AnalyzerPaste a manifest. Privileged containers, missing limits, absent probes, plaintext secrets — each linked to the failure it causes.
- CIDR CalculatorNetwork address, usable range and host count for an IPv4 block — including the /31 and /32 cases where subtracting two is wrong.
- Error Budget CalculatorWhat an availability target allows, and the burn rate.
Questions people ask about this
What is the difference between 502 and 504?
Both come from a proxy reporting on something behind it, and the difference is whether it waited. A 504 is a timeout: the upstream never answered inside the deadline. A 502 means an answer arrived and was unusable, or the connection failed outright.
That distinction changes what you look at. A 504 points at something slow — a query, a lock, a downstream call. A 502 points at something broken or absent — a crashed worker, a wrong port, a process that died mid-response.
I am getting a 404 but the route exists. Where has it gone?
Establish whether the request reached your application at all. If nothing in your logs shows it, the 404 came from in front of you and the route being correct is beside the point.
In Kubernetes this is usually an Ingress with no rule matching the host or path, or a Service selecting no pods. Both answer 404 for a path your application would have served happily.
Why does a large upload fail with 413 when my app allows it?
Because the proxy rejects it before your application is consulted. nginx defaults client_max_body_size to 1MB, and an ingress controller usually has its own equivalent — so raising the limit in application config changes nothing.
Raise it at every hop that can refuse it, not just the last one.
Is a 4xx always the client's fault?
No, and the name causes real confusion. 4xx means a server rejected a request, not that the caller misbehaved. A 413 from a proxy default, a 404 from an unmatched route and a 400 from an oversized header are all fixed on the server.
The useful question is not which class the code is in. It is which piece of software produced the response.
What is a 499, when no specification defines one?
It is nginx’s own log entry for “the client gave up and disconnected before I could answer”. It is never sent over the wire — nobody receives a 499.
A rise in them almost always means you got slower rather than that clients changed. Compare them against upstream response time.
Did this get you to an answer?
No text box on purpose — please do not paste production logs anywhere