What is the difference between a 502 and a 504?

Both come from a gateway or proxy talking to an upstream, but RFC 9110 draws the line by what came back. A 502 (15.6.3) means the proxy received an invalid response from the upstream; a 504 (15.6.5) means it received no timely response at all — it waited and gave up. 502 is a bad answer, 504 is no answer in time. They point at different problems, so do not troubleshoot them the same way.

Is a 504 a client-side or server-side problem?

Server-side, almost always. The proxy answered you — it just could not get a timely answer from something behind it. That is different from ERR_CONNECTION_TIMED_OUT, where your own connection to the edge never completed and you never got any HTTP status back.

Why does the 504 come back after almost exactly 60 seconds?

Because a timeout is a fixed clock. nginx defaults its proxy_read_timeout to 60 seconds and an AWS Application Load Balancer defaults its idle timeout to 60 seconds, so a backend that runs long hits that wall and the proxy emits a 504 at the limit. The roundness of the delay is the clue — random failures do not land on the same second every time.

I am on Cloudflare and see error 524, not 504. Same thing?

Same root cause, different label. 524 (A timeout occurred) is Cloudflare-specific: it connected to your origin but the origin did not send a response in time. A standard 504 means an intermediate hop timed out. Either way the fix is the slow origin, not the edge.

Views: 18

504 Gateway Timeout Checklist

504 Gateway Timeout means the upstream was too slow, not broken. Fix it in 3 checks: upstream latency, port reachability, DNS target. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

The proxy answered, and the answer was 504 Gateway Timeout. Read RFC 9110 §15.6.5 literally: the gateway “did not receive a timely response from an upstream server it needed to access.” Timely is the whole story. A 504 does not mean “I couldn’t reach the backend” — it means “I reached it, I waited, and it never finished talking.” The single most useful piece of evidence you have is how long the request hung before the 504 came back.

Symptoms

HTTP Check returns a final 504 after a long, suspiciously round delay — often almost exactly 30, 60, or 100 seconds.
The edge or proxy itself is up: you got an HTTP error page back, not a dead connection.
It is worse on slow endpoints — reports, exports, search, anything that does real work. Static pages load fine.
It is not a 502 (the proxy got an invalid or empty reply) and not a client-side ERR_CONNECTION_TIMED_OUT (your SYN never got answered at all).

Top 3 Causes

The upstream is slow, not down - It exceeds the proxy’s read timeout. nginx defaults proxy_read_timeout, proxy_connect_timeout, and proxy_send_timeout to 60 seconds; an AWS ALB defaults its idle timeout to 60 seconds and its target connection timeout to 10. A backend that takes 65 seconds on a heavy query produces a 504 like clockwork.
The proxy cannot open a connection to the upstream in time - A connect timeout. The backend is saturated, its accept queue is full, or the configured upstream address is wrong or firewalled. The proxy waits out the connect window, then gives up.
A timeout mismatch in the chain - Every hop (CDN → load balancer → app server → database) keeps its own clock, and the shortest one fires first. A request that legitimately needs 90 seconds behind a 60-second proxy will always 504, no matter how healthy each component looks on its own.

The clock tip: note the delay before the 504. Roughly 60 seconds on nginx or an ALB points straight at a read timeout — go fix the slow query or raise the limit, not the firewall.

Diagnose with DechoNet

HTTP Check to confirm the final code is 504 and see how long the request takes. A 504 that returns in a round number of seconds is a timeout firing, not a fluke.
Port Check to verify the upstream or origin port is actually reachable. This separates the connect-timeout cause from the read-timeout cause — if the port is open, the proxy can reach the backend and the problem is latency, not routing.
DNS Lookup to confirm the proxy is forwarding to the live origin and not a stale or wrong address that quietly black-holes connections.

If the port comes back closed or refused rather than the request timing out, you have a reachability problem, not a timeout — switch to the open port 443 closed checklist. If the browser fails with ERR_CONNECTION_TIMED_OUT and never gets any HTTP code, that is client-to-edge — see the ERR_CONNECTION_TIMED_OUT fix.

Resolution Checklist

Measure the actual response time of the failing route. If it sits near the proxy’s read timeout, you have found the cause.
Compare proxy timeout settings (proxy_read_timeout, ALB idle timeout) against real backend latency. Raising the limit is a stopgap; fixing the slow path is the real fix.
Profile the slow endpoint — a missing index, an N+1 query, a blocking external API call. A 504 is usually a performance bug wearing a network costume.
Confirm the upstream port is reachable and the backend is not saturated (full accept queue, exhausted worker or connection pool).
Walk the whole chain and align timeouts so an outer proxy is not shorter than an inner hop that legitimately needs the time.
Re-run HTTP Check; a healthy result returns well under the timeout, not pinned against it.

When to Escalate

Escalate to whoever owns the slow upstream when the 504 tracks one specific heavy endpoint. That is an application performance problem, and raising a proxy timeout only moves the pain downstream.
Escalate to platform or infrastructure owners when a managed load balancer or CDN sits in front and the timeout is theirs to configure, not yours.
If 504s are intermittent and correlate with traffic spikes, treat it as capacity and saturation rather than a single fault — look at autoscaling, connection pools, and database contention.