A 504 gateway time out in WordPress is one of the most frustrating errors you will encounter on a production server. Here is what catches developers off guard: your frontend web server, usually Nginx, waited too long for an upstream response from PHP-FPM or Apache. This issue frequently strikes during heavy database queries, large plugin updates, or poorly optimized REST API calls. If you have ever stared at a blank screen wondering how to fix 504 gateway time out in WordPress, you know it requires inspecting multiple layers of your LEMP stack.
Why the 504 Gateway Timeout Happens Under the Hood
Let us look at the request lifecycle. When a client requests a resource, Nginx proxies the execution to PHP-FPM via a Unix socket or TCP port. Nginx enforces a strict internal clock. If your script—such as a massive migration or an external API import—takes longer than that threshold, Nginx cuts the connection, drops the request, and throws a 504 error. A mistake I see developers make all the time in production is simply increasing PHP max execution time while ignoring the proxy timeout configurations in the server blocks. For related infrastructure edge cases, you can review our guide on 502 bad gateway wordpress nginx errors.
Before touching configuration files, always check your error logs. On an Ubuntu server running Nginx, your gateway logs live in /var/log/nginx/error.log. You will likely spot entries stating upstream timed out (110: Connection timed out) while reading response header from upstream. This tells you precisely that the upstream PHP process took longer than allowed.
How to Fix 504 Gateway Timeout by Adjusting Nginx and PHP-FPM
To solve this permanently, you must align your proxy timeouts across Nginx, your PHP-FPM pool configuration, and your WordPress application limits. Don’t just copy-paste this blindly—check your server config first. Let us walk through the exact configuration updates required to extend these limits safely.
nginx.confhttp { proxy_connect_timeout 300s; proxy_send_timeout 300s; proxy_read_timeout 300s; fastcgi_connect_timeout 300s; fastcgi_send_timeout 300s; fastcgi_read_timeout 300s; }
The snippet above forces Nginx to wait up to 300 seconds before dropping an upstream PHP-FPM connection. However, Nginx timeouts alone will fail if PHP-FPM kills the worker process first. You need to adjust your PHP-FPM pool settings. According to the official documentation at PHP.net, script execution limits are strictly controlled to prevent server resource starvation.
www.conf[www] request_terminate_timeout = 300 php_admin_value[max_execution_time] = 300
After modifying your PHP-FPM configuration pool, restart your services to apply the changes immediately. Run the systemctl reload commands via your terminal as shown below:
terminalsudo systemctl restart php8.2-fpm sudo systemctl reload nginx
If you are running resource-heavy plugins or dealing with database bloat, your site might also hit memory ceilings. Make sure to check our detailed walkthrough on fix php fatal error wordpress to ensure your memory limits match your new timeout configurations.
Comparative Analysis of Gateway Error Fixes
| Configuration Layer | Default Limit | Recommended Production Limit | Primary Impact |
|---|---|---|---|
| Nginx Proxy Read | 60s | 300s | Prevents premature proxy drop |
| PHP-FPM Terminate | 0 (off) | 300s | Kills runaway worker scripts |
| WordPress Memory | 256M | 512M | Prevents memory exhaustion |
| FastCGI Timeout | 60s | 300s | Extends socket waiting time |
Troubleshooting Edge Cases and Server Gotchas
Even after bumping your timeout values, you might still experience intermittent 504 errors. Here is what catches developers off guard: external HTTP calls made inside WordPress plugins. If a plugin makes a synchronous API request that hangs, PHP will stall until the request hits your newly configured 300-second limit, drastically slowing down your server throughput. Always review your server logs for slow database queries using tools like Query Monitor.
Another common culprit is aggressive reverse proxy caching or Cloudflare edge settings. Cloudflare enforces a strict 100-second timeout limit on HTTP requests. If your origin server takes longer than 100 seconds to respond, Cloudflare will return its own 504 gateway timeout page, regardless of what your Nginx config dictates. For web standards and protocol specifications, consult the MDN Web Docs.
Frequently Asked Questions
How to fix 504 gateway timeout on Nginx permanently?
You must increase both the Nginx proxy_read_timeout and the PHP-FPM request_terminate_timeout values inside your server configuration blocks, followed by restarting the services.
Is a 504 error caused by WordPress or the server?
It is fundamentally a server communication timeout, though it is often triggered by heavy database queries, unoptimized plugins, or slow external API requests originating from inside WordPress.
How do I fix timeout issues on mobile devices or browsers?
Browser caches or mobile network states do not cause 504 server timeouts. Clearing your browser cache or testing on mobile will not resolve this; the fix must be applied directly to your web server and PHP configuration.
