WordPress Stack Troubleshooting

You can use the WordPress Optimized platform to achieve excellent performance with a website by utilizing NGINX and PHP-FPM. However, some users may experience the occasional technical issue that can lead to frustration and time-consuming troubleshooting. A lack of familiarity with the underlying components can make this especially troublesome.

In this article, we explore the general troubleshooting procedures you can apply when tackling an issue with your WordPress Optimized hosting, as well as a list of common problems and their solutions. If you get stuck along the way, do not hesitate to reach out to our support team 24/7.

  • The information in this tutorial applies to InMotion Hosting products that use NGINX Caching, including our WordPress Hosting plans and certain VPS configurations.
  • We also reference various settings pertaining to the Cache Manager Plugin for cPanel. Please see our tutorial on the Cache Manager Plugin for more information.
  • For an in-depth explanation of how NGINX and the rest of the stack work together, please check out our WordPress Hosting Stack article.

Deciphering Common Error Codes

Below you will find a list of common HTTP status codes, typical triggering events, as well as tips on how to resolve or troubleshoot each issue. Resolving certain errors, such as the 502 or 503 errors, requires root-level access. Customers on our VPS or Dedicated platforms should reach out to our support team if unsure how to proceed. On our WordPress Hosting product, our systems team closely monitors the servers and typically resolve these issues quickly.

406 Not AcceptableA ModSecurity rule was triggeredEnsure that ModSecurity hits are not being cached (ModSecurity Response Cache Time under Advanced Options in the Cache Manager Plugin. This option is disabled by default.) Click here for more information on 406 errors.
429 Too Many RequestsTraffic to ratelimited URIs has exceeded the max number of requests per minuteNGINX has a rate-limiting feature that it can apply to URIs of your choice — typically to protect login pages and API endpoints. If you receive this 429 error, the number of requests from a single IP address has exceeded the threshold. If the traffic is legitimate, consider increasing the threshold under the Max requests per minute setting in the Cache Manager Plugin.
499 Client DisconnectedThe client disconnected before Nginx could send a replyThis error will only show up in the NGINX access log, and indicates that the client (such as a visitor to your webpage) terminated the connection before NGINX could send a response. If you see a lot of these, it typically indicates a long-running PHP process, perhaps due to a bad WordPress plugin.
500 Internal Server ErrorPHP script errors, database connection error, syntax error in htaccess files, and various other issuesCheck the Apache or PHP error log for more information, as a number of issues can cause this error.
502 Bad GatewayNGINX could not connect to ApacheCheck the NGINX error log (/var/log/nginx/error.log) for details, or just try restarting Apache/HTTPd via WHM or SSH. If you are not on a VPS or Dedicated Server plan (or if you are, and are unsure how to proceed), contact our support team for assistance.
503 Service UnavailableApache could not communicate with PHP-FPM, or the PHP-FPM pool is not able to spawn a worker to handle the request. Certain PHP scripts (such as WordPress) can also intentionally trigger this error to indicate to web crawlers that your site is in Maintenance Mode.On VPS or Dedicated Servers, try restarting PHP-FPM. For more information, you can find error logs at /opt/cpanel/ea-php*/root/usr/var/log/php-fpm/error.log. If you are not on a VPS or Dedicated Server plan (or if you are, and are unsure how to proceed), contact our support team for assistance. This error can also be triggered due to a low number of max PHP-FPM workers for the domain— check the PHP-FPM error log to confirm if this is the case.
504 Gateway TimeoutApache or PHP-FPM took too long to respondThis typically relates to a long-running PHP script. For example, attempting to perform a large import operation, big file upload, etc. By default, NGINX will wait up to 60 seconds for PHP and Apache to send back a response— if it does not receive anything in that time, it returns a 504 status. If you get this error and have not performed any sort of long-running operation, you may want to look at your plugins. Poorly-written plugins or long-running database queries can trigger this error since the page has to wait for these operations to complete before sending a response.
508 Resource Limit is ReachedYour account has hit a resource limit, and could not service the request.Use the Resource Manager plugin in cPanel (listed as CPU and Concurrent Connection Usage) to determine which limit your account reached and how. This error does not apply to VPS or Dedicated Server plans.


Page Timeouts and 504 Errors

As mentioned in the status code table above, these 504 Gateway Timeout errors are typically triggered because PHP or Apache took too long to respond (NGINX will wait for up to 60 seconds). You can use the following checklist to help narrow down the potential cause, then determine the appropriate solution.

phpinfo Check

First, check to see if you can access a phpinfo.php page. If the page loads correctly, this means that PHP-FPM and Apache are working correctly. If this test fails, then the issue lies with either Apache or PHP-FPM. New accounts have a copy of this file by default— visit https://example.com/phpinfo.php (replacing ‘example.com’ with your domain). If you have removed the file, or cannot access it, check our guide on creating a phpinfo page.

Batch Operations

Batch operations, such as importing large datasets via a web interface, may take longer than 60 seconds with sufficiently large datasets. We recommend that you import data via another method, if possible. If not possible, then you may be able to break the import into smaller chunks (for example, if importing a CSV file, try splitting the file in half, then importing each half separately). Depending on your goal, it may be possible to perform the action via WP-CLI. Many popular WordPress plugins extend WP-CLI to provide commands for performing administrative operations. Check the documentation for your particular plugin or application for details. Check our WP-CLI education channel for a list of WP-CLI-related articles.

