Troubleshooting gateway errors and timeouts: 502, 504

Sometimes when you’re receiving constant Gateway errors, you are unable to access your website’s admin area (like WordPress’s wp-admin), yet you find you need to do so to help troubleshoot this issue. The only way to regain access is to block access until you can get the issue resolved.

To block access, you can proceed in one of two ways: 1) block access to the particular part of the site that’s eating up resources, or 2) you can block access to all IPs except your own temporarily to regain access.

To block access to all IPs except your own (easier)

Login to Plesk and visit the apache & nginx settings page. Under “Deny access to the site” enter a custom value and make it "*“ (without the quotes). Then under “Excluding” enter your own IP address and save the changes. You may need to wait up to 3 minutes after saving your changes for the server to restart (~1m) and for any PHP processes that were running to reach their timeout (~2m).

Be sure to remove this block when you’re done troubleshooting.

To block access to the resource intensive request (more complex)

If there’s only one page or resource on the site that’s creating this problem (like a single page that loads slowly), use the logs to identify that particular request URI. Then add the following code snippet to the top of your .htaccess file to block the problematic resource (even just temporarily) so you can access the admin panel. Replace filename\.php with the actual request URI shown in the logs (this is the part that comes after the domain). If there are dots in the file path be sure to prepend them with a backslash as seen in the example.

<FilesMatch filename\.php>
Order Allow,Deny
Deny from all
</FilesMatch>

If you do not currently use a page caching plugin like WP Super Cache (free) or WP Rocket (paid), installing and activating an optimization plugin will very likely resolve this issue.

If you’re not using WordPress, look for the option to enable page caching and/or object caching in your content management system.

Caching solutions save the contents of each page as a simple text file so they do not need to be dynamically generated each time. This single change can take a site from a 10 active user max to thousands.

If your site is running normally, but every time you try to run a large export, import, or report for your site’s data, you get gateway errors, this is because you’re reaching timeouts before the report can be processed. Although there’s no super simple way to fix this long term, there is a way to fix it short term: temorarily increase the timeouts.

You can do this in Plesk control panel by following the steps in our guide on how to change a PHP setting. You will need to change the values (they’re in seconds) for max_execution_time and max_input_time to something like 300 to allow processes to run for 5 minutes. Do not forget to change those values back after you have completed your long-running action.

Why can’t you just increase the timeouts permanently?

Technically you can, however increasing timeouts permanently will very likely detrimentally affect the performance of your site. Timeouts default to values like 30 or 60 seconds with intention: if a process takes that long to complete, and you trigger too many long running processes, they can eat up all available processing slots and bring your entire site down for all visitors. Therefore keeping your timeout values around 30-60s ensures this can only happen for at most that amount of time.

You’ll know if this is the issue if one or more pages on the site take longer than ~10s to even begin loading, with your browser showing nothing until that 10+ second period has passed.

There are two common reasons this can occur:

1) Code Performance Issues: you’ve got some code running on the site that is not optimized for performance or having a problem. An example of this would be an infinite loop in the code, or something that tries to pull millions of database records in one query (rather than retrieving them in batches). The first thing to check is any code that has been recently added to the site, like plugins, a new theme, custom code, etc. You’ll probably want to get your developer involved to help narrow this down. We have a KB article with some commonly recognized versions of this, however if you’re not able to determine the cause with those suggestions, then your remaining option is exhaustive troubleshooting. We have a guide to exhaustive troubleshooting with WordPress here.

2) Slow or Non-Responding External Resource Requests: Some PHP code is trying to communicate with an external resource (hosted elsewhere) that’s taking too long to respond or not responding at all. To solve issues with External Resources, you’ll need to look into what parts of your website’s PHP code (custom code or plugins/theme code) are trying to retrieve external resources. This is most commonly code that connects to a 3rd party service like a payment processor or weather data retrieval via an API or scraping. Here’s a few examples:

• Some payment gateways, or XML API services use non-standard ports (though it’s very uncommon these days as standard ports are used far more frequently now). If it’s not using port 80 or 443, it’s likely trying to communicate on a blocked port and failing.
• Older twitter widgets have been known to retrieve tweets using back-end code and then failures to connect to the Twitter servers cause hang-ups like this. This does not apply to Twitter’s own feed embeds that operate via Javascript asynchronously.

If you’re using WordPress or any other CMS with plugins, be sure to try disabling any plugin that might communicate externally to see if it solves the problem.

If you’re not able to determine which plugin might be at fault intuitively, then your remaining option is exhaustive troubleshooting. We have a guide to exhaustive troubleshooting with WordPress here.

If you use JetPack Boost or Hummingbird, try disabling it. These optimization plugins put heavy load on the server by still requiring a PHP process for each page request.

Instead, we recommend trying WP Super Cache or WP Rocket as per our guide to improving WordPress performance performance as these plugins allow bypassing PHP altogether for most page requests.

Apache or PHP processes may be generating larger data sizes than nginx is allowed to process. Since apache and PHP both need to pass this data through nginx to reach the website visitor, it generates a 502 error indicating “Upstream sent too big header”. We’ve seen this error with customers using the WordPress plugin OptInMonster, however any software could do it.

Our shared hosting should already be optimized with larger buffers for nginx, however if you have your own VPS, or are not hosted with us, you’ll need to apply these values yourself to the nginx configuration:

fastcgi_buffers 128 4096k;
fastcgi_buffer_size 4096k;

This tells nginx that it’s okay for it to accept large (4MB) headers. You can insert these into a file like: /etc/nginx/conf.d/increase_buffers.conf then restart nginx to apply the changes. Example:

echo 'fastcgi_buffers 128 4096k;
fastcgi_buffer_size 4096k;' > /etc/nginx/conf.d/increase_buffers.conf

Sometimes if you’re getting constant Gateway Timeout errors, and the only thing that clears them up is restarting PHP (as described above), or if you’re on a VPS and you see your PHP processes staying running at high CPU and lasting far longer than they should (or you’ve been told that’s what is happening by server techs), you will need to take some steps to rein them in.

Note: if you’re on our shared hosting, our PHP-FPM configuration is already optimized for a shared hosting environment and so if you’re experiencing gateway errors, this solution will not apply.

The following are some options that have worked for us, however it’s super important to note that these are workarounds to the real issue. Identifying the code that isn’t responding fast enough, and optimizing its performance is the true solution.

1. PHP-FPM allows you to tune the PHP Process Manager (FastCGI Process Manager = FPM) by making some changes in Plesk. If you’re using the “ondemand” style PHP-FPM process, you may want to reduce the number of requests each process handles before gracefully exiting / restarting a new process. This is labelled as pm.max_requests. Try 100 or 150 if you’re having performance issues
2. If your PHP processes aren’t dying off, you may need to *make* them die. There’s a couple good ways to do this. First is to definitely set an idle timeout for the PHP-FPM processes by setting pm.process_idle_timeout – try setting it to 10s (you can do this in the field below the FPM settings.
3. If your PHP processes still aren’t dying off, you may need to get even more aggressive with them. Try setting request_terminate_timeout to a few seconds higher than your max_execution_time setting. If max_execution_time doesn’t kill off the process, request_terminate_timeout certainly will.