Impact of Varnish on WordPress

Updated 4 April 2024

What is Varnish?

Varnish is a software that helps websites load faster by storing a copy of the website’s content in a special place called a cache.

Varnish Cache is a web application accelerator also known as a caching HTTP reverse proxy. However, You can install it in front of your web server.

When someone visits the website, instead of fetching all the information from scratch, varnish quickly retrieves the stored copy, making the website load much faster.

In this blog, we will learn how to implement Varnish and Apache.

Benefits of using varnish

Speed: Websites load faster because varnish serves up cached copies of web pages instead of generating them from scratch every time someone visits.

Reduced Server Load: Since varnish reduces the number of requests to the main server, it helps to lower the burden on the server, which can handle more visitors without slowing down.

Better User Experience: Faster loading times mean visitors spend less time waiting for pages to load, leading to a better overall experience and higher satisfaction.

Scalability: Varnish can handle a large number of simultaneous requests, making it suitable for high-traffic websites.

Cost Savings: By reducing server load and increasing efficiency, varnish can help save on hosting costs.

In simple terms, varnish is like a turbocharger for websites, making them faster and more efficient, which benefits both website owners and visitors.

How to set up/install Varnish?

It completely depends on the OS of the server. Based on the server OS you will run the command to install.
Note – Here we are using the Ubuntu 20.04 server.

Please run the below commands:

This command updates the package list to get information on the latest available packages.

This command will install the further dependencies to configure the package repository.

Here’s a breakdown of what each of these packages does and why they might be required:

> Debian-archive-keyring: This package contains the GnuPG archive keys of the Debian archive. These keys are used to verify the authenticity of Debian packages during installation. Installing this package ensures that your system can authenticate packages from the Debian repository.

> Curl: Curl is a command-line tool and library for transferring data with URLs. However, it supports various protocols, including HTTP, HTTPS, FTP, and more. It’s commonly used for downloading files or interacting with web services from the command line.

> gnupg: GnuPG (GNU Privacy Guard) is a complete and free implementation of the OpenPGP standard. It’s used for encryption and signing of data and communication. It’s likely included here because it’s a dependency for other packages or because it’s commonly used for secure communication or package verification.

> apt-transport-https: This package allows apt-get to retrieve and download packages over HTTPS. It’s essential for securely fetching packages from repositories that use HTTPS, which is increasingly becoming the standard for package repositories to ensure data integrity and security during transmission.

Further, the next command will import the GPG key into the package manager configuration:

This command retrieves a GPG (GNU Privacy Guard) key from the specified URL ( and then adds it to the list of trusted keys used by the APT package manager on a Debian-based Linux system.

Here’s a breakdown of the components:

> curl: This is the command-line tool used for transferring data with URLs. In this command, it’s fetching the GPG key from the specified URL.

> -s: This flag makes the curl operate in silent mode, meaning it doesn’t show progress or error messages.

> -L: This flag tells the curl to follow any HTTP redirects, so it will automatically go to the final destination URL if there are any redirections.

You can retrieve the GPG key from the URL –

> |: This is the pipe operator, which redirects the output of the curl command (the GPG key) to the next command (sudo apt-key add -).

> sudo apt-key add -: This command adds the GPG key received from curl to the list of trusted keys used by APT. sudo is used to run the command with administrative privileges.

And finally, we have to update the package list once again. This will ensure the Package-cloud repository is included:

Now that the repositories are added and the right repository preferences are configured, you can install Varnish by running the following command:

How to configure Varnish?

Varnish usually listens for requests on port 6081, but we’re configuring Varnish to listen on port 80, We are also adjusting how much Varnish can store in memory by making changes to its unit file.

Default block:

After doing the required changes our block will look like this:

This block is a configuration for starting the Varnish Cache daemon (varnishd).

Let’s break down each option:

> ExecStart: This is a directive typically found in a systemd service unit file (*.service). It specifies the command to execute when starting the service.

> /usr/sbin/varnishd: This is the path to the Varnish Cache daemon executable.

> -j unix,user=vcache: This option tells Varnish to create a shared memory file (VSM) using Unix domain sockets with permissions granted to the vcache user. We are using this for inter-process communication.

> -F: This option tells Varnish to run in the foreground, meaning it won’t daemonize and detach from the terminal.

> -a :80: This option specifies the address and port on which Varnish should listen for incoming client requests. In this case, it’s listening on port 80 of all available network interfaces (: represents all interfaces).

> -T localhost:6082: This option specifies the address and port where the Varnish administration interface (Varnish Management Interface, VSM) is available. It’s listening on localhost ( on port 8443. This interface is typically used for administration tasks such as cache inspection, statistics gathering, and dynamic configuration updates.

> -p feature=+http2: This option enables HTTP/2 support in Varnish. HTTP/2 is the latest version of the HTTP protocol and offers improvements over HTTP/1.1, including multiplexing as well as header compression.

> -f /etc/varnish/default.vcl: This option specifies the location of the Varnish Configuration Language (VCL) file that Varnish should use for configuring its behavior. In this case, it’s using /etc/varnish/default.vcl.

> -S /etc/varnish/secret: This option specifies the location of the secret file used for securing communication between Varnish and varnishadm (the management CLI for Varnish). Hence, this file typically contains a shared secret key.

> -s malloc,2g: This option specifies the storage method and size for the Varnish cache. In this case, it’s using the malloc storage backend, which stores cache objects in memory. The 2g indicates that Varnish should allocate 2 gigabytes of memory for caching.

We’ve finished configuring Varnish. Now, we’re setting up the web server – Apache.

Now we’ll install the Apache on the Ubuntu server. For Apache, we’ll have it running on port 8080.

In Apache, we’ll tweak settings in both the virtual hosts (vhosts) files and the port.conf file.

First, we will change the port in the ports.conf which is located at /etc/apache2/ports.conf. Here you will change the port from 80 to 8080.

Now, we will make the changes in this file 000-default.conf, it is located at /etc/apache2/sites-enabled/000-default.conf.

Here also you will change Apache port from 80 to 8080.

Varnish gives us a WordPress VCL (Varnish Configuration Language) file, and we’ll use it for our setup.

Here’s the full VCL file:

This is a Varnish Configuration Language (VCL) script used for configuring Varnish Cache, an HTTP accelerator. Let’s break down the script section by section:

Backend Configuration:

This section defines the default backend server to which Varnish will forward requests.

Purge ACL:

Defines an ACL (Access Control List) named “purge” containing IP addresses and hostnames allowed to perform cache purges.

vcl_recv (Receive)
This subroutine handles incoming client requests and performs various actions:

> Query String Handling: Removes empty query string parameters and sorts query parameters alphabetically for cache normalization.
> Proxy Header Removal: Removes the proxy header to mitigate the httproxy vulnerability.
> X-Forwarded-Proto Header Addition: Adds the X-Forwarded-Proto header to indicate the protocol used (http or https).
> Purge Logic: Implements logic for cache purging based on the PURGE method.
> HTTP Method Handling: Allows only specific HTTP request methods and passes others through.
> Query String Parameter Removal: Removes tracking query string parameters used by analytics tools.
> Cache Control: Specifies which requests should not be cached.

This subroutine is responsible for generating a hash key used to look up objects in the cache. As a result, it creates cache variations based on the request protocol.

Handles responses from the backend server:

> Header Injection: Injects URL and Host headers into the object for asynchronous banning purposes.
> Cache-Control Header Handling: Sets a default TTL if no Cache-Control header is present.
> Static File Caching: Sets a specific TTL for static files.
> Cookie Handling: Removes Set-Cookie headers under certain conditions.

Performs actions before delivering the response to the client:

> Debug Header: Sets a debug header indicating cacheability.
> Header Cleanup: Removes injected headers.

Finally, we will reload and restart the services.

To reload the systemd daemon we will use the below command:

Restart the Apache web server, we will run the below command:

To restart the Varnish, we will run the below command:

This restart will also make sure that the correct settings are in place for Nginx, Apache, and Varnish to properly store and serve cached versions of your WordPress website, improving its performance.

How to delete the cache?

You can restart or reload Varnish if you want to clear the entire cache. This will effectively clear all cached content.

How to disable varnish completely?

To completely disable the Varnish service and switch Apache back to port 80 from port 8080, follow these steps:

Stop the Varnish service:

Edit Apache configuration:

Open the Apache configuration file, typically located at /etc/apache2/sites-enabled/*.conf.
Find the line that specifies the port number. It might look like Listen 8080 or Listen.
Further, change the port number to 80.

Edit ports.conf

Open the ports.conf file, typically located in the /etc/apache2/ directory.
Now, change any references from 8080 to 80.

Restart Apache:

Open a web browser and navigate to your server’s domain or IP address. As a result, it should now be accessible without specifying the port number, as Apache is now listening on port 80.

By following these steps, you’ve effectively disabled Varnish and restored Apache to listen on port 80, ensuring your web server serves content directly without Varnish caching in between.

The above-mentioned part will only work for port 80 because the varnish is an HTTP accelerator and it can cache the HTTP level but what if we want to serve the website with SSL? So let’s configure the varnish with Apache and Nginx to work with SSL.

The above Varnish configuration will be the same as it is mentioned earlier. Just we will make the changes for the Ngixn conf.

You can find the nginx default file with the name default in the path. Path – /etc/nginx/sites-enabled/default

Please go through the below-given conf and make the changes in your file accordingly.

Now restart all the services i.e. Nginx, Varnish and Apache. Open your browser and hit the domain. As a result, you will able to see the varnish hit in the browser console.


Was this guide helpful? Please share your feedback in the comments below.

In case you have any issues/queries regarding the module please raise a ticket at

For any further information or query contact us at [email protected].

Thanks for reading!!

. . .

Leave a Comment

Your email address will not be published. Required fields are marked*

Be the first to comment.

Start a Project

    Message Sent!

    If you have more details or questions, you can reply to the received confirmation email.

    Back to Home