Large Uploads

If you cannot upload a large file within the 60 second timeframe, this can also trigger a 504 error. This typically occurs when attempting to upload large archives, plugins, or theme packages. Instead, try using FTP or SFTP to upload the file. For WordPress themes, you can also use WP-CLI. Click here for instructions.

Malfunctioning Plugins or Scripts

Plugins that rely on external data sources can often cause 504 timeout errors and 500 errors in general. For example, if a GeoIP plugin cannot reach the server it uses to perform its lookups, the plugin might hang or retry for a long period of time. You can check our guide to troubleshooting WordPress plugins for further guidance.

Long-running MySQL queries

MySQL queries can also cause 504 timeout errors if the PHP script waits on a response from the MySQL server but it takes too long to respond. You can monitor active MySQL processes by logging in to phpMyAdmin, then clicking the “Status” tab along the top of the page. VPS and Dedicated server customers can also view more in-depth information by logging in as the root user via SSH or WHM— check our guide on monitoring MySQL processes for details.



Caching problems can create a lot of confusion for those unfamiliar with full-page caching. We have written a full article on how to troubleshoot caching issues, as well as tune cache parameters for the best performance. Below are a few quick tips to help get you started:

  • Install an automatic cache purge plugin for WordPress, or your CMS of choice. For WordPress, we recommend using the NGINX Helper plugin— click here for installation details and setup instructions.
  • After making any major site changes (new theme, adding/removing plugins, updating CSS, modifying header/footer files, etc.), we recommend that you purge the entire cache. This will prevent pages from potentially referencing outdated content which typically results in a broken site. Use the “Purge Full Cache” button in the Cache Manager Plugin to quickly perform this action.
  • Need to quickly purge the cache for a single page? Prefix the URI with /purge (example: https://example.com/1/page becomes https://example.com/purge/1/page), or use the “Purge URL” feature in the Cache Manager Plugin.
Check out our full article on NGINX cache management for an explanation of all tunable parameters, as well as tips on how to configure and troubleshoot caching for your sites.

High Memory Usage

For VPS and Dedicated customers, you may have noticed apparent high memory usage when running NGINX. The memory usage typically displayed in WHM shows the total system memory utilization, including system cache memory. The default NGINX configuration we distribute for VPS and Dedicated servers includes options that instruct NGINX to cache open file handles for frequently used content. This can help ensure that all of your images, stylesheets, and other static content serves quickly, as it remains in the operating system’s cache for quick retrieval. This “system page cache” holds recently-used files in memory for faster access times. When other applications need to use this memory, it remains available for use. For a full explanation of how the kernel file cache works in Linux, please review our page on Linux memory usage. This page also describes how to check the total available memory (the actual amount of free memory available to applications).

The below example VPS shows what appears to be 0 bytes of memory free. However, if we add the amount under the Mem “available” column, and the Swap “free” columns, we can see that the server actually has approximately 2GB available for applications, out of a total of 4GB (50% free). On Dedicated Servers, you should only use the Mem “available” column to calculate available memory.

 [root@vps ~]# free -h               total        used        free      shared  buff/cache   available Mem:           1.5G        890M          0B        6.8G        645M        415M Swap:          2.5G        1.0G        1.5G

AutoSSL Certificate Not Updating

AutoSSL, the free SSL that’s auto-enabled forever, allows users to generate free SSL certificates for all of their domains. This very useful feature allows users to secure their website over HTTPS/TLS at no additional cost.

Due to the way cPanel implements AutoSSL support, our NGINX configuration builder currently has no way to automatically trigger once a new AutoSSL certificate has installed. We have worked around this by having the script automatically check for changes every 20 minutes. This process then detects if cPanel has added a new AutoSSL certificate and applies it to the NGINX configuration for your domain(s). If you do not want to wait, you can open the Cache Manager Plugin in cPanel, then click the “Save Changes” button to force the configuration builder to re-check. If cPanel eventually does add hooks for the AutoSSL completion event in the future, we will then implement this support in our tooling to make the experience more seamless.

Temporary URL Not Working

If you have used cPanel servers previously, you may have used the “temporary URL” feature (via Apache mod_userdir). For example, accessing your user’s public_html directory via https://example.com/~username/ for testing purposes. Since this does not work nicely with PHP-FPM or the NGINX rules, InMotion Hosting disables this feature on servers with the WordPress Optimized stack.

Instead of using the temporary URL, you can perform a host file modification instead. This also has the advantage that you do not have to make any changes to your WordPress or other CMS configuration (most CMSes rely on a matching hostname and URI prefix, which breaks when using the temporary URL to test). Check out our article on modifying your hosts file for more details.

If you still cannot determine the source of a problem, please do not hesitate to reach out to our support team for assistance.
Check out more WordPress tutorials in the support center:
John-Paul Briones Content Writer II

John-Paul is an Electronics Engineer that spent most of his career in IT. He has been a Technical Writer for InMotion since 2013.

More Articles by John-Paul

Was this article helpful? Join the conversation!