502 Bad Gateway, 503 and 504: what each error actually means

All four mean a server failed, not your connection. That is the first useful thing to know, because it saves you restarting a router that was never involved. The second useful thing is that each number points at a different stage of the failure, and the difference matters enormously if the site happens to be yours.

These codes exist because almost no website is a single server any more. There is a proxy or load balancer at the front, and one or more application servers behind it. The proxy is the thing generating the error, and it is telling you something specific about its relationship with the machine behind it.

Why these errors exist at all

A request to a modern site passes through several hands. A CDN edge node takes it first. That forwards to a load balancer. The load balancer picks an application server. The application server queries a database and renders a response, which travels back along the same chain.

Each link can fail independently, and each intermediate device needs a way to say "I am fine, but the thing behind me is not." That is exactly what the 502 and 504 codes are for. 502 means the upstream gave a broken answer. 504 means it gave no answer in time. 503 is different again: it means the server you reached knows it cannot serve you right now, and is saying so deliberately.

Reading them this way tells you roughly how far your request travelled before it died.

What each code actually means

Code	Literal meaning	What it usually is
500 Internal Server Error	The application crashed while handling the request	A code bug, an unhandled exception, a failed database query. The server is running, the code is not.
502 Bad Gateway	A proxy got an invalid response from upstream	The application process died or restarted, is listening on a different port than the proxy expects, or crashed mid response.
503 Service Unavailable	The server is deliberately refusing right now	Maintenance mode, overload protection, rate limiting, a health check failing, or no backends available in the pool.
504 Gateway Timeout	The upstream did not answer within the deadline	A slow database query, an external API hanging, or a request doing more work than the proxy's timeout allows.

The distinction between 502 and 504 is the one worth remembering. 502 is a broken answer, 504 is no answer. A 502 usually means something crashed. A 504 usually means something is slow. Those lead to completely different investigations.

503 deserves its own note: it is the only one of the four that is often intentional. A site put into maintenance mode returns 503 on purpose, and well configured ones include a Retry-After header telling clients when to come back. A 503 during a traffic spike is overload protection working as designed rather than a fault.

The Cloudflare 5xx codes

If the error page carries a Cloudflare ray ID, the number is more specific than a generic 502 and tells you a lot more.

Code	Meaning
520	The origin returned something Cloudflare could not interpret. Usually an empty response or a malformed header.
521	The origin actively refused the connection. The web server is down, or its firewall is blocking Cloudflare's addresses.
522	The connection to the origin timed out. Often a firewall silently dropping packets rather than refusing them, or an overloaded server.
523	The origin is unreachable. Frequently a DNS record pointing at an address that no longer exists.
524	The connection succeeded but the origin took too long to finish responding. The 100 second limit is the usual culprit.
525 / 526	TLS handshake failure between Cloudflare and the origin, or an origin certificate that failed validation. 526 specifically means the certificate is invalid or expired.

521 and 522 look similar and are not. 521 is a refusal, 522 is silence. A refusal means something answered and said no, which points at the web server being stopped. Silence means packets are disappearing, which points at a firewall rule dropping them.

If you are just trying to use the site

There is not much you can do about someone else's server, but it is worth spending thirty seconds establishing that it really is someone else's problem.

1. Check the status code from a different path

   Run an HTTP(S) Check against the URL. It shows the status code the server actually returned, plus the full redirect chain. If it reports 502 from your phone on cellular data as well as from your laptop on Wi-Fi, that is the server, definitively.

2. Try the bare domain and a known good path

   If the homepage returns 200 and one page returns 500, the site is up and one route is broken. That is a very different situation from the whole thing being down, and worth mentioning if you report it.

3. Check it is not a DNS or certificate problem wearing a 5xx costume

   A DNS lookup confirms the name resolves, and a TLS inspection confirms the certificate is valid. An expired certificate at the origin produces a 526 from Cloudflare, which looks like a server error but is really a certificate problem.

4. Wait, then retry

   502 and 504 during a deployment or a traffic spike often clear themselves within minutes. Refreshing aggressively during an overload makes it marginally worse for everyone.

# What status is the server actually returning?
https://netdebug.app/open/http?target=https://example.com

# Does the name still resolve, and to what?
https://netdebug.app/open/dns?target=example.com&server=1.1.1.1

# Is the certificate at the origin still valid?
https://netdebug.app/open/tls?target=example.com

If the site is yours

Fixing a 502

Something behind the proxy is not answering correctly. In rough order of likelihood: the application process crashed or is in a restart loop, the proxy is configured to talk to the wrong port or socket, the application is bound to localhost while the proxy connects over the network, or a deployment left the old process stopped and the new one not yet listening.

The quickest confirmation is to connect to the application port directly, bypassing the proxy entirely. A TCP connect to the upstream host and port tells you within a second whether anything is listening. If nothing is, the proxy is not at fault and the application is.

Fixing a 504

Something is slow rather than dead. Check for a long running database query, an external API that is not responding, a lock or deadlock, or a request that legitimately needs more time than the proxy's timeout allows. Raising the timeout hides the symptom, and is occasionally the right answer for a genuinely slow report, but usually the real fix is upstream.

A useful signal: if 504s cluster at particular times of day, suspect a scheduled job competing for the database. If they cluster on particular URLs, suspect one slow query.

Fixing a 503

First establish whether it is deliberate. Maintenance mode, a feature flag, a rate limiter or a WAF rule can all produce it intentionally. If not, the usual cause is that a load balancer has no healthy backends, which means the health check is failing. Health checks fail for their own reasons, sometimes as simple as the check hitting a path that now requires authentication.

Fixing a 521 or 522

Your origin is not accepting connections from the CDN. Confirm the web server is running, then check the firewall: if you restricted inbound traffic to a set of addresses, the CDN's ranges need to be in it, and those ranges change. A 522 specifically suggests packets are being dropped rather than refused, which almost always means a firewall rule.

Fixing a 526

The certificate on your origin is expired, self signed, or does not cover the hostname the CDN is requesting. Inspect what the origin is actually serving rather than what your certificate manager claims, because a renewed certificate that was never loaded by the web server is a very common cause. There is more on reading certificate problems in the post on SSL certificate errors.

The codes people confuse

504 Gateway Timeout vs ERR_CONNECTION_TIMED_OUT. The first came from a server and means an upstream was slow. The second never reached a server at all, and means your connection attempt failed. One is their problem, the other might be yours.

502 vs 503. 502 is an accident, 503 is usually a decision. If you are seeing 503 with a Retry-After header, someone chose that.

500 vs 502. 500 means the application ran and threw an error, so it is alive and the bug is in the code. 502 means the proxy could not get a usable response at all, so the application may not be running.

403 and 429 appearing as outages. A WAF or rate limiter returning 403 or 429 is not a server failure, but it looks like one to a user. If the status code is in the 400s, the server is healthy and is refusing you specifically.

The short version

All of these are server side, so nothing on your network needs restarting. 502 means a broken answer from upstream, 504 means no answer in time, 503 means a deliberate refusal, and 500 means the application itself crashed. With Cloudflare, 521 is a refusal and 522 is silence, which point at a stopped server and a firewall rule respectively. Check the actual status code and the redirect chain before assuming anything, and if the site is yours, connect straight to the upstream port to find out whether the proxy or the application is at fault.