Cos'è Varnish Cache: installazione e configurazione di base di Varnish Cache Server

Varnish Cache è una cache reverse proxy che, davanti al server web, conserva in memoria le risposte HTTP e risponde alle stesse richieste senza passare dal server di origine. Quando abbiamo messo Varnish 6.6.2 davanti a WordPress su un server AlmaLinux 9.8, le pagine non venivano messe in cache a causa di max-age=0; abbiamo risolto impostando un tempo di conservazione nel VCL.

Quali richieste mettere in cache e per quanto tempo conservarle si scrive in un file VCL (Varnish Configuration Language).

1️⃣ Concetto di Varnish Cache: cache reverse proxy

Per ogni richiesta, Varnish controlla prima se esiste una risposta salvata. Se risponde con una risposta salvata è un cache hit (HIT); se deve prenderla dal server di origine (backend) è un cache miss (MISS). La risposta presa con un miss viene conservata per il tempo di conservazione e usata per le richieste successive.

Varnish open source non supporta TLS, quindi non può ricevere direttamente le richieste HTTPS. Sulla porta 443 è Nginx o HAProxy a gestire il TLS e poi a passare la richiesta a Varnish.

Il progetto open source Varnish Cache ha cambiato nome in Vinyl Cache a partire dalla versione 9.0, uscita a marzo 2026. Il nome Varnish Cache continua a essere usato dalla versione che Varnish Software distribuisce con funzioni TLS aggiunte.

2️⃣ Installare Varnish Cache Server

Su AlmaLinux 9 lo installi con il pacchetto varnish del repository predefinito (AppStream), e la versione di questo pacchetto è Varnish 6.6.2, precedente al cambio di nome.

dnf -y install varnish

Finita l'installazione, controlla la versione con [varnishd -V].

varnishd -V

varnishd (varnish-6.6.2 revision 17c51b08e037fc8533fb3687a042a867235fc72f)
Copyright (c) 2006 Verdens Gang AS
Copyright (c) 2006-2020 Varnish Software

I pacchetti della famiglia RHEL mantengono la versione 6.6.2, il cui supporto da parte del progetto è terminato, e la distribuiscono aggiungendo solo correzioni di sicurezza. Il pacchetto 6.6.2-7, uscito a giugno 2025, contiene la correzione di una vulnerabilità di HTTP request smuggling (CVE-2025-47905).

L'installazione crea anche [/etc/varnish/default.vcl] e [/usr/lib/systemd/system/varnish.service].

grep ExecStart= /usr/lib/systemd/system/varnish.service

ExecStart=/usr/sbin/varnishd -a :6081 -f /etc/varnish/default.vcl -s malloc,256m

[-a :6081] indica la porta che riceve le richieste, e [-s malloc,256m] i 256MB di memoria usati come spazio di archiviazione della cache.

3️⃣ Configurazione di base: backend e porta

Nel file VCL predefinito, [/etc/varnish/default.vcl], la porta 8080 dello stesso server è già impostata come backend.

vcl 4.1;

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

In Apache, cambia il valore di [Listen] in [httpd.conf] in 8080 perché riceva le richieste passate da Varnish.

# /etc/httpd/conf/httpd.conf
Listen 8080

Per i siti che usano HTTPS, lascia Varnish sulla porta 6081 e collega Nginx, che gestisce il TLS, in modo che passi le richieste a Varnish.

Una configurazione in cui Varnish riceve le richieste direttamente sulla porta 80 è adatta ai siti che usano solo HTTP. In quel caso, crea una copia del file di servizio come indica la documentazione di installazione di Varnish Software e cambia 6081 in 80 nella riga [ExecStart].

systemctl edit --full varnish

La copia salvata nell'editor viene creata in [/etc/systemd/system/varnish.service], e la porta modificata resta anche quando aggiorni il pacchetto.

systemctl enable --now varnish

Qualunque configurazione tu scelga, alla fine registra l'avvio automatico al boot con il comando enable e l'opzione now, che avvia subito anche Varnish.

4️⃣ Verificare il funzionamento: header X-Varnish e Age

Dopo aver avviato Varnish, controlla con gli header di risposta se le pagine di WordPress arrivano davvero dalla cache. La richiesta va direttamente alla porta 6081 di Varnish senza passare da Nginx, quindi il dominio e l'uso di HTTPS si indicano con gli header [Host] e [X-Forwarded-Proto].

curl -sI -H "Host: example.com" -H "X-Forwarded-Proto: https" http://127.0.0.1:6081/ | grep -iE "^(HTTP|cache-control|x-varnish|age|via)"

HTTP/1.1 200 OK
Cache-Control: max-age=0
X-Varnish: 1001
Age: 0
Via: 1.1 varnish (Varnish/6.6)

[X-Varnish] è il numero che Varnish assegna alla richiesta, e [Via: 1.1 varnish] indica che la risposta è passata da Varnish. [Age] è il tempo (in secondi) trascorso da quando la risposta è stata salvata nella cache.

Anche quando abbiamo inviato di nuovo la stessa richiesta 3 secondi dopo, [X-Varnish] aveva un solo numero e [Age] era 0: ha risposto di nuovo il server di origine. Una regola che il plugin di cache aveva messo in [.htaccess] aggiunge [max-age=0] all'HTML, e per questo la configurazione predefinita di Varnish ha calcolato il tempo di conservazione in 0 secondi.

Anche le richieste con cookie non passano dalla cache nella configurazione predefinita. Lo stesso vale per i cookie degli strumenti di analisi delle visite, quindi tutte le richieste dei visitatori che hanno questi cookie vanno al server di origine.

Il VCL qui sotto passa al server di origine le richieste di login e di amministrazione e quelle che non sono GET o HEAD, e mette in cache le altre richieste dopo averne rimosso i cookie. Le risposte con un tempo di conservazione di 0 secondi che non creano cookie vengono conservate per 10 minuti, mentre quelle che chiedono di non essere conservate, come [no-cache], non vengono conservate.

vcl 4.1;

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

sub vcl_recv {
    if (req.method != "GET" && req.method != "HEAD") {
        return (pass);
    }
    if (req.url ~ "^/(wp-admin|wp-login\.php)" || req.http.Cookie ~ "wordpress_logged_in_|wp-postpass_|comment_author_") {
        return (pass);
    }
    unset req.http.Cookie;
}

sub vcl_backend_response {
    if (beresp.ttl <= 0s && !beresp.http.Set-Cookie) {
        set beresp.ttl = 10m;
    }
}

Dopo aver modificato il file VCL, ricaricalo con [systemctl reload varnish]. Qui sotto c'è la seconda delle due risposte ottenute inviando due volte la stessa richiesta a Varnish con questo VCL applicato.

curl -sI -H "Host: example.com" -H "X-Forwarded-Proto: https" http://127.0.0.1:6081/ | grep -iE "^(HTTP|cache-control|x-varnish|age|via)"

HTTP/1.1 200 OK
Cache-Control: max-age=0
X-Varnish: 1004 1002
Age: 3
Via: 1.1 varnish (Varnish/6.6)

La seconda richiesta, inviata 3 secondi dopo aver applicato il VCL, aveva due numeri in [X-Varnish] e [Age] era 3. Due numeri significano che ha risposto la cache, e il secondo numero è quello della richiesta che ha preso la pagina dal server di origine e l'ha salvata.

La richiesta con il cookie di login ha avuto un solo numero e ha risposto il server di origine, mentre quella con il solo cookie dello strumento di analisi ha avuto risposta dalla cache.

🔢 FAQ & contenuti consigliati

ℹ️ Informativa sull'affiliazione
I contenuti di questo sito includono link di affiliazione. Se un visitatore acquista un prodotto o un servizio tramite uno di questi link, il sito riceve una commissione dal venditore. In questo processo l'importo pagato dall'acquirente ^{(durante le promozioni l'importo scende↓)} non aumenta. Prezzi, sconti e disponibilità indicati si riferiscono al momento della stesura e possono differire da quelli reali: prima di acquistare verifica sempre presso il venditore. I prodotti vengono scelti e valutati secondo criteri propri, e le commissioni non influiscono sull'ordine di presentazione né sul contenuto delle valutazioni.