Sito lento? Guida rapida per renderlo veloce - Come installare e configurare Varnish con Nginx e PHP su Ubuntu (video)

Il tuo sito è lento? Niente paura! Varnish è un "acceleratore HTTP" gratuito e open source. Si tratta cioè di un software che, una volta installato sul tuo server web, consente ai visitatori di caricare le pagine in meno di un secondo, riducendo drasticamente sia il consumo di RAM e CPU del server web stesso, sia il numero di accessi al database. In questa guida vedremo dunque come installare e configurare Varnish con Nginx e PHP su Ubuntu nel modo più rapido possibile, di modo da rendere velocissimo qualsiasi sito Internet in pochi minuti

La procedura è stata testata su Ubuntu Server 24.04, 22.04 e 20.04, ma dovrebbe rimanere valida anche per tutte le generazioni successive.

Prima di installare Varnish: il server web è necessario

Prima di iniziare a impartire comandi (cioè il focus di questa guida!), è bene capire che la "magia" di Varnish è resa possibile da un sistema di caching e un motore di regole configurabili che consentono all'amministratore del server di scegliere cosa e per quanto tempo cachare, e quando invece no. In altre parole: Varnish è "solo" un sistema di caching che si affida al nostro tradizionale "backend" per generare le pagine da salvare nella propria cache: allo scopo, possiamo usare un server web come Nginx, Apache HTTP Server o simili.

In particolare, questa guida è incentrata su Varnish con Nginx, quindi è necessario installare preventivamente Nginx seguendo la guida dedicata:

» Leggi: Come installare NGINX su Ubuntu

Affinché l'accelerazione abbia senso è poi necessario che il sito erogato abbia una logica di generazione "dinamica" delle pagine, come potrebbe essere l'uso PHP per l'accesso a un database o ad API REST, SOAP e/o GraphQL. Ad esempio: Varnish è eccezionale con WordPress, WoCommerce, Magento, Prestashop e altri sistemi notoriamente "pensanti", ma può sicuramente fare la differenza anche con applicazioni basate su Symfony o Laravel, soprattutto se non realizzate nel migliore dei modi.

La procedura per installare PHP e interfacciarlo con Nginx è stata presentata in questa guida dedicata:

» Leggi: Guida: come installare PHP su Ubuntu (PHP-FPM, video)

Da qui in poi daremo per scontato che il sito web funzioni, ma le pagine si carichino troppo lentamente. Il nostro obbiettivo è dunque di installare e configurare Varnish per rendere veloce il sito esistente.

Varnish e la "questione HTTPS (TLS/SSL Termination)"

Il web moderno funziona universalmente su HTTPS (con la "s" alla fine), ovvero "HTTP crittografato". I browser web fanno il possibile per dissuadere gli utenti dal visitare siti non-HTTPS, mostrando una schermata minacciosa in caso si tenti di aprire una pagina HTTP

Sfortunatamente, Varnish NON supporta nativamente HTTPS, per esplicita volontà del suo autore.

[per la precisione: questo è vero limitatamente alla versione open source. La versione commerciale (a pagamento) Varnish Enterprise, invece, supporta nativamente HTTPS. Ma questo articolo è incentrato sulla versione open source, libera e gratuita per tutti]

Il risultato è che, per farlo funzionare con HTTPS, dobbiamo configurare Varnish in mezzo a "due" server web:

1. il primo server web è quello al quale si collegano i visitatori del sito, usando HTTPS. Il suo ruolo è detto TLS Termination (in passato: SSL Termination): non deve usare PHP, né fare null'altro se non gestire le connessioni HTTPS
2. quando il visitatore richiede una pagina, il TLS Termination la richiede a Varnish
3. se Varnish non ha ancora salvato tale pagina nella propria cache, si collega al server web di backend (il "secondo server web") per generarla
4. il server web di backend genera la pagina, magari usando PHP per recuperare i dati da un database o da altre fonti esterne, poi restituisce la pagina finita a Varnish
5. Varnish salva la pagina nella propria cache (se le regole per la pagina in questione glielo consentono), poi la restituisce al TLS Termination, che la mostra al visitatore
6. successivamente, ad ogni richiesta della stessa pagina, Varnish la leggerà direttamente dalla propria cache, invece che farla generare di nuovo al backend

Un'idea potrebbe essere quella di usare Hitch come TLS Termination. Si tratta di un mini-server web, sviluppato dalla stessa azienda che sviluppa Varnish appositamente per questo specifico scopo. Personalmente, però, preferisco evitare l'installazione di un pacchetto aggiuntivo e configurare Nginx sia come TLS Termination, sia come "secondo server web (backend)" al quale si connette Varnish. In pratica, l'architettura diventa questa:

1. Nginx, in ascolto sulla porta TCP 80, invia un codice di risposta 301 ai client che si connettono erroneamente in HTTP tradizionale. In questo modo, quando i visitatori richiedono erroneamente il sito in HTTP, invece di HTTPS, effettuano automaticamente un redirect verso il sito erogato in HTTPS
2. Nginx, in ascolto sulla porta TCP 443, svolge il ruolo di TLS Termination. Per quanto spiegato sopra, si limita dunque ad accettare le richieste HTTPS dei visitatori e inoltrare la richiesta a Varnish
3. Varnish, in ascolto sulla porta TCP 6081, accetta le richieste dal TLS Termination e, se non ha ancora la pagina in cache, la richiede al backend sulla porta 8080
4. Nginx, in ascolto sulla porta TCP 8080 (interfaccia localhost, quindi non raggiungibile dall'esterno) ricopre il ruolo di "secondo server web": include quindi PHP e tutta la logica di backend, e Varnish si collega ad esso per generare le pagine

Bene! Vediamo ora come implementare, in pratica, questa configurazione.

Connessione SSH

Connettiti in SSH al server sul quale vuoi installare Varnish. In questo articolo installeremo Varnish sullo stesso server sul quale è in esecuzione il server web, che è la scelta più sensata nella maggior parte dei casi

» Leggi: SSH con Windows, Linux, Mac: la Guida Definitiva

Valuta di configurare la connessione SSH per entrare senza password. Non è indispensabile, ma sicuramente ti semplifica molto la vita:

» Leggi: [guida] Come creare una chiave SSH da PC Windows, Linux, Mac e accedere ai server senza password

Varnish con Nginx e PHP su Ubuntu, Passo 1: Installazione automatica

Tecnicamente, è possibile installare Varnish su Ubuntu tramite apt, poiché il pacchetto è disponibile nei repository nativi. Ma, personalmente, ti stra-raccomando di NON farlo, perché la versione che si installa in questo modo non è mai aggiornata. Nel momento in cui scrivo, ad esempio, Ubuntu 24.04 offre Varnish 7.1, mentre è già disponibile da molti mesi Varnish 7.6. Se poi il server monta una versione di Ubuntu meno recente, il divario è ancora più marcato.

Di conseguenza, io consiglio di utilizzare il repository ufficiale gestito dal team che sviluppa Varnish: fornisce build altrettanto stabili, ma costantemente aggiornate con tutte le nuove funzionalità e correzioni.

Per installare Varnish su Ubuntu tramite i repository ufficiali di Varnish in modo completamente automatico basta impartire questo singolo comando sul tuo server:

sudo apt update && sudo apt install curl -y && curl -sL https://turbolab.it/scarica/477 | sudo bash

In caso fosse richiesta la password, digita quella associata al tuo utente Linux sul server

Il comando appena impartito esegue uno script (visualizzabile qui) che svolge in sequenza tutte le tediose operazioni che, altrimenti, dovresti svolgere manualmente.

Al termine, lancia questo comando sul server stesso connetterti a Varnish:

curl http://127.0.0.1:6081

Se, in risposta, viene visualizzato codice HTML, significa che l'installazione è riuscita

Tecnicamente, il messaggio di risposta che vedi è un errore, ma, in questo momento, non importa. Quello che conta è che Varnish risponda, come effettivamente avviene!

Varnish con Nginx e PHP su Ubuntu, Passo 2: Configurare il server web di backend

L'errore che abbiamo appena visto dipende dal fatto che Varnish non riesce a collegarsi al server web di backend (v. spiegazione sopra). Questo succede perché non abbiamo ancora configurato tale server web di backend. Procediamo dunque a farlo ora, seguendo questa regola:

Il server web di backend è esattamente il nostro sito attuale, senza la configurazione relativa a HTTPS, erogato sulla porta 8080 locale

Spostiamoci dunque nella cartella dove si trova la configurazione del nostro sito. Per chi ha seguito la nostra guida a Nginx, installandolo dai repository del team di sviluppo di Nginx, il comando è:

cd /etc/nginx/conf.d

Chi invece abbia usato i repository di default di Ubuntu:

cd /etc/nginx/sites-enabled

Una volta dentro, dobbiamo localizzare il file di configurazione del nostro sito:

ls -l

Prendiamo ad esempio il file example.com.conf, che avevamo già visto durante la guida all'installazione di Nginx. Apriamolo:

sudo nano example.com.conf

Nel caso in esempio, la configurazione del sito è costituita dal primo blocco server { ... }. Seguendo la regola sopra, dobbiamo dunque:

1. copiarla
2. rimuovere la configurazione HTTPS
3. spostarla sulla porta locale (listen 127.0.0.1:8080;)

Il risultato è visionabile, per confronto, in questo file (sezione ## Backend web server)

Batti ora Ctrl+O seguito da Invio per salvare, poi Ctrl+X per uscire.

Ora eseguiamo un test della configurazione e ricarichiamo la configurazione aggiornata con il solito comando concatenato:

sudo nginx -t && sudo service nginx reload

Varnish con Nginx e PHP su Ubuntu, Passo 3: Testare il server web di backend direttamente

Ora assicurati che il server web di backend che hai appena attivato funzioni correttamente impartendo il seguente comando:

curl http://127.0.0.1:8080

In risposta, dovresti visualizzare a terminale l'HTML del tuo sito

Varnish con Nginx e PHP su Ubuntu, Passo 4: Testare il server web di backend attraverso Varnish

Ora che il server web di backend è funzionante, Varnish dovrebbe riuscire a connettersi e mostrare il risultato. Verifichiamolo inviando nuovamente a Varnish la stessa richiesta che avevamo tentato in precedenza:

curl http://127.0.0.1:6081

Se tutto ha funzionato, dovresti nuovamente vedere l'HTML del tuo sito.... ma con un'importante, invisible differenza: la richiesta sta arrivando a Varnish il quale, non avendo la pagina salvata nella propria cache, interroga il server web di backend che abbiamo attivato un attimo fa. Quest'ultimo genera la pagina tramite PHP, la restituisce a Varnish, che la restituisce al client web del visitatore.

Se stai usando la pagina index.php di test che abbiamo fornito nella nostra guida all'installazione di Nginx dovresti vedere nell'HTML la dicitura qui puoi leggere la data attuale =>. Nota il numero di secondi, poi impartisci nuovamente curl http://127.0.0.1:6081: noterai che il numero di secondi non avanza, ma rimane fisso per alcuni minuti dopo la prima richiesta. Questo dipende proprio dal fatto che Varnish sta servendo la pagina direttamente dalla propria cache, senza contattare nuovamente il server di backend, e quindi senza eseguire la pagina PHP originale. Ne consegue che l'orario rimane fisso alla prima generazione.

Vuoi un ulteriore conferma? Procedi così:

1. richiedi la pagina a Varnish con curl http://127.0.0.1:6081
2. arresta il processo di Nginx con sudo service nginx stop
3. richiedi nuovamente la pagina a Varnish con curl http://127.0.0.1:6081. Noterai che l'HTML si vede comunque, nonostante Nginx sia fermo, proprio perché Varnish sta servendo la pagina dalla propria cache, senza contattare Nginx

1. ora riavvia Varnish con sudo service varnish restart, di modo da rimuovere tutta la sua cache
2. richiedi nuovamente la pagina a Varnish con curl http://127.0.0.1:6081
3. questa volta riceverai un errore, perché Varnish non ha la pagina in cache e tenta quindi di recuperarla dal server web di backend, il quale però non è in funzione

Vedremo come gestire le regole di caching in seguito.

Completato l'esperimento, puoi riavviare Nginx impartendo sudo service nginx restart

Varnish con Nginx e PHP su Ubuntu, Passo 5: Configurare il TLS Termination

Procediamo configurando il TLS Termination, ovvero il "primo server web", cioè quello che "sta davanti" e gestisce le richieste HTTPS dei visitatori che richiedono le pagine del sito. In questo caso, la regola da seguire è la seguente:

Il TLS Termination contiene solo il server_name, la configurazione HTTPS e il proxy_pass verso Varnish

Apriamo quindi nuovamente il file di configurazione del sito

sudo nano example.com.conf

Ora modifichiamo il "vecchio" blocco server { ... }, cioè quello da cui abbiamo copiato sopra per creare il server web di backend. Seguendo la regola sopra, dobbiamo dunque:

1. mantenere solo il server_name e la configurazione HTTPS
2. aggiungere l'inclusione del proxy_pass verso Varnish (include /etc/nginx/varnish.conf;)

Il risultato è visionabile, per confronto, in questo file (sezione ## TLS Termination)

Batti Ctrl+O seguito da Invio per salvare, poi Ctrl+X per uscire.

Ora eseguiamo un test della configurazione di Nginx e ricarichiamo la configurazione aggiornata con il solito comando concatenato:

sudo nginx -t && sudo service nginx reload

Varnish con Nginx e PHP su Ubuntu, Passo 6: Visualizzare il sito

Ora che anche il TLS Termination è configurato correttamente possiamo provare ad aprire il sito tramite il browser web del nostro PC (https://example.com, nel caso usato come esempio). Se tutto funziona correttamente, dovremmo vedere il nostro sito, esattamente come prima

Di nuovo: se stai usando la pagina index.php di test che abbiamo fornito nella nostra guida all'installazione di Nginx dovresti vedere nell'HTML la dicitura qui puoi leggere la data attuale =>. Nota il numero di secondi, che ora rimane fisso ad ogni reload della pagina. Questo dipende proprio dal fatto che Varnish sta servendo la pagina dalla propria cache.

Varnish con Nginx e PHP su Ubuntu, Passo 7: Come capire se Varnish sta funzionando

Come capire se Varnish sta restituendo la risposta dalla propria cache oppure la sta chiedendo al server web di backend? Semplice:

1. apri gli Strumenti di sviluppo del browser (scorciatoia da tastiera: F12)
2. portati alla sezione Rete
3. apri il tuo sito
4. clicca sulla richiesta relativa alla pagina principale (la prima in alto, generalmente) nella lista di richieste
5. scorri fino alla sezione Intestazioni risposte
6. trova la riga X-Varnish

Se, in concomitanza di tale riga, trovi:

1. un singolo numero: la pagina è stata generata dal server di backend, non servita dalla cache. Questo avviene sempre al primissimo accesso a un determinato URL del sito, oppure dopo che la cache di Varnish è stata svuotata (v. seguito)
2. due numeri: la pagina è stata restituita direttamente dalla cache di Varnish

Varnish con Nginx e PHP su Ubuntu, Passo 8: Svuotare la cache di Varnish

In alcune circostanze è necessario svuotare completamente la cache di Varnish, di modo che le pagine vengano nuova generate dal server web di backend. Il comando è:

sudo varnishadm ban "req.url ~ ."

In alternativa, si può riavviare Varnish:

sudo service varnish restart

Questa seconda strada, però, potrebbe causare un (breve) disservizio ai visitatori del sito e non è dunque ottimale per i sistemi di produzione.

Usando la configurazione consigliata (v. seguito), è anche possibile rimuovere uno specifico URL dalla cache tramite una richiesta HTTP che utilizzi il metodo PURGE. Se, ad esempio, volessimo rimuovere dalla cache di Varnish la pagina con URL https://example.com/pagina-da-rimuovere, dovremo usare una richiesta HTTP simile a questa:

curl -X PURGE -H "Host: example.com" "http://127.0.0.1:6081/pagina-da-rimuovere" --head

Se la risposta contiene 200 Purged, l'operazione è andata a buon fine e la pagina verrà rimossa dalla cache

Per evitare che chiunque possa eliminare oggetti dalla cache di Varnish semplicemente inviando una chiamata come questa, la configurazione proposta accetta il metodo PURGE solo quando l'origine è il sistema stesso (localhost) oppure un altro sistema sulla stessa LAN. Tutti gli altri, ricevono un errore 405 e la cache non viene svuotata

Varnish con Nginx e PHP su Ubuntu, Passo 9: Varnish Configuration Language (VCL)

Nella situazione attuale, cioè senza personalizzare le regole di caching, è probabile che Varnish stia cachando troppo, mostrando pagine obsolete, oppure troppo poco, cioè interrogando continuamente il server web di backend. Il linguaggio con cui si regolano le condizioni di caching si chiama Varnish Configuration Language (VCL). Apri dunque il file dedicato:

sudo nano /etc/varnish/default.vcl

Lo script automatico che abbiamo eseguito all'inizio della guida per installare Varnish ha già scaricato una versione del file leggermente pre-configurato tramite l'inclusione di un secondo file (base.vcl) che prevede alcune direttive valide nella maggior parte dei casi. Alcuni esempi:

• esclude dal caching le richieste che utilizzino i metodi HTTP di modifica, come POST, PUT, DELETE, ...
• esclude dal caching le richieste/risposte con cookie
• considera due URL che abbiamo gli stessi parametri, ma in un ordine diverso, come la stessa pagina

È però indubbiamente necessario apportare altre modifiche, specifiche per il progetto o il framework in uso. Raccomando, in particolare, di dare un'occhiata a questi esempi della documentazione ufficiale:

• WordPress VCL - per l'integrazione, ho personalmente usato con soddisfazione il plugin Proxy Cache Purge (gratuito). Ricorda solo di configurare come host localhost:6081 da pannello admin di WordPress
• Drupal VCL
• Configurazione con Magento (il VCL si genera dalla sezione "admin")

Varnish con Nginx e PHP su Ubuntu, Passo 10: Riavviare il servizio

Per rendere effettive le modifiche al VCL usa SEMPRE questo specifico comando concatenato:

sudo varnishd -C -f /etc/varnish/default.vcl && sudo service varnish restart

Così facendo, Varnish verifica prima che la nuova configurazione sia corretta, e solo se va tutto bene effettua il restart. In caso contrario, vengono visualizzati i dettagli degli errori, mentre Varnish continua a funzionare con la configurazione precedente. In questo modo, evitiamo che il servizio si fermi e non possa più essere riavviato a causa di un errore nella nuova configurazione.

Conclusioni

In questa guida abbiamo visto come rendere veloce un sito web configurando Varnish con Nginx e PHP su Ubuntu. Arrivati a questo punto, il sistema è in funzione: la parte più difficile è chiaramente la personalizzazione del VCL, indispensabile per utilizzare la cache il più possibile, ma solo quando vi siano le condizioni per farlo.

Un'ultima raccomandazione: è indispensabile testare approfonditamente ogni parte del sito, verificando la navigazione prima e dopo il login, cancellando i cookie dal proprio browser e quant'altro. Per i siti di ecommerce, in particolare, raccomando di verificare che il flusso di carrello e checkout sia sempre escluso dal caching, e che la presenza di eventuali "minicart" nella barra di navigazione non causi un "mix" di dati fra i clienti.