How to Fix a 504 Gateway Timeout Error on Your WordPress Site
Updated on June 12, 2018
There’s nothing more worrisome and frustrating than browsing to your WordPress site and encountering a white screen with an error. Some common ones you might have experienced in the past include 502 bad gateway errors, the ever so popular white screen of death, or the frightening error establishing a database connection. For many blogs and ecommerce sites, these errors result in the loss of revenue from visitors instantly bouncing and customers unable to complete their purchases. Today we want to dive into the 504 gateway timeout error and some recommendations on how to fix it on your WordPress site. Read more below about what causes this error and what you can do to prevent it in the future.
Before diving into the error itself, it’s important to understand how they are generated. Whenever you launch your browser and visit a website it sends a request back to the web server it is hosted on. The web server then processes the request and sends back the requested resources along with what they call an HTTP header. This HTTP header contains one of many HTTP status codes to communicate whether everything is OK or if something has gone wrong. Not all HTTP status codes are bad. For example, a 200 status code means “Everything is OK.”
There are many different types of 500 status error codes (500, 501, 502, 503 504, etc) which all have different meanings. These indicate that the request was accepted, but the server prevented the fulfillment of the request.
In this case, a 504 gateway timeout error means that “the server, acting as a gateway, timed out waiting for another server to respond.” The code returns when there are two servers involved in processing a request, and the first server times out waiting for the second server (upstream server), to respond (RFC 7231, section 6.6.5).
504 gateway timeout error in the browser
504 Gateway Timeout Error Variations
Due to all the different web browsers, operating systems, and servers, a 504 gateway timeout error can present itself in a number of different ways. They all typically have the same meaning though. Below are just a few of the many different variations you might see pop up:
“504 Gateway Timeout”
“504 Gateway Timeout NGINX”
“NGINX 504 Gateway Timeout”
“Gateway Timeout Error”
“HTTP Error 504”
“HTTP Error 504 – Gateway Timeout”
“Gateway Timeout (504)
“504 Gateway Time-out – The server didn’t respond in time”
A blank white screen
504 Errors Impact on SEO
Unlike 503 errors, which are used for WordPress maintenance mode and tell Google to check back at a later time, a 504 error can have a negative impact on SEO if not fixed right away. If your site is only down for say 10 minutes and it’s being crawled consistently a lot of times the crawler will simply get the page delivered from cache. Or Google might not even have a chance to re-crawl it before it’s back up. In this scenario, you’re completely fine.
However, if the site is down for an extended period of time, say 6+ hours, then Google might see the 504 error as a site level issue that needs to be addressed. This could impact your rankings. If you’re worried about repeat 504 errors you should figure out why they are happening to begin with. Some of the solutions below can help.
How to Fix the 504 Gateway Timeout Error
Where should you start troubleshooting if you see a 504 gateway timeout error on your WordPress site? Without a great deal of context, it can sometimes be frustrating and overwhelming where to even begin. Typically these are network connectivity issues and or problem with the server at which the site is hosted. However, it can also be a client-side issue, or even a result of a third-party plugin. So we’ll dive into a little of both. Check out these common causes and ways to fix the 504 gateway timeout error and get back up and running in no time.
1. Try Reloading the Page
One of the easiest and first things you should try when encountering a 504 bad gateway error is to simply wait a minute or so and reload the page (F5 or Ctrl + F5). It could be that the host or server is simply overloaded and the site will come right back. While you’re waiting, you could also quickly try a different browser to rule that out as an issue.
Another thing you can do is to paste the website into downforeveryoneorjustme.com. This website will tell you if the site is down or if it’s a problem on your side. A tool like this checks the HTTP status code that is returned from the server. If it’s anything other than a 200 “Everything is OK” then it will return a down indication.
2. Disable Proxy Settings
Sometimes you might see a 504 error if you are utilizing a proxy service. This is usually pretty rare, especially on the client-side. However, one might have been set without you even knowing it. Follow these tutorials on how to disable or check to ensure no proxy settings are enabled:
A 504 gateway timeout could also be because of a DNS issue. There are two sides to this, the first is on the server-side, such as the domain is not resolving to the correct IP. If you have just migrated your WordPress site to a new host, is it important to wait for things to fully propagate, which can take up to 24 hours in some cases. This depends upon the TTL value of your DNS records. You can use a free tool like DNSMap to check and see if your DNS has propagated around the globe.
Check DNS propagation
The second is a DNS issue on the client-side. In which case you could try flushing your local DNS cache. This is similar to clearing your browser cache.
In Windows simply open up Command Prompt and enter the following:
You should see a “Successfully flushed the DNS resolver Cache” if it worked.
For macOS users, you can enter the following in the terminal:
Note: There is no success message on Macs.
And lastly, you could temporarily change your client-side DNS servers. By default, DNS servers are automatically assigned by your ISP. But you could try temporarily changing these to a public DNS server, such as Googles. In fact, some prefer to use Google’s public DNS long-term due to them sometimes being more reliable.
4. Temporarily Disable CDN
It could also be an issue with your content delivery network (CDN). If you are using a third-party CDN provider an easy way to troubleshoot this is to simply disable your CDN temporarily. For example, we are big fans of the free CDN enabler plugin. If you are using that, you can simply deactivate the plugin and then test your site. If you can’t access your site’s dashboard, simply log in to your site via SFTP and rename the plugin’s folder to cdn-enabler_old. This will temporarily disable the CDN connection. The same goes for WP Rocket or any other plugin you might have hooked up to your CDN.
This can also occur sometimes with fully proxy services like Cloudflare or Sucuri, as they have extra firewalls in-between. Most of them actually cache 500 status codes when they are returned by your origin server. We have noticed that this happens once in a while on the Cloudflare free plan. Unfortunately, since Cloudflare is a fully proxy service, there is no quick way to simply disable it.
However, before you go pointing the finger at Cloudflare, it’s important to know that there are two different types of 504 gateway timeout variations as seen below:
504 Gateway Timeout at Cloudflare (Variation 1)
If you see the following screen, this is actually a problem on Cloudflare’s end, in which case you should reach out to them for support. Or check their status page. Most likely they are already aware of the issue and have their team working on it.
Cloudflare 504 gateway timeout
504 Gateway Timeout at Cloudflare (Variation 2)
If you see the following screen, this is a problem with your WordPress host (origin server), in which case you’ll want to skip down to recommendation #5 below.
Cloudflare 504 gateway timeout error at host
504 Gateway Timeout at Cloudflare with Uploads
Another reason for a timeout could be related to the size of your uploads. They do restrict POST (uploads) to 100MB on their free plan. However, we have occasionally seen clients have issues with files or uploads smaller than this. Sometimes this problem can be on your host’s end or Cloudflare. An easy way to determine which is simply is by bypassing Cloudflare with your DNS hosts file and trying your upload again. Or simply disable Cloudflare temporarily.
A server issue is one of the most common reasons users experience 504 gateway timeout errors on their WordPress sites. To put it layman’s terms, Nginx or Apache is waiting on a response from something and it timed out. We get a lot of clients that come to Kinsta due to the fact that they were constantly receiving these at other WordPress hosts. Here is an example of a conversation we receive on a regular basis.
We’re getting around 100k visitors per month with more than 200k views. We’re currently hosting with ____ and recently we experienced 504 errors due to server overload. I don’t like how ____ handled the problem and we were also advised that we will have to move to their dedicated plans soon, which I believe is not necessary.
504 errors do more often occur on high-traffic and ecommerce sites such as WooCommerce that have a lot of uncachable requests, as they sometimes can cause a server overload. However, we’ve seen these errors with all types of sites, even with simple blogs. Many hosts will simply reply back saying that you are required to upgrade to a high-tier plan to fix the issue. And while this most likely will get rid of most 504 gateway timeout errors, and is sometimes required, it’s not always necessary.
Here at Kinsta, we utilize LXD managed hosts and orchestrated LXC software containers for each site. This means that every WordPress site is housed in its own isolated container, which has all of the software resources required to run it (Linux, Nginx, PHP, MySQL). The resources are 100% private and are not shared with anyone else or even your own sites. Many shared WordPress hosts don’t have this capability and therefore a high-traffic neighboring site causing 504 gateway timeout errors, could very well impact your site.
Not only are your sites isolated, but our infrastructure was built to easily handle thousands of concurrent connections. Even MySQL databases are hosted at localhost, not a remote server. This ensures that there is no latency between machines, which results in faster queries and less chance of timeouts occurring anywhere in-between. Many clients who migrate to Kinsta see huge decreases in overall load times.
Besides server timeouts due to server load, here are few other reasons a server could be experiencing a 504 error:
Slow server: It could very well be the server your WordPress site is on is simply too slow to respond to the request and therefore it generates gateway errors.
Not enough PHP workers: PHP workers are used to execute the code on your WordPress site. On demanding sites it could very well be that all the PHP workers are busy, in which case they start to build up a queue. If the queue and backlog are full, old requests start to get disregarded. You can ask your host about increasing your number of PHP workers. Additional PHP workers per site allow for multiple requests to execute simultaneously.
Firewall issues: The firewall on your server could have some errors, an improper configuration, or rules preventing a connection from establishing properly.
Network connectivity: If there are problems with the network connection between the proxy server and the web server, it could cause delays in the response for the HTTP request. There could also be network connectivity issues with a load balancer if one is used.
It’s also important to note that 504 errors can deceptively look a lot like 503 service unavailable errors or even 502 bad gateway errors, but they are in fact different. You If you are experiencing a 504 error at Kinsta simply open a support ticket and we’ll get it fixed immediately. We also proactively monitor errors like these with New Relic, so more than likely our team is already investigating.
WordPress support ticket
If you are worried about these happening on your site in the future, you can also utilize a tool like updown.io to monitor and notify you immediately if they occur. It periodically sends an HTTP HEAD request to the URL of your choice. You can simply use your homepage. The tool allows you to set check frequencies of:
It will send you an email if and when your site goes down. Here is an example below.
This can be especially useful if you’re on a shared host, who tend to overcrowd their servers. This can give you proof of how often your site might actually be doing down (even during the middle of the night). That’s why we always recommend going with a managed WordPress host. Make sure to check out our post that explores the top 9 reasons to choose managed WordPress hosting.
6. Spam, Bots, or DDoS Attack
It very well could be that your site is getting spammed by bots or is undergoing a DDoS attack. Sometimes these can result in uncached requests and could overwhelm the server resulting in 504 gateway timeout errors. You can take a look at your server analytics and see if you can spot any patterns. Here at Kinsta, we provide this data in our MyKinsta analytics tool. You could also ask your host for this data. The first report we recommend looking at is the top client IPs. This can be very helpful if your site is suddenly generating a lot of bandwidth or getting hit by bots.
Security metrics top client IPs
The second report we recommend looking at is the requests & bots. You can quickly spot the ratio of how many humans are hitting your site vs crawlers or bots. Remember though, not all bots are bad. GoogleBot is an example of one you don’t ever want to block due to the fact that it crawls your site to index content in SERPs.
Requests and bots
The third report we recommend looking at is the cache analysis. Here you can see how many requests are bypassing the cache, missing the cache, and the top locations on your site. For performance and stability reasons, you want as many requests to be cached as possible. This is not always possible though as sites such as those running WooCommerce generate a lot of un-cachable requests, and have to for features as the shopping cart and checkout process to work correctly and stay in sync.
If you spot and or identify traffic/IPs that should be blocked on your site, you can use a WordPress security plugin to help. However, if you’re a Kinsta customer we typically don’t allow security plugins for a couple reasons. First of all, they can have a huge effect on your performance, especially the scanning capabilities. Second, we utilize load balancers with Google Cloud Platform, which means a lot of time their IP blocking functionality wouldn’t work as intended.
Of course, IPs can always be blocked by our Kinsta support team, but depending upon the length and scale of the attack, this could be a never-ending process of blacklisting IPs, which in most cases doesn’t solve the problem fast enough. A lot of attacks or spamming when blocked in one area, will simply pop up in another, or change IPs and proxy addresses. So in this instance, we recommend that the client utilize a security solution such as Cloudflare or Sucuri.
Many might say that third-party plugins or themes don’t cause 504 gateway timeout errors. And in most cases, they don’t. However, in our experience, a slow uncached request from a plugin can indeed result in delays as this ties up more of your PHP workers. Once you’ve reached your limit of PHP workers, the queue starts to push out older requests which could result in 504 errors. This is not to be confused with 502 gateway errors in which the error occurs after a timeout of 60 seconds in the queue.
A few ways you can troubleshoot this is by deactivating all your plugins. Remember, you won’t lose any data if you simply deactivate a plugin. If you can still access your admin, a quick way to do this is to browse to “Plugins” and select “Deactivate” from the bulk actions menu. This will disable all of your plugins.
If this fixes the issue you’ll need to find the culprit. Start activating them one by one, reloading the site after each activation. When you see the 504 gateway timeout return, you’ve found the misbehaving plugin. You can then reach out to the plugin developer for help or post a support ticket in the WordPress repository.
If you can’t access your admin you can FTP into your server and rename your plugins folder to something like plugins_old. Then check your site again. If it works, then you will need to test each plugin one by one. Rename your plugin folder back to “plugins” and then rename each plugin folder inside of if it, one by one, until you find it. You could also try to replicate this on a staging site first.
Always makes sure your plugins, themes, and WordPress core are up to date. And check to ensure you are running a supported version of PHP. You can always reach out to your host for assistance. We utilize New Relic and other troubleshooting methods here at Kinsta to help clients narrow down what plugin, query, or script might be causing the error. You can also use your own custom New Relic key.
If it turns out to be an efficient query or bad code in a plugin, you might need to bring in a WordPress developer to fix the issue.
8. Check Logs
You should also take advantage of your error logs. If you are a Kinsta client, you can easily see errors in the log viewer in the MyKinsta dashboard. This can help you quickly narrow down the issue, especially if it’s resulting from a plugin on your site.
Check error logs for 502 bad gateway errors
If your host doesn’t have a logging tool, you can also add the following code to your wp-config.php file to enable logging:
You can also check the log files in Apache and Nginx, which are commonly located here:
If you are a Kinsta client you can also take advantage of our analytics tool to get a breakdown of the total number of 504 errors and see how often and when they are occurring. This can help you troubleshoot if this is an ongoing issue, or perhaps something that has resolved itself.
9. Nginx Settings
If you are managing your own server and WordPress sites on Nginx + FastCGI (php-fpm) or Nginx as proxy for Apache, there are some additional settings you can change to help prevent 504 gateway timeout errors.
504 Gateway Timeout Error on Nginx + FastCGI (php-fpm)
If you are using Nginx with FastCGI (php-fpm) then you’ll need to first make a change to your PHP-FPM file. Navigate to /etc/php5/fpm/pool.d/www.conf (may vary based on PHP version). Set the following directive:
request_terminate_timeout = 300
Next, you must change your php.ini file, which is typically located at /etc/php.ini. Search for the max_execution_time directive. Increase the value to 300, if the directive is not already present, then add it:
max_execution_time = 300
Lastly, you’ll need to modify your nginx.conf file. Add the following inside your Nginx virtual host configuration.
As you can see, there is a multitude of different ways to troubleshoot and fix 504 gateway timeout errors on your WordPress site. Typically these are a server issue, in which case you can quickly reach out to your host to get it resolved. But it’s also important to understand they can actually be caused by third-party plugins or overwhelming your PHP workers queue/backlog.
If you are indeed maxing out your PHP workers, we recommend reaching out to our support here at Kinsta or hire a WordPress developer who specializes in web performance optimization. If after digging into your site you discover that your plugins, theme, and queries are fine, it might very well be that you do need to upgrade your plan or number of PHP workers.
Was there anything we missed? Perhaps you have another tip on troubleshooting 504 gateway timeout errors. If so, let us know below in the comments.
Brian is the Chief Marketing Officer at Kinsta. He focuses on everything from developing new online growth strategies, content creation, technical SEO, and outreach within the community. He has a huge passion for WordPress, has been using it for 8+ years, and even develops a couple premium plugins. Brian enjoys blogging, movies, and hiking. Connect with Brian on Twitter.
Kinsta is a premium hosting platform optimized specifically for WordPress, created by WordPress professionals.
A cookie is a piece of information that a website stores on a visitor’s computer. We use this for some functionality on our website to work properly, and also to collect analytics to better understand our visitors and offer them a better experience. You can accept all cookies at once or fine-tune your preferences in the cookie settings.
Thanks, we've saved your settings, you can modify them any time on the cookie settings page
These cookies are needed for our website to function providing payment gateway security and ther essentials. Therefore they are always on but they do not contain personally identifiable information (PII).
If you've set preferences (which cookies you accept and which you don't) we store your preferences here to make sure we don't load anything that you didn't agree to.
WordPress sets a couple of cookies that track logged in users and store user preferences set in their WordPress user profile. These are set for members of the Kinsta website only - members of our staff.
Stripe is our payment provider and they may set some cookies to help them with fraud prevention and other issues. This is required for our payments to work.
This cookie contains information about the affiliate who refered a visitor. The cookie contains no information about the visitor whatsoever.
Analytics help us deliver better content to our audience. We have made sure no personally identifiable information (PII) is sent by anonymizing IPs.
Analytics cookies allow us to gather data to help us better understand our visitors and offer them a better experience.
Set and used by Hotjar. We use Hotjar to analyze user behavior without identifying the user.
Marketing cookies help us target our ads better. We mainly use them to target ads to users who have visited Kinsta.
Set and used by Twitter, used for targeting advertisements and promoting content to users who have visited kinsta.com.
Set and used by AdRoll for remarketing and targeting advertisements to users who have visited kinsta.com.
Set and used by Facebook, used for targeting advertisements and promoting content to users who have visited kinsta.com.
Set and used by Quora, used for targeting advertisements to users who have visited kinsta.com.