504 Gateway Timeout: what causes it and how to fix it

504 vs 502 vs Cloudflare's 524

A 502 Bad Gateway means the proxy got a broken response or a refused connection: the backend was down or misbehaving. A 504 means the backend was reachable, or at least not refusing, but did not answer in time. One is usually a crash or misconfiguration, the other usually slowness.

Cloudflare uses its own code for the slow-origin case. Its 524 error means Cloudflare connected to your server but did not receive an HTTP response within its proxy read timeout, which Cloudflare's documentation sets at 125 seconds by default; Enterprise plans can raise it to 6,000 seconds. A 504 seen behind Cloudflare usually comes from a timeout inside your own stack, passed through.

Where the timeouts live

Knowing each layer's default helps you match the time it took to fail with the layer that gave up:

• nginx: proxy_read_timeout and fastcgi_read_timeout default to 60 seconds. nginx logs "upstream timed out (110: Connection timed out)" when one expires.
• Apache: ProxyTimeout applies to proxied requests and defaults to the main Timeout setting, which is 60 seconds by default.
• PHP: max_execution_time limits script run time (30 seconds in the default php.ini), and PHP-FPM's request_terminate_timeout can kill a worker that runs too long.
• Load balancers: many have an idle timeout, for example 60 seconds by default on AWS Application Load Balancers, after which they return 504.
• CDNs: Cloudflare waits 125 seconds by default before returning 524.

Align the timeouts

The timeouts work well nested, with each inner layer giving up before the layer outside it. If PHP stops a script before nginx stops waiting, and nginx stops before the load balancer or CDN does, the failure is reported by the layer closest to the problem, with a clear entry in its log. When the order is reversed, an outer layer returns a generic 504 while the application keeps working on a request nobody is waiting for, using up a worker for nothing.

Connection timeouts are separate from read timeouts. nginx's proxy_connect_timeout, for example, covers only establishing the connection to the backend. A 504 that happens on connecting points at a backend that is unreachable or dropping traffic, not at a slow page.

Common causes

Raising a timeout rarely fixes a 504 on its own. The question is why the response took so long. The usual reasons:

• Slow database queries, such as a missing index, a huge table scan, or a query waiting on a lock held by another process.
• Calls to external services. An API, payment gateway or license server that hangs makes your page hang with it.
• Long jobs run inside a web request: imports, exports, report generation, image processing or backups started from an admin screen.
• An overloaded server. When every worker is busy, new requests queue, and the wait in the queue alone can exceed the timeout.
• A network path that silently drops traffic between the proxy and the backend, for example a firewall rule that drops packets rather than rejecting them, so the connection attempt hangs until it times out.

How to fix a 504 as the site owner

Find the slow layer first, then fix the slow work, and only then consider timeouts:

1. 1Confirm from outside with the uptime check. It names the failing stage, so you can see whether the request timed out completely or returned a 504 from a proxy.
2. 2Note how long the failing request takes. A failure at about 60 seconds points at a 60-second timeout such as nginx's default; 125 seconds behind Cloudflare points at Cloudflare's limit.
3. 3Use the HTTP header checker on a working page of the site to see which layers sit in front (CDN, load balancer, web server), then read each layer's error log at the time of the failure.
4. 4Find the slow request. Enable PHP-FPM's slow log or your application's request logging, and the database's slow query log, then reproduce the failing page.
5. 5Fix the slow work: add the missing index, put a short timeout and caching on external API calls, and move long jobs out of the web request into a background queue or scheduled task.
6. 6If a legitimately long request must stay, such as an admin export, raise the timeouts for that path only, and keep them aligned: an inner timeout longer than the outer one never gets a chance to apply.
7. 7If the server is constantly saturated, reduce the load with caching or add capacity.

504 errors on WordPress

On WordPress, 504s cluster around a few patterns: admin pages and admin-ajax requests from plugins that do heavy work, imports and bulk edits, backup or migration plugins running inside a web request, and plugins that call external services on page load. The Query Monitor plugin shows slow database queries and HTTP API calls per request, which points at the responsible plugin.

WP-Cron is another source. By default WordPress runs scheduled tasks on visitor page loads, so a heavy scheduled job can slow random visitor requests. Setting DISABLE_WP_CRON in wp-config.php and running wp-cron.php from a real system cron moves that work off visitor requests.

What visitors can do

A 504 is a problem on the website's side. Reloading after a short wait is worth trying, because a temporary spike or a single slow request may have caused it. If the error appeared after submitting a form or placing an order, check for a confirmation email before resubmitting, since the action may have completed even though the page timed out.