504 Gateway Timeout: what it means, why it happens and how to fix it

A 504 Gateway Timeout error means a server acting as a gateway or proxy waited for the server behind it and got no reply in time. The page you asked for may be fine, but the application behind the proxy (nginx, a load balancer, a CDN such as Cloudflare) took longer than the proxy was willing to wait. To fix it, find the slow hop, make that request faster, and only then adjust timeouts.

The HTTP specification defines it this way: the server, "while acting as a gateway or proxy, did not receive a timely response from an upstream server it needed to access in order to complete the request" (RFC 9110, section 15.6.5). The "upstream server" is your application server, PHP-FPM pool, Node process, database-backed API or origin.

504 vs 502 vs 503

A 502 Bad Gateway and a 504 often show up in the same incident, because each proxy decides which code to send when an upstream connection stalls or drops. A 503 Service Unavailable is different: the server you reached is refusing work, usually on purpose.

Common causes

• A slow request. A database query without an index, a report that scans a whole table, or a call to a third-party API that hangs. The proxy times out while the application is still working.
• An overloaded upstream. Every worker is busy, so new requests wait in a queue until the proxy gives up.
• A timeout chain that doesn't line up. The CDN waits 125 seconds, the load balancer 60, nginx 60 and PHP 30. The shortest timeout in the chain decides what the visitor sees.
• Network trouble between the proxy and the origin. A firewall or network ACL drops return traffic, so the proxy never hears back.
• A long job run inside a web request. Exports, imports, image processing and AI calls that take minutes belong in a background job, not in a request a proxy is timing.

How to diagnose a 504, step by step

1. Confirm it from outside and time it. curl shows the status and how long the request ran before it failed:

   curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com/slow-page
   

   A 504 that always arrives at 60.0 seconds points at a 60-second timeout somewhere in the chain.

2. Request the origin directly. Bypass the CDN or load balancer:

   curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" --resolve example.com:443:203.0.113.10 https://example.com/slow-page
   

   If the origin answers, but after 90 seconds, the application is the problem. If it answers fast, look at the proxy layer and the network in between.

3. Read the proxy's error log. nginx writes upstream timed out (110: Connection timed out) while reading response header from upstream when it gives up on a slow upstream.

4. Find the slow part in the application. Check slow-query logs, application traces and calls to outside APIs for the same timestamp.

5. List every timeout in the chain (CDN, load balancer, web server, application runtime) and write down each value.

Fixes by platform

nginx as a reverse proxy

nginx's defaults are a 60-second proxy_read_timeout, proxy_send_timeout and proxy_connect_timeout. The read timeout "is set only between two successive read operations, not for the transmission of the whole response", and the connect timeout "cannot usually exceed 75 seconds" (nginx proxy module). For PHP-FPM behind nginx, the equivalent is fastcgi_read_timeout, also 60 seconds by default (nginx FastCGI module).

location /admin/reports/ {
    proxy_pass http://app;
    proxy_read_timeout 180s;
}

Apache with mod_proxy

ProxyTimeout sets the "network timeout for proxied requests". Its default is the value of the core Timeout directive (Apache mod_proxy). As with nginx, raise it per virtual host or route that genuinely needs it, after you have looked at why the backend is slow.

Cloudflare

Cloudflare sends its own code, error 524, when it connected to your origin but "the origin did not provide an HTTP response before the default 125 seconds". Enterprise customers can raise that limit to 6,000 seconds; everyone else should poll long jobs instead of holding one request open, or move requests that regularly run past 125 seconds to a DNS-only subdomain (Cloudflare error 524).

A Cloudflare-branded 502 or 504 page means your origin returned that error (Cloudflare 502/504). Start with the origin's own logs and the load balancer in front of it.

AWS Application Load Balancer

AWS lists these 504 causes, among others: the load balancer "failed to establish a connection to the target before the connection timeout expired (10 seconds)", or it connected but "the target did not respond before the idle timeout period elapsed". It also names a network ACL that blocks return traffic on the ephemeral ports, and a target that sends a content-length larger than the body it sends (ALB troubleshooting).

The idle timeout defaults to 60 seconds and can be set from 1 to 4,000 seconds. AWS recommends setting your application's own idle timeout higher than the load balancer's (ALB attributes):

aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn <arn> \
  --attributes "Key=idle_timeout.timeout_seconds,Value=120"

Vercel and other serverless hosts

On Vercel, a 504 with the code FUNCTION_INVOCATION_TIMEOUT means a function ran longer than its allowed execution time. Vercel names slow API or database calls, a function that never returns a response, infinite loops and unhandled exceptions as causes (Vercel docs). Make sure every path returns a response, and move long work out of the request.

What visitors can do

A 504 is a server problem. A visitor can wait a minute and reload, or try again outside peak hours. If one specific action always times out (a big export, a search with many filters), tell the site's owner the exact URL and what you clicked, because that request is probably the slow one.

How 504 errors affect Google Search

Google handles a 504 like other server errors. Its documentation says "5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling", that content from 5xx responses is ignored, and that already indexed URLs "are preserved in the index, but eventually dropped" if the errors continue (Google Search Central). Once the server answers with 2xx again, Google gradually raises the crawl rate.

A slow page that only times out for Googlebot now and then is easy to miss.

Search Console's Page indexing report lists URLs under "Server error (5xx)". After a fix, check that the page and its redirects end in a fast 200 with the redirect checker, and watch load times with the Core Web Vitals checker.

For the full list of codes and how Google treats each, see HTTP status codes.