How to Install and Configure Varnish Cache on CentOS

Varnish Cache is a high-performance HTTP reverse proxy that stores responses in memory and serves repeat requests without contacting the application server. On a CentOS host, it can reduce backend load, improve response times, and help a busy website cope with traffic spikes.

This guide covers package installation, backend preparation, VCL configuration, firewall rules, service management, and basic testing. The commands suit CentOS 7 and CentOS Stream, although repository availability differs between releases.

Check the CentOS Host Before Installation

Confirm the operating system and available repositories before installing anything:

cat /etc/centos-release
sudo yum repolist

CentOS 7 reached end of life in June 2024, so standard mirrors may no longer provide current packages. For a production server, use a supported CentOS Stream release or a compatible RHEL rebuild. On older systems, repository files may need to point to the CentOS vault, and Varnish versions can be considerably older.

Varnish normally listens on port 80, while Nginx or Apache must listen on another local port, commonly 8080. This arrangement is especially useful for Australian sites serving visitors across Sydney, Melbourne, Brisbane, and Perth, where avoiding an unnecessary backend request can make a noticeable difference over long network paths.

Install Varnish and Prepare the Backend

On CentOS 7, enable EPEL and install the package with yum:

sudo yum install -y epel-release
sudo yum install -y varnish

On CentOS Stream or a newer compatible system, use the available package manager:

sudo dnf install -y varnish

Check the installed version and service files:

varnishd -V
systemctl cat varnish

Configure the origin web server to use port 8080. For Nginx, change the relevant server block:

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

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

Then test and reload Nginx:

sudo nginx -t
sudo systemctl reload nginx

If the server also handles file transfers, keep that work separate from web caching; this Fedora FTP guide explains a comparable service-management workflow for vsftpd.

Create a Practical Varnish Configuration

The main VCL file is commonly /etc/varnish/default.vcl. The following configuration defines Nginx as the origin server and avoids caching unsafe or personalised requests:

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080";
    .connect_timeout = 5s;
    .first_byte_timeout = 30s;
    .between_bytes_timeout = 5s;
}

sub vcl_recv {
    if (req.method != "GET" && req.method != "HEAD") {
        return (pipe);
    }

    if (req.url ~ "^/admin" || req.url ~ "^/login") {
        return (pass);
    }

    if (req.http.Authorization) {
        return (pass);
    }

    return (hash);
}

sub vcl_backend_response {
    if (beresp.ttl <= 0s ||
        beresp.http.Set-Cookie ||
        beresp.http.Surrogate-control ~ "no-store" ||
        beresp.http.Cache-Control ~ "private") {
        set beresp.uncacheable = true;
        set beresp.ttl = 120s;
        return (deliver);
    }

    set beresp.ttl = 10m;
    return (deliver);
}

The cache lifetime should reflect the application. A public news page may tolerate a short delay before updates appear, while an online shop must bypass sessions, carts, account pages, and payment routes. Australian stores commonly experience traffic surges around local campaigns, public holidays, and end-of-financial-year promotions, so a conservative TTL is a sensible starting point.

Component	Typical setting	Purpose
Varnish listener	Port 80	Accepts public HTTP requests
Nginx or Apache	Port 8080	Serves uncached origin content
Static content TTL	10 minutes	Reduces repeated backend requests
Login and admin paths	Bypass	Prevents private content caching
HTTPS termination	Nginx or load balancer	Handles TLS before Varnish

Start the Cache and Verify Traffic

On many CentOS installations, /etc/varnish/varnish.params controls the listener port and VCL path. Set the relevant values as follows:

sudo vi /etc/varnish/varnish.params

VARNISH_LISTEN_PORT=80
VARNISH_VCL_CONF=/etc/varnish/default.vcl

Enable and start both services:

sudo systemctl enable --now varnish
sudo systemctl restart varnish
sudo systemctl status varnish --no-pager

Allow HTTP traffic through firewalld and confirm that the ports are listening:

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --reload

sudo ss -ltnp | grep -E ':80|:8080'

Test the response headers twice:

curl -I http://example.com/
curl -I http://example.com/

The first request commonly shows X-Varnish without a cache hit, while later requests can show Age or a custom hit indicator if one has been added to VCL. Review service errors with journalctl -u varnish -e when the daemon fails to start.

Maintain Performance and Cache Safety

Use Varnish’s monitoring tools during testing:

sudo varnishstat
sudo varnishlog -g request

varnishstat shows hit rates, evictions, and backend failures. varnishlog provides request-level detail, but it can be noisy on a live site. For an Australian audience using NBN connections or mobile networks, measure both origin response time and cached response time from more than one region rather than relying on a single office connection.

Apply these operating practices:

Keep Varnish, Nginx, the kernel, and security packages updated on supported CentOS systems.
Never cache responses containing sessions, authorisation data, shopping carts, or personal account details.
Purge or bypass affected URLs after publishing important content or changing application data.
Put TLS termination in front of Varnish or configure a suitable HTTPS architecture; plain HTTP alone is inadequate for production sites.
Monitor backend health, memory pressure, disk usage, and cache hit ratio with the tools already used by the operations team.

For sites that need broader global delivery, a CDN or edge platform such as edge delivery tools can complement local Varnish caching, but it should not replace careful cache-control rules at the origin. The key principle is simple: let Varnish handle safe, repeatable public responses while private and state-changing requests continue directly to the application.