Fix 504 Gateway Timeout on Nginx and WordPress

A 504 Gateway Timeout on Nginx and WordPress means your web server waited too long for a response from a backend service (usually PHP-FPM) and gave up. This usually happens during heavy traffic, slow plugins, or misconfigured timeouts. This guide walks you through the most effective fixes, from quick configuration changes to deeper optimizations, so you can restore your site’s reliability.

What You’ll Need

• SSH (terminal) access to your server
• Sudo or root privileges
• Basic familiarity with the command line
• Text editor (nano, vim, or similar)

Step-by-Step

1. Identify the Slow Component

First, confirm that Nginx is actually timing out. Check the Nginx error log (usually /var/log/nginx/error.log) for lines containing upstream timed out or 504. This tells you the upstream (PHP-FPM or another proxy) is not responding in time. Also check the PHP-FPM log (often /var/log/php-fpm.log or /var/log/php7.4-fpm.log) for slow or stalled requests.

2. Increase Nginx Timeout Settings

Edit your Nginx site configuration (usually in /etc/nginx/sites-available/). Inside the location ~ \.php$ block, add or modify these directives:

proxy_connect_timeout 75s;
proxy_send_timeout 300s;
proxy_read_timeout 300s;
fastcgi_connect_timeout 75s;
fastcgi_send_timeout 300s;
fastcgi_read_timeout 300s;

Also add fastcgi_buffers 8 16k; and fastcgi_buffer_size 32k; to prevent buffer-related timeouts. After saving, test the config with nginx -t and reload with systemctl reload nginx.

3. Increase PHP-FPM Timeout Settings

Edit the PHP-FPM pool configuration (e.g., /etc/php/7.4/fpm/pool.d/www.conf). Look for request_terminate_timeout and request_slowlog_timeout. Set them to a higher value, like 300 seconds, or comment them out to disable. Also set max_execution_time in your php.ini to 300. Then restart PHP-FPM: systemctl restart php7.4-fpm (adjust the version).

4. Optimize WordPress for Slow Requests

If the timeout happens only on certain pages, it’s likely a slow plugin or theme. Temporarily disable all plugins via WP-CLI or by renaming the wp-content/plugins folder. If the site loads, re-enable plugins one by one to find the culprit. Also switch to a default theme (like Twenty Twenty-Four) to rule out theme issues. Clear any caching plugins and server-side caches (Redis, Varnish).

5. Increase PHP-FPM Pool Resources

If you have many concurrent requests, PHP-FPM might be exhausted. In www.conf, adjust pm.max_children, pm.start_servers, pm.min_spare_servers, and pm.max_spare_servers based on your server’s RAM. A common starting point for a 2GB server is pm.max_children = 20. Restart PHP-FPM after changes.

6. Enable PHP-FPM Status and Slow Log

To diagnose which script is slow, enable the status page in www.conf by setting pm.status_path = /status and slowlog = /var/log/php-fpm-slow.log. Then configure an Nginx location for /status to access it. Also set request_slowlog_timeout = 10s to log any request taking longer than 10 seconds. Check the slow log to see exact PHP files and lines causing delays.

7. Check External HTTP Calls

WordPress plugins often make external HTTP requests (e.g., license checks, API calls). If those external servers are slow, they can block PHP execution. Use a plugin like Query Monitor to identify slow HTTP calls, or temporarily disable suspicious plugins. You can also increase WordPress’s HTTP timeout by adding to wp-config.php:

define('WP_HTTP_BLOCK_EXTERNAL', true);

(This blocks all external calls – only use temporarily for testing).

8. Increase Server Resources or Optimize

If none of the above helps, your server may simply lack CPU or RAM. Check free -m and top to see usage. Consider upgrading your hosting plan, or optimize by enabling opcode caching (like OPcache), adding a page cache (like WP Super Cache or W3 Total Cache), and using a CDN.

9. Restart Services

After all changes, restart both Nginx and PHP-FPM to apply everything: systemctl restart nginx and systemctl restart php7.4-fpm. Then test your site.

Common Mistakes

• Only increasing Nginx timeouts – if PHP-FPM itself is stuck, Nginx will still timeout eventually. Always adjust both.
• Setting timeouts too high – a 504 after 5 minutes is better than a 504 after 30 seconds, but if a script is truly broken, it will just hang longer. Use slow logs to find the root cause.
• Ignoring PHP-FPM pool settings – if max_children is too low, requests queue up and time out. If too high, you run out of memory.
• Not checking the logs – guessing without logs wastes time. Always start with error logs.
• Disabling all plugins permanently – that’s a diagnostic step, not a fix. Re-enable them one by one.

Tips

• Use a staging environment to test changes before applying to production.
• Set up monitoring (like UptimeRobot or New Relic) to alert you when 504s occur.
• Regularly update WordPress core, themes, and plugins – outdated code is often slow.
• Consider using a lightweight theme and avoiding heavy page builders if you’re on a small server.
• If you’re on shared hosting, contact your provider – they may have specific limits or already have optimized settings.

Troubleshooting

If the 504 still appears after following steps:

1. Check the Nginx error log again – is the timeout still from upstream? If yes, PHP-FPM is still not responding.
2. Check if PHP-FPM is even running: systemctl status php7.4-fpm. If it’s crashed, look at its log for fatal errors.
3. Try accessing a simple PHP file (e.g., phpinfo.php) directly. If that times out too, the problem is PHP-FPM itself, not WordPress.
4. If only WordPress pages time out, but static files load fine, it’s definitely PHP execution. Use the slow log to pinpoint the exact plugin/theme function.
5. Check for resource exhaustion: free -h and df -h. If RAM or disk is full, that can cause hangs.
6. If you’re using a proxy like Cloudflare, check its error logs – sometimes the 504 comes from the proxy, not your server.
7. As a last resort, temporarily increase fastcgi_read_timeout to 600s to see if the request eventually completes – that confirms it’s a slow script, not a dead one.

Frequently Asked Questions

Why do I get a 504 only during peak hours?

Peak traffic means more concurrent PHP-FPM workers. If your pool’s max_children is too low, requests queue up and wait, eventually exceeding the timeout. Increase the pool settings or add more server resources.

Can a plugin really cause a 504?

Yes. Plugins that make external API calls, run complex database queries, or have memory leaks can hang PHP-FPM. Use the slow log to identify which plugin file is slow.

What’s the difference between 502 and 504?

A 502 Bad Gateway means Nginx received an invalid response from PHP-FPM (e.g., it crashed). A 504 means Nginx didn’t receive any response within the timeout period. Both point to PHP-FPM issues, but 504 is specifically about timing.

Should I set timeouts to 0 (unlimited)?

No. That can allow a malicious or broken script to hang your server indefinitely. A reasonable high value (300s) is safer. If a legitimate request takes longer than 5 minutes, you should optimize it instead.

Will upgrading my hosting plan fix the 504?

Sometimes, if the issue is resource exhaustion. But if the problem is a poorly coded plugin, more resources just delay the inevitable. Always diagnose first.

How do I check my current timeout values?

Run nginx -T | grep timeout to see Nginx settings, and php -i | grep max_execution_time for PHP. For PHP-FPM, check the pool config file directly.

Related

• AI Boom vs. Dot-Com Crash: What Developers Should Watch
• AI Agent Harness vs Framework: What’s the Difference?
• OpenAI Decisions API: Practical Implementation Guide