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.
| Status | Reason | Action |
|---|---|---|
| 406 Not Acceptable | A ModSecurity rule was triggered | Ensure 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 Requests | Traffic to ratelimited URIs has exceeded the max number of requests per minute | NGINX 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 Disconnected | The client disconnected before Nginx could send a reply | This 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 Error | PHP script errors, database connection error, syntax error in htaccess files, and various other issues | Check the Apache or PHP error log for more information, as a number of issues can cause this error. |
| 502 Bad Gateway | NGINX could not connect to Apache | Check 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 Unavailable | Apache 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 Timeout | Apache or PHP-FPM took too long to respond | This 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 Reached | Your 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. |
PHP-FPM
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.
NGINX
Caching
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/pagebecomeshttps://example.com/purge/1/page), or use the “Purge URL” feature in the Cache Manager Plugin.
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).
[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.
