A 504 Gateway Timeout means Nginx sent a request to an upstream service – usually PHP-FPM – and that service did not respond in time. Nginx gave up waiting and returned an error to the visitor instead.
The error is not coming from Nginx itself. Nginx is the middleman here. It received the request, forwarded it to PHP-FPM (or another backend), and the backend took too long. From Nginx’s perspective, the upstream is unresponsive.
Understanding that distinction matters because it tells you where to look when diagnosing the problem.
What the 504 error actually means
When a visitor hits your WordPress site, the request travels through several layers:
- Nginx receives the request
- Nginx passes it to PHP-FPM via a Unix socket or TCP connection
- PHP-FPM boots a worker, runs your PHP code, queries the database
- PHP-FPM returns the result to Nginx
- Nginx sends the response to the visitor
A 504 happens when step 4 takes longer than Nginx is configured to wait. The default timeout is typically 60 seconds. If PHP-FPM hasn’t responded by then, Nginx returns a 504 to the visitor and closes the connection.
The PHP-FPM process may still be running in the background after Nginx gives up. It does not know Nginx stopped waiting. This is why you sometimes see partial database writes or incomplete operations during a 504.
Common causes
1. A slow or stuck PHP process
The most common cause. A PHP script is taking too long to execute. This can happen because:
- A database query is running slowly due to missing indexes or a large table scan
- An external API call (payment gateway, email service, third-party webhook) is timing out or responding slowly
- A WordPress plugin is doing something expensive – importing data, running a bulk operation, generating a report
- A loop or recursion in PHP code is taking longer than expected
In these cases, the PHP process is genuinely busy. It is doing work, just slowly. Nginx runs out of patience and returns the 504 before PHP finishes.
2. PHP-FPM pool exhaustion
PHP-FPM maintains a pool of worker processes. Each incoming request occupies one worker until the request completes. The pool has a maximum size.
If your site receives more concurrent requests than there are available workers, new requests queue up waiting for a free worker. If a worker does not free up before the timeout expires, Nginx gets a 504.
This typically happens under sudden traffic spikes, during bot attacks hammering PHP endpoints, or on sites with slow pages that hold workers for a long time.
3. Database connection issues
PHP-FPM is waiting for MySQL, and MySQL is slow or unresponsive. This can happen because:
- The database server is under heavy load from another process
- A long-running query is holding a table lock that other queries are waiting on
- The MySQL connection pool is exhausted
- The database server restarted and connections are being re-established
From Nginx’s perspective, this looks the same as any slow PHP process. The request is forwarded, and nothing comes back.
4. Upstream connection failures
If PHP-FPM crashes, restarts, or its socket becomes unavailable, Nginx cannot establish the upstream connection at all. Depending on configuration, this may return a 502 Bad Gateway instead of a 504, but the symptoms and diagnosis overlap.
How to diagnose a 504
Check your Nginx error log
The error log is the first place to look. A 504 will appear as an entry like:
upstream timed out (110: Connection timed out) while reading response header from upstreamor
upstream timed out (110: Connection timed out) while connecting to upstreamThe difference matters. “While reading response header” means Nginx connected to PHP-FPM successfully but PHP-FPM never sent a response back. The PHP process is running but slow. “While connecting to upstream” means Nginx could not even reach PHP-FPM – the socket or port is unavailable.
On Hostney, your Nginx error log is available from the control panel under Logs & statistics > Error logs. Look for entries timestamped around the time you saw the 504.
Check your PHP error log
If the timeout is caused by a PHP error or exception, it will appear in the PHP error log, not the Nginx log. Look for fatal errors, exceptions, or warnings that correlate with the time of the 504.
On Hostney, PHP logs are available under Logs & statistics > PHP logs in the control panel.
Identify which page is timing out
The Nginx error log includes the request URI that timed out. If the 504 is happening on a specific page or endpoint (an admin action, a form submission, a specific URL), that narrows down which plugin or code is responsible.
If the 504 is happening across the entire site, the problem is more likely PHP-FPM pool exhaustion or a database issue rather than a specific slow script.
Fixing a 504
If a specific page or action is timing out
The underlying problem is that a PHP script is taking too long. The fix depends on what the script is doing:
Slow database queries: Use a query monitor plugin like Query Monitor to identify which queries are slow. Add database indexes where missing. Avoid queries inside loops.
External API calls: If your site calls a third-party API (payment processor, email service, social media), and that API is slow, the request will hang waiting for a response. Add timeouts to your API calls so PHP fails fast instead of waiting indefinitely. Most WordPress HTTP API calls support a timeout parameter.
Heavy plugin operations: Bulk imports, CSV exports, image regeneration – anything that processes large amounts of data in a single request. Break these into smaller batches, or run them via WP-CLI from the command line where there is no web timeout.
WooCommerce or form submissions: These are common timeout sources because they involve database writes, email sending, and sometimes payment API calls all in a single request. Identify which step is slow using the PHP log.
If the 504 is happening across the whole site
This points to a resource constraint rather than a single slow script.
Check whether the 504 correlates with high traffic, a bot attack, or a specific time of day. If bots are hammering your site and consuming PHP workers, stopping the bot traffic is the fix – not adjusting timeouts. On Hostney, the firewall section in the control panel shows active bot activity.
If you are on a shared hosting plan and regularly hitting resource limits under normal traffic, a plan upgrade may be necessary.
If the 504 is intermittent and hard to reproduce
Intermittent 504s are often caused by a slow external service that the site depends on. A payment gateway that occasionally takes 30 seconds to respond. A CDN origin pull that times out under load. A DNS lookup that intermittently stalls.
Correlate the timestamps in your Nginx error log with any external services your site uses. If the pattern matches, the fix is on the external service side – add fallbacks, increase local caching, or switch providers.
A note on timeout settings
Nginx has several timeout directives that control how long it waits for an upstream response:
-
proxy_read_timeout– how long to wait for data from the upstream after the connection is established -
proxy_connect_timeout– how long to wait to establish the connection -
fastcgi_read_timeout– specific to FastCGI (PHP-FPM) connections
PHP-FPM also has its own
request_terminate_timeout
which kills PHP workers that run too long.
On Hostney, Nginx configuration is fully managed. If you have a legitimate use case that requires a longer timeout – a bulk data import, a video processing script, a long-running report – contact support and we can adjust the timeout for your specific configuration. Increasing timeouts globally is not recommended because it allows slow scripts to hold PHP workers longer, which can make pool exhaustion worse under load.
When to contact support
If you have checked the error log, identified that the 504 is not caused by a specific slow script, and the problem persists, contact support with:
- The timestamp of the 504
- The URL that timed out
- What the page was doing (submitting a form, loading the admin, running an import)
- The relevant lines from your error log
This gives support enough context to investigate the server-side resource picture and identify whether the issue is at the PHP-FPM level, the database level, or somewhere else.
Summary
A 504 Gateway Timeout in Nginx means the upstream service (PHP-FPM) did not respond within the allowed time. The most common causes are slow PHP scripts, external API calls that hang, PHP-FPM pool exhaustion under high load, and database bottlenecks.
Start with the error log to identify whether the timeout is on a specific request or system-wide. Check the PHP log for errors in the script itself. If the problem is a specific slow operation, fix the underlying script. If it is system-wide, look at traffic patterns and resource usage.
On a managed hosting platform, server-level timeout configuration is handled for you. The fix is almost always in the application – the slow query, the hanging API call, the plugin doing too much in a single request.