How to Install and Configure Varnish Cache on a Linux VPS: Complete Guide to Speeding Up Your Website

If your website receives consistent traffic and you want to reduce server response times without immediately investing in additional resources, Varnish Cache is one of the most effective solutions available. Varnish is an HTTP accelerator (reverse proxy cache) that stores server responses in RAM, serving static and dynamic content tens of times faster than without caching.

In this guide, you'll learn how to install and configure Varnish Cache on a Linux VPS NVMe running Ubuntu 22.04, alongside Nginx as the backend web server.

What Is Varnish Cache and Why Does It Matter?

Varnish Cache acts as an intermediary between users and your web server (Nginx or Apache). When a visitor requests a page, Varnish first checks whether it has a saved version in cache. If it does, it serves it instantly — without consulting PHP, the database, or any other backend resource.

Concrete benefits:
- Response time reduction from hundreds of milliseconds to under 5ms for cached pages
- Significantly lower CPU and RAM consumption on the backend
- Support for a much higher number of concurrent visitors
- Excellent compatibility with WordPress, Joomla, Magento, and other CMS platforms

To get the most out of Varnish, you need a server with sufficient RAM. A performant SSD VPS with at least 2 GB RAM is a solid starting point.

Prerequisites

Before you begin, make sure you have:
- A VPS running Ubuntu 22.04 (or Debian 11/12)
- Root or sudo access
- Nginx installed and running
- A domain name pointing to your server

If you don't have a server configured yet, explore our entry-level VPS plans to get started quickly.

Step 1: Installing Varnish Cache

First, update your package list:

sudo apt update && sudo apt upgrade -y

Install Varnish from the official Ubuntu repositories:

sudo apt install varnish -y

Verify the installed version:

varnishd -V

For a newer version (e.g., Varnish 7.x), use the official Varnish repository:

curl -s https://packagecloud.io/install/repositories/varnishcache/varnish74/script.deb.sh | sudo bash
sudo apt install varnish -y

Step 2: Configuring Nginx to Listen on Port 8080

Varnish will listen on port 80 (public HTTP), while Nginx will run on port 8080 as the backend. Edit the Nginx configuration:

sudo nano /etc/nginx/sites-available/default

Modify the listen directive:

server {
    listen 8080;
    server_name example.com www.example.com;

    root /var/www/html;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
    }
}

Restart Nginx:

sudo systemctl restart nginx

Step 3: Configuring Varnish to Listen on Port 80

Create a systemd override for the Varnish service:

sudo systemctl edit varnish

Add the [Service] section:

[Service]
ExecStart=
ExecStart=/usr/sbin/varnishd \
  -a :80 \
  -f /etc/varnish/default.vcl \
  -s malloc,256m

Reload systemd and restart Varnish:

sudo systemctl daemon-reload
sudo systemctl restart varnish
sudo systemctl enable varnish

Step 4: Configuring the VCL File (Varnish Configuration Language)

The main configuration file is /etc/varnish/default.vcl. It is written in VCL — Varnish's own configuration language.

Open the file:

sudo nano /etc/varnish/default.vcl

A basic configuration for WordPress looks like this:

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

sub vcl_recv {
    # Do not cache authenticated requests or shopping carts
    if (req.http.Cookie ~ "wordpress_logged_in|woocommerce_cart") {
        return(pass);
    }

    # Do not cache the admin area
    if (req.url ~ "^/wp-admin" || req.url ~ "^/wp-login.php") {
        return(pass);
    }

    # Remove cookies for static assets
    if (req.url ~ "\.(css|js|png|jpg|gif|ico|woff2|svg)$") {
        unset req.http.Cookie;
        return(hash);
    }

    return(hash);
}

sub vcl_backend_response {
    # Cache for 1 hour by default
    set beresp.ttl = 1h;
    set beresp.grace = 15m;
}

sub vcl_deliver {
    # Add debug header
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }
}

Restart Varnish after making changes:

sudo systemctl restart varnish

Step 5: Testing the Cache

Use curl to verify that Varnish is working correctly:

curl -I http://example.com

Look for the X-Cache header in the response:

HTTP/1.1 200 OK
X-Cache: MISS   ← first request (cache is empty)

Repeat the command:

curl -I http://example.com

HTTP/1.1 200 OK
X-Cache: HIT    ← second request (served from cache)

Use varnishstat for real-time statistics:

varnishstat

Or varnishlog to watch live requests:

varnishlog

Step 6: Setting Up HTTPS with Nginx as SSL Terminator

Varnish does not natively handle HTTPS. The standard solution is to place Nginx on port 443 as an SSL terminator, which forwards decrypted traffic to Varnish on port 80.

Full flow: Client → Nginx:443 (SSL) → Varnish:80 → Nginx:8080 (backend)

Add an HTTPS server block to Nginx:

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }
}

If you don't have an SSL certificate yet, check out our professional SSL certificate services or set up a free Let's Encrypt certificate using Certbot.

Step 7: Cache Invalidation (Purge)

When you publish new content, you need to clear the Varnish cache. Add purge support to your VCL:

acl purge {
    "127.0.0.1";
    "localhost";
}

sub vcl_recv {
    if (req.method == "PURGE") {
        if (!client.ip ~ purge) {
            return(synth(405, "Not allowed"));
        }
        return(purge);
    }
    # ... rest of configuration
}

Send a manual purge command:

curl -X PURGE http://example.com/page-to-purge

For WordPress, the Proxy Cache Purge plugin (formerly Varnish HTTP Purge) automates this process seamlessly.

Additional Optimizations

• Increase cache memory: Edit the -s malloc,256m parameter and set a larger value (512m or 1g) depending on available RAM
• Grace mode: Allows Varnish to serve stale content while refreshing the backend — reduces perceived latency for users
• Saint mode: Prevents sending traffic to a backend that is returning errors
• Directors: Distribute load among multiple backends for horizontal scalability

If your site has grown significantly and Varnish alone isn't enough, consider a managed dedicated server where you can implement more complex multi-tier architectures.

Monitoring Varnish

Useful monitoring commands:

# Global statistics
varnishstat -1

# Cache hit/miss ratio
varnishstat -1 -f MAIN.cache_hit -f MAIN.cache_miss

# Filtered logs
varnishtop -i RespHeader

A hit rate above 80% is considered excellent. If yours is below 50%, revisit your VCL rules — you may be excluding too much content from caching.

Conclusion

Varnish Cache is a powerful tool that can dramatically improve your website's speed with relatively modest configuration effort. Combined with a fast NVMe VPS and a valid SSL certificate, you get a modern web infrastructure capable of handling high traffic loads with minimal resources.

If you'd rather leave server configuration to experts, CLIQHOST offers professional Linux server management services. Reach out via our contact page or explore more technical guides on our blog.