502, 503, and 504 Errors: What Each One Actually Means

502, 503, and 504 all mean roughly “the server couldn’t give you a real answer right now,” which is why they’re so often confused for each other. But each code narrows the problem down differently, and reading the number correctly saves time troubleshooting the wrong layer.

The quick distinction

• 502 Bad Gateway — a server acting as a gateway or proxy got an invalid response from the server behind it.
• 503 Service Unavailable — the server is up but is deliberately refusing to handle the request right now (overloaded, or in maintenance).
• 504 Gateway Timeout — a server acting as a gateway or proxy got no response from the server behind it within its time limit.

The pattern: 502 and 504 both involve two servers — a proxy/load balancer/CDN in front, and an application server behind it. 503 is usually just one server telling you directly that it’s not ready.

502 Bad Gateway

What’s happening: A reverse proxy, load balancer, or CDN (like Cloudflare or Nginx acting as a gateway) forwarded your request to the actual application server, and got back a response it couldn’t understand or that was malformed — not silence, an actually broken reply.

Common causes:

• The application server (Node, PHP-FPM, a backend process) crashed or restarted mid-request.
• A misconfigured reverse proxy pointing at the wrong port or address.
• The backend returned a response that violates basic HTTP formatting.
• A CDN or WAF in front of the site is misconfigured and rejecting a legitimate backend response.

What to check if it’s your site: Look at your application server’s logs for crashes or restarts around the error time. Confirm your reverse proxy config (nginx proxy_pass, load balancer target, etc.) points at a backend that’s actually running on the expected port.

503 Service Unavailable

What’s happening: The server received your request just fine, but is explicitly telling you it can’t handle it right now. Unlike 502/504, this is usually intentional — a server stating its own condition rather than a proxy complaining about what’s behind it.

Common causes:

• Planned maintenance — many platforms return 503 on purpose while deploying or updating, often with a Retry-After header.
• Overload — too many concurrent requests for the server’s capacity, common during traffic spikes (a sale, a viral post, a DDoS).
• Resource exhaustion — the server ran out of memory, database connections, or worker processes to handle new requests.
• Rate limiting — some setups return 503 instead of 429 when a client (or an upstream service) is sending requests too fast.

What to check if it’s your site: If this appeared during a deploy, it may resolve itself within seconds to minutes. If it persists, check server resource usage (CPU, memory, connection pool limits) and your process manager’s logs for workers failing to start or being killed.

504 Gateway Timeout

What’s happening: Same two-server setup as 502, but instead of getting a broken response from the backend, the proxy got nothing at all within its allotted wait time. It’s the “gateway” sibling of a plain connection timeout.

Common causes:

• The backend is taking too long to process the request — a slow database query, an unoptimized script, or a dependency (API, third-party service) that’s itself slow or down.
• The backend is overloaded and too busy to respond in time, even though it hasn’t crashed.
• A proxy timeout setting that’s too aggressive for a legitimately slow (but working) operation, like a large file upload or a heavy report generation.

What to check if it’s your site: Profile the slow endpoint directly, bypassing the proxy, to see if the backend itself is slow or if the issue is purely in the proxy layer. Check whether a specific dependency (database, external API) is degraded, since that’s the most common root cause of a backend going slow rather than crashing outright.

Is it you, or is it them?

All three of these are server-side errors by definition — they’re not caused by your browser, your DNS, or your local network, which separates them clearly from issues like ERR_CONNECTION_TIMED_OUT or DNS_PROBE_FINISHED_NXDOMAIN. If you’re seeing a 502, 503, or 504, the fix (if there is one you can make) is almost never on your end — refreshing occasionally works for a transient 503, but a persistent one just means waiting for the site to resolve it.

To confirm it’s not just you — some CDN or regional edge nodes occasionally serve a bad gateway error while others are fine — run the site through an independent status check to see the live HTTP status code from a server outside your own network, along with response time and SSL status in the same view.