Varnish transforme un site média : 90 % de hits cache, origine quasi inactive, facture processeur divisée par trois. Puis un éditeur se connecte, publie un correctif urgent — et les anonymes voient encore l'ancien titre parce que la purge n'a touché que l'URL article, pas la page d'accueil taggée listing-news.
Ce scénario illustre la nature de Varnish : ce n'est pas un CDN managé, c'est un moteur de politique HTTP. Vous écrivez en VCL qui est identique, qui est différent, et ce qui se passe quand un cookie session_id apparaît. Mal maîtrisé, c'est le cache le plus rapide pour servir la mauvaise vérité.
Avant Varnish, la question n'est pas « combien de RAM ? » mais « un utilisateur connecté est-il une variante cache ou une exception ? »
Sur un site média ou e-commerce, la réponse varie page par page : article public cacheable, en-tête membre en fragment privé, panier toujours en contournement. Sans cette matrice écrite, la VCL devient une série de correctifs après incident.
Modèle mental : hash, pass, miss
| Décision VCL | Effet |
|---|---|
return (hash) | Cherche/stocke en cache |
return (pass) | Origine, pas de store |
return (pipe) | Tunnel brut |
return (synth) | Réponse synthétique (maintenance) |
Flux courant : requête → vcl_recv ; cookie session → pass ; POST/PUT → pass ; sinon → hash avec clé URL + langue + segment anonyme ; hit → deliver ; miss → origine → TTL dans vcl_backend_response.
Varnish vous force à répondre : un utilisateur connecté est-il une variante cache ou une exception ?
Utilisateurs connectés : trois patterns
Pattern 1 — contournement total si cookie session
if (req.http.Cookie ~ "PHPSESSID") {
return (pass);
}
Simple, sûr, origine plus chargée pour les membres.
Pattern 2 — segmentation hash
Même URL, deux entrées role=member vs anon. Risque : trop de variantes.
Pattern 3 — ESI (Edge Side Includes)
Coque cacheable plus fragment <esi:include src="/private/header"> en pass. Puissant, complexe.
PURGE, BAN et Surrogate-Keys
| Opération | Portée | Usage |
|---|---|---|
| PURGE url | Un objet | Article modifié |
| BAN expression | Motif | ban("req.url ~ /news/") |
| Surrogate-Key ban | Tag logique | ban("obj.http.Surrogate-Key ~ article-123") |
Header origine : Surrogate-Key: article-123 listing-home. À la publication CMS → ban tag article-123 plus listing-home. Sans tags, vous PURGEz à la main — oubli garanti.
TTL, grace et stale
TTL : fraîcheur nominale. Grace : servir une version périmée pendant lenteur origine — utile en pic, dangereux sur prix stock. Pour e-commerce : grace court ou nul sur pages prix.
La grace permet de servir une version périmée pendant que l'origine est lente — utile en pic média, dangereux sur prix ou stock. Documentez la politique par type de page : article de blog tolère dix secondes de stale ; fiche produit avec stock limité non.
Hébergement et dimensionnement
Varnish consomme beaucoup de RAM : planifiez environ 1–2 Go plus taille objets cache. Sur VPS : instance dédiée si taux de hit supérieur à 70 % ; surveillez varnishstat — cache_hit, n_lru_nuked. En mutualisé : Varnish indisponible ; CDN edge partiel sans contrôle VCL fin. Voir Cache page dynamique et CDN ou optimisation origine. Sans équipe pour maintenir la VCL, un CDN managé avec règles prédéfinies peut être plus sûr qu'un Varnish mal réglé.
Le sommet : Varnish récompense ceux qui connaissent leur audience
Décider et avancer sans angle mort
Commencez par inventorier les cookies et les routes qui doivent toujours passer en contournement. Versionnez la VCL dans Git et testez le rechargement avant chaque mise en production. Branchez les Surrogate-Keys depuis le CMS pour purger sans PURGE manuel. Validez enfin le comportement anonyme versus membre sur l'accueil, le compte et le panier, puis surveillez le taux de hit et les échecs de ban pendant une semaine.
Questions fréquentes
Varnish cache-t-il les pages avec cookie de session ?
Par défaut, non : la présence d'un cookie de session doit déclencher un contournement ou un hachage segmenté. Ne servez jamais une page membre à un visiteur anonyme, même si la VCL semble « presque » correcte.
Différence pass, pipe et cache ?
Le mode cache stocke la réponse. Le mode pass interroge l'origine sans stocker. Le mode pipe tunnelise la connexion brute — utile pour des flux non HTTP classiques.
Comment purger après mise à jour ?
Utilisez PURGE ou BAN ciblés, ou mieux un ban Surrogate-Key automatisé depuis le CMS à chaque publication. Évitez les purges globales qui vident tout le cache en pleine heure de pointe.
Varnish devant nginx ou l'inverse ?
L'architecture classique place Varnish en frontal, puis nginx, puis PHP-FPM. Varnish absorbe le trafic répétitif ; nginx gère le détail de l'application et les en-têtes que la VCL ne doit pas casser.
Varnish accélère ce que vous avez décidé d'être identique — le reste est votre responsabilité VCL, documentée et testée avant chaque grosse campagne éditoriale.