Web & Graphic designer.

Based in Edinburgh, UK. Specializing in custom WordPress site development and graphic design.

If you are a business seeking a web presence or an employer looking to hire, you can get in touch with me here.

How to deal with the "Error 503 Backend fetch failed" Varnish error on Cloudways

How to deal with the “503 Backend fetch failed” Varnish error on Cloudways

Varnish Cache is a web application accelerator also known as a caching HTTP reverse proxy. It can be installed in front of any server that speaks HTTP and can be configured to cache the contents. Varnish Cache is really, really fast. It typically speeds up delivery with a factor of 300 – 1000x, depending on your architecture.

Cloudways implement Varnish to their web technology stack along with other caching layers.

Varnish can be activated on your Cloudways server by clicking on the Servers link on top then click on your server name, select Manage Services form the Server Management menu on the left and activate Varnish from the MANAGE SERVICES panel on the right.

Cloudways - Manage Services panel image
Cloudways – Manage Services panel

As you can see, from there you can also purge your server’s cache or disable the cache altogether.

Apart from that, though, you can also enable/disable the Varnish cache for each of your applications. Just select the Applications link from the top of your Cloudways panelthen  select your application from the list that appears, click the Application Settings on the left from the Application Management panel and enable/disable accordingly.

Cloudways - Applications Settings
Cloudways – Applications Settings panel

Instead of having to go to your Cloudways panel Application Settings, Cloudways has developed a plugin called Breeze that can be installed on your WordPress installation so that cache can be cleared from there in a convenient way. The plugin can also be used to minify your HTML, CSS and JavaScript and adjust other settings related to Gzip compression and Browser Cache. There are also settings to optimize your database tables and use your CDN to offload your cache.

I have been using Cloudways Managed WordPress hosting for sometime now and I am more than happy. One of the few issues that bug me sometimes is an error I get usually after I clear my application Varnish cache and visit a page on the frontend. It doesn’t happen very often but when it does, I would get this page on the browser:

503 backend error image
Varnish 503 Backend error

A couple of page refreshes usually fix the issue but I wasn’t happy that this was happening in the first place and I wanted a resolution on this. Searching for a solution, I discovered that there were quite a few cases of users having the exact same problem but solution was vage at best and no official post was published by Cloudways, probably  due to the fact that each user case was unique.

I decided to initiate a ticket through the Cloudayws chat support. After a few moments an agent asked me to confirm my server IP and I was given a few things to try out that could potentially fix the issue. I decided to write this blog post while I was implementing a few of those changes so other users could potentially benefit from what I had done.

Excessive number of applications

The good thing about Cloudways is that you could install a number of applications on the same server. Of course, the higher the number of applications you install, the more strain you put on your server. You could potentially alleviate the Varnish error on your server by having a small amount of applications.

Server Execution Limit and Memory Limit

From your Server Management panel, under the Settings & Packages on the BASIC tab there are a couple of settings that could help. I was told that Execution Limit could be set to 1200 and Memory Limit to 512.

Cloudways - Server Management
Cloudways – Server Management panel

Execution Limit is the amount of time a request is allowed to run across the stack. Web servers set a time limit on how long a script can run. This is done to prevent the webserver from abuse. Since WordPress is made up of PHP scripts, each script has to run completely within the set time limit. On Cloudways this time limit is usually 60 seconds, and in most cases, this is more than enough time for a script to run. However, if a PHP script runs for longer than the set time limit, PHP cuts short the execution. It then returns the fatal error: maximum execution time exceeded message.

Memory Limit is the maximum amount of Memory in (MB) that a PHP request is allowed to allocate. That means that if multiple requests were to use more than your server’s memory, you could potentially run out of memory so it depends on your server’s resources and the number of applications currently running on your server. So if you were to modify that settings, remember to monitor performance if your server resources are minimal.

Disable WP-CRON on on all applications

A suggestion was made to disable WP-CRON on all applications to optimize memory consumption on the server. This is easy to do. Just open the wp-config.php file located on your WordPress installation root folder and add the following just before the /* That's all, stop editing! Happy blogging. */ line:

define('DISABLE_WP_CRON', 'true');

Then, save the file and reupload it on the server. You can then easily add a manual CRON job to your application by following this article. Alternatively, you can create your own CRON job on an external website such as this one that allows you to create CRON jobs from minute-by-minute to once a year, for free.

Checking your cache plugin settings

In case you have another caching plugin install, there might be some settings that need to be tweaked. You can experiment with some settings so that there are no conflicting issues. For example, I use Autoptimize to minify my scripts so I have minification deactivated in the Breeze plugin.

Disable Varnish on php stack applications

It is not recommended from Cloudways to have Varnish activated on custom PHP applications. You can easily disable it from your Application Settings console (see screenshot above).

Attacks on your login page

Usually malicious users or bots might be targeting your login pages and as a result, your server resources would be consumed and produce the 503 error. You could make use of your security plugin to apply a reCAPTCHA for all your login and registration page and also change your default login URL. For example, Wordfence has a function to enable reCAPTCHA on the login and user registration pages by going to Wordfence->Login Security, select the Settings tab and activate the Enable reCAPTCHA on the login and user registration pages checkbox. Various other security plugins can also do the job.

Attacks from WordPress XML-RPC

XML-RPC is a method that WordPress uses to communicate with external services and transmit data. With the introduction of the upcoming WordPress API we can expect XML-RPC to be eliminated entirely. Attackers could use brute force attacks through xmlrpc.php to gain access to your site. Hackers could also use the pingback feature in WordPress to send pingbacks to thousands of sites instantaneously. This feature in xmlrpc.php gives hackers a nearly endless supply of IP addresses to distribute a DDoS attack over. Those attacks could be easily overloading your server thus causing the 503 error.

You can use the XML-RPC Validator to examine if your site has XML-RPC running. If the test fails that means that XML-RPC is deactivated. To deactivate it you can make use of the Disable XML-RPC plugin or manually by adding the following to your htaccess file:

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
allow from 127.0.0.1
</Files>

Some security plugins like Wordfence also have the functionality to deactivate XML-RPC, built-in. Just head to WordFence->Login Security, select the Settings tab and enable the Disable XML-RPC authentication checkbox.

Analytics monitoring

The application motoring tool on the Cloudways console can be used to monitor incoming traffic to your website. From there, you can check which IP requests and URLs accessing your site. You can find them by going to Applications->Application management -> Monitoring -> Analytics -> Traffic.

Cloudways traffic monitoring
Cloudways traffic monitoring

And there you have it!

Please, bear in mind that the above settings are not guaranteed to fix the issue and I suggest you try any changes on a cloned server beforehand. There is some useful info here for sure, though, and it would be interesting to see if any of these work for you.

You can visit the Cloudways Managed Cloud Hosting Platform and see if they have any plans that interest you. If you liked the article and thinking of signing up with Cloudways managed hosting, you can click on my affiliate link and signup.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.