Qu'est-ce que Varnish Cache : installation et configuration de base de Varnish Cache Server

Varnish Cache est un cache de proxy inverse qui, placé devant le serveur web, garde en mémoire les réponses HTTP et répond aux mêmes requêtes sans passer par le serveur d'origine. Quand nous avons mis Varnish 6.6.2 devant WordPress sur un serveur AlmaLinux 9.8, les pages n'étaient pas mises en cache à cause de max-age=0 ; nous avons résolu le problème en fixant une durée de conservation dans le VCL.

Les requêtes à mettre en cache et leur durée de conservation s'écrivent dans un fichier VCL (Varnish Configuration Language).

1️⃣ Concept de Varnish Cache : cache de proxy inverse

Pour chaque requête, Varnish vérifie d'abord s'il existe une réponse enregistrée. S'il répond avec une réponse enregistrée, c'est un succès de cache (HIT) ; s'il doit la récupérer auprès du serveur d'origine (backend), c'est un échec de cache (MISS). La réponse récupérée lors d'un échec est conservée pendant sa durée de conservation et sert aux requêtes suivantes.

Varnish open source ne prend pas en charge TLS et ne peut donc pas recevoir directement les requêtes HTTPS. Sur le port 443, Nginx ou HAProxy traite le TLS, puis transmet la requête à Varnish.

Le projet open source Varnish Cache a pris le nom de Vinyl Cache à partir de la version 9.0, sortie en mars 2026. Le nom Varnish Cache reste utilisé par la version que Varnish Software distribue avec des fonctions TLS en plus.

2️⃣ Installer Varnish Cache Server

Sous AlmaLinux 9, vous l'installez avec le paquet varnish du dépôt par défaut (AppStream), et ce paquet correspond à Varnish 6.6.2, la version antérieure au changement de nom.

dnf -y install varnish

Une fois l'installation terminée, vérifiez la version avec [varnishd -V].

varnishd -V

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

Les paquets de la famille RHEL conservent la version 6.6.2, dont le support par le projet est terminé, et la distribuent en y ajoutant seulement des correctifs de sécurité. Le paquet 6.6.2-7, sorti en juin 2025, contient le correctif d'une vulnérabilité de type HTTP request smuggling (CVE-2025-47905).

L'installation crée aussi [/etc/varnish/default.vcl] et [/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] définit le port qui reçoit les requêtes, et [-s malloc,256m] les 256MB de mémoire utilisés comme espace de stockage du cache.

3️⃣ Configuration de base : backend et port

Le fichier VCL par défaut, [/etc/varnish/default.vcl], définit déjà le port 8080 du même serveur comme backend.

vcl 4.1;

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

Pour Apache, remplacez la valeur de [Listen] dans [httpd.conf] par 8080 afin qu'il reçoive les requêtes transmises par Varnish.

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

Pour les sites en HTTPS, laissez Varnish sur le port 6081 et reliez Nginx, qui traite le TLS, pour qu'il transmette les requêtes à Varnish.

Une configuration où Varnish reçoit directement les requêtes sur le port 80 convient aux sites qui n'utilisent que HTTP. Dans ce cas, créez une copie du fichier de service comme l'indique la documentation d'installation de Varnish Software, puis remplacez 6081 par 80 sur la ligne [ExecStart].

systemctl edit --full varnish

La copie enregistrée dans l'éditeur est créée dans [/etc/systemd/system/varnish.service], et le port modifié est conservé même après une mise à jour du paquet.

systemctl enable --now varnish

Quelle que soit la configuration choisie, terminez avec la commande enable et l'option now pour activer le démarrage automatique tout en lançant Varnish immédiatement.

4️⃣ Vérifier le fonctionnement : en-têtes X-Varnish et Age

Une fois Varnish lancé, vérifiez avec les en-têtes de réponse si les pages WordPress viennent réellement du cache. La requête est envoyée au port 6081 de Varnish sans passer par Nginx ; le domaine et le HTTPS sont donc indiqués avec les en-têtes [Host] et [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] est le numéro que Varnish attribue à la requête, et [Via: 1.1 varnish] indique que la réponse est passée par Varnish. [Age] est le temps (en secondes) écoulé depuis l'enregistrement de la réponse dans le cache.

Quand nous avons renvoyé la même requête 3 secondes plus tard, [X-Varnish] n'avait toujours qu'un numéro et [Age] valait 0 : c'est encore le serveur d'origine qui a répondu. Une règle que l'extension de cache a placée dans [.htaccess] ajoute [max-age=0] au HTML, si bien que la configuration par défaut de Varnish a calculé une durée de conservation de 0 seconde.

Les requêtes avec des cookies ne passent pas non plus par le cache dans la configuration par défaut. Il en va de même pour les cookies des outils d'analyse d'audience : toutes les requêtes des visiteurs qui ont ces cookies vont au serveur d'origine.

Le VCL ci-dessous transmet au serveur d'origine les requêtes de connexion et d'administration ainsi que les requêtes autres que GET ou HEAD, et met en cache les autres requêtes après avoir supprimé leurs cookies. Les réponses dont la durée de conservation est de 0 seconde et qui ne créent pas de cookies sont conservées 10 minutes, et les réponses qui demandent à ne pas être conservées, comme [no-cache], ne le sont pas.

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;
    }
}

Après avoir modifié le fichier VCL, rechargez-le avec [systemctl reload varnish]. Voici la seconde des deux réponses obtenues en envoyant deux fois la même requête à Varnish avec ce VCL appliqué.

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 seconde requête, envoyée 3 secondes après l'application du VCL, avait deux numéros dans [X-Varnish] et [Age] valait 3. Deux numéros signifient que le cache a répondu, et le second numéro est celui de la requête qui a récupéré la page auprès du serveur d'origine et l'a enregistrée.

La requête avec un cookie de connexion avait un seul numéro et a reçu la réponse du serveur d'origine, tandis que celle qui ne portait que le cookie de l'outil d'analyse a reçu la réponse du cache.

🔢 FAQ & contenus recommandés

ℹ️ Mention d'affiliation
Le contenu de ce site contient des liens d'affiliation. Lorsqu'un visiteur achète un produit ou un service via l'un de ces liens, le site perçoit une commission du vendeur. Le montant payé par l'acheteur^{(il baisse lors des promotions ↓)}, lui, n'augmente pas. Les prix, remises et stocks indiqués correspondent à la date de rédaction et peuvent différer ; vérifiez-les donc auprès du vendeur avant d'acheter. Les produits sont choisis et évalués selon nos propres critères, et les commissions n'influencent ni l'ordre de présentation ni le contenu des évaluations.