Fixing 504 Gateway Timeout Errors

A 504 is a chain of stopwatches

Between a visitor and your code there are usually several programs, and each one starts its own stopwatch when it hands the request inward. The first stopwatch to run out produces the error. That is why the same slow page can show a 504 on one day, a CDN error on another, and simply load very slowly on a third.

Defaults change between versions and hosts often override them, so treat the table as a guide and check the real values on your server. The pattern matters more than the numbers: if the outer layer's limit is shorter than the inner layer's, the outer one fires first and you get a 504 with nothing useful in your application log.

Working out which timeout fired

Time the request first. The number of seconds before the error usually identifies the layer straight away.

curl -s -o /dev/null -w "status %{http_code}  total %{time_total}s  first byte %{time_starttransfer}s\n" \
  "https://www.example.co.uk/reports/annual-summary/?year=2025"

• Almost exactly 60 seconds and a plain nginx or Apache error page: a proxy or FastCGI read timeout on your own server.
• Around 100 seconds and a Cloudflare page with code 524: the origin did not answer Cloudflare in time. Your own server may still be working on the request.
• A round number with a cloud provider's error page: the load balancer's idle timeout.
• An error after a few seconds: probably not a real timeout. A 504 that arrives quickly can mean the proxy cannot reach the upstream at all, which the 502 guide covers in more detail.

Then confirm it in the web server error log. nginx writes a distinctive line for this case:

upstream timed out (110: Connection timed out) while reading response header from upstream,
client: 198.51.100.24, server: www.example.co.uk, request: "GET /reports/annual-summary/?year=2025 HTTP/2.0",
upstream: "fastcgi://unix:/run/php/php8.3-fpm-example.sock"

"While reading response header" means the connection worked and the application was simply too slow. "While connecting to upstream" means nginx could not even open the connection in time, which points at an overloaded or unreachable back end instead.

One URL or all of them?

If one report page, search or export fails, the slowness is in that page's own work. If every page times out at once, something shared is stuck: the database, a full pool of workers, a lock on a table, or a service every page calls, such as a session store. When all PHP-FPM workers are busy on slow requests, even fast pages wait in the queue behind them and time out too, so one slow page can take down the whole site.

Catching the slow step in the act

Once you know the request is too slow, you need to know where the time goes. Three tools answer that without guesswork.

The PHP-FPM slow log

PHP-FPM can write a stack trace of any request that runs longer than a threshold. The trace shows the function it was in at that moment, which usually points straight at a database call, an HTTP request or a loop.

; in the site's PHP-FPM pool file
request_slowlog_timeout = 10s
slowlog = /var/log/php-fpm/example-slow.log

Reload PHP-FPM, trigger the slow page, and read the file. A trace ending in curl_exec() means an outgoing web request; one ending in a database driver function such as mysqli_query() or PDOStatement->execute() means a query.

The database slow query log

-- MySQL or MariaDB, until the next restart
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2;
SHOW VARIABLES LIKE 'slow_query_log_file';

Run EXPLAIN on any query that appears. A type of ALL on a large table means every row is scanned, and the usual fix is an index on the columns in the WHERE and ORDER BY clauses. For PostgreSQL, the equivalent setting is log_min_duration_statement.

Application monitoring

An application performance monitoring tool, or a framework debug bar on a staging copy, breaks a request into database, cache, external call and code time. If you have one, it is the fastest way to see the slow step for a specific URL.

The fix, step by step

When raising the timeout is the right answer

Increasing fastcgi_read_timeout or proxy_read_timeout is the most common advice for a 504, and it is sometimes correct. It is right when a small number of known, legitimate operations need more time and only trusted users trigger them, such as an administrator running a report. It is wrong as a general fix, because:

• Visitors still wait. A page that takes 90 seconds instead of failing at 60 is not a working page for anyone browsing.
• Slow requests hold workers. Every request that runs for a minute occupies a PHP-FPM worker or Node connection for that minute, so fewer are left for everyone else.
• The CDN will not wait. Raising your own limit above the CDN's timeout just moves the error to the CDN.

If you do raise it, scope it to the path that needs it:

# nginx: longer limit only for the admin export area
location ^~ /admin/exports/ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
    fastcgi_pass unix:/run/php/php8.3-fpm-example.sock;
    fastcgi_read_timeout 180s;
}

Remember to raise the matching PHP-FPM request_terminate_timeout for that pool if it is lower, or the worker will be stopped anyway.

Patterns that point to the cause

Pages that can be cached for anonymous visitors, such as product listings and articles, should be. A full-page cache in front of the application means most requests never reach the slow code at all, which protects the site even while you work on the underlying query.

What 504s mean for search engines

Search engines treat a 504 like other server errors: the page is not fetched, and the crawler tries again later. Repeated timeouts cause Google to slow down its crawling of the site, and slow responses in general reduce how many pages it will request in a session. The Crawl Stats report in Search Console shows both the average response time and the share of requests that ended in server errors, which is a useful before-and-after check once you have made fixes. Slow pages also hurt visitors long before they reach a timeout, so fixing the slow step pays off even for pages that never actually fail.

If your pages respond but only after a long delay, or the connection never gets an answer at all, the request timeout guide covers slow first bytes and network-level causes.

Keeping timeouts away

• Leave the slow logs on. A PHP-FPM slow log at a generous threshold and a database slow query log cost little and warn you before slow becomes a timeout.
• Set timeouts on every outgoing call. Many HTTP client libraries wait a very long time by default. Give each external call an explicit short limit.
• Design big tasks as background work. Anything that grows with the size of your data belongs in a queue, not in a page request.
• Check query plans when data grows. Review slow queries after large imports or when a table grows significantly.
• Schedule heavy jobs for quiet hours. Keep backups and imports away from busy periods and from times when crawlers are most active on your site.
• Audit regularly. The HTTP Error Audit records response times as well as status codes, so pages creeping towards a limit are visible before they fail.