Varnish verwandelt eine Medienseite: 90 % Cache-Treffer, fast inaktiver Ursprung, Prozessorrechnung geteilt durch drei. Dann meldet sich ein Redakteur an, veröffentlicht eine dringende Korrektur – und anonyme Personen sehen immer noch den alten Titel, da die Bereinigung nur die Artikel-URL betraf, nicht die Startseite mit dem Tag „listing-news“.
Dieses Szenario veranschaulicht die Natur von Varnish: Es handelt sich nicht um ein verwaltetes CDN, sondern um eine HTTP-Richtlinien-Engine. Sie schreiben in VCL, was gleich ist, was anders ist und was passiert, wenn ein „session_id“-Cookie erscheint. Schlecht gemeistert ist es der schnellste Cache, der die schlechte Wahrheit bedient.
Vor Varnish lautet die Frage nicht „Wie viel RAM?“ » sondern „ist ein angemeldeter Benutzer eine Cache-Variante oder eine Ausnahme?“
Auf einer Medien- oder E-Commerce-Website variiert die Reaktion von Seite zu Seite: Öffentlicher Artikel kann zwischengespeichert werden, Mitglieder-Header im privaten Fragment, Warenkorb wird immer umgangen. Ohne diese schriftliche Matrix wird die VCL zu einer Reihe von Korrekturen nach dem Vorfall.
Mentales Modell: Hash, Pass, Miss
| VCL-Entscheidung | Wirkung |
|---|---|
return (hash) | Im Cache suchen/speichern |
return (pass) | Herkunft, kein Blind |
return (pipe) | Rohtunnel |
return (synth) | Synthetische Reaktion (Wartung) |
Aktueller Ablauf: query → vcl_recv; Sitzungscookie → pass; POST/PUT → bestanden; sonst → Hash mit URL-Schlüssel + Sprache + anonymem Segment; drücken Sie → „liefern“; verpassen → Ursprung → TTL in vcl_backend_response.
Varnish zwingt Sie zur Antwort: Ist ein angemeldeter Benutzer eine Cache-Variante oder eine Ausnahme?
Verbundene Benutzer: drei Muster
Muster 1 – vollständige Umgehung bei Sitzungscookie
„vcl if (req.http.Cookie ~ "PHPSESSID") { return(pass); }
Einfacher, sicherer und belebterer Ursprung für Mitglieder.
**Muster 2 – Hash-Segmentierung**
Gleiche URL, zwei Einträge „role=member“ vs. „anon“. Risiko: zu viele Variationen.
**Muster 3 – ESI (Kantenseite inklusive)**
Zwischenspeicherbare Shell plus „<esi:include src="/private/header">`-Fragment im Durchgang. Kraftvoll, komplex.
:::Hinweis
**Denken Sie daran.** WooCommerce, Symfony-Sicherheit, Django-Sitzung: Listen Sie den **genauen Cookie-Namen** in VCL auf – kein generisches „Cookie vorhanden“, das alles oder nichts umgeht.
:::
## PURGE, BAN und Surrogate-Keys
| Betrieb | Geltungsbereich | Verwendung |
| --- | --- | --- |
| PURGE-URL | Ein Objekt | Geänderter Artikel |
| BAN-Ausdruck | Muster | `ban("req.url ~ /news/")` |
| Verbot von Ersatzschlüsseln | Logisches Tag | `ban("obj.http.Surrogate-Key ~ Article-123")` |
Ursprünglicher Header: „Surrogate-Key: Article-123 Listing-Home“. Bei CMS-Veröffentlichung → Tag „article-123“ plus „listing-home“ verbieten. Ohne Tags säubern Sie von Hand – Vergessenheit garantiert.
## TTL, Anmut und abgestanden
**TTL**: nominelle Frische. **Grace**: Bieten Sie eine abgelaufene Version zu einem niedrigen Preis an – nützlich in Spitzenzeiten, gefährlich bei Aktienkursen. Für E-Commerce: kurze oder keine Nachfrist auf Preisseiten.
Die **Gnade** ermöglicht die Bereitstellung einer veralteten Version, während der Ursprung langsam ist – nützlich bei Spitzenzeiten der Medien, gefährlich für Preis oder Lagerbestand. Dokumentieren Sie die Richtlinie nach Seitentyp: Blog-Beiträge tolerieren zehn Sekunden Veraltung; Produktblatt mit begrenzter Lagernr.
## Hosting und Dimensionierung
Varnish verbraucht viel **RAM**: Planen Sie etwa 1–2 GB plus Cache-Objektgröße ein. Auf VPS: dedizierte Instanz, wenn die Trefferquote mehr als 70 % beträgt; Monitor „varnishstat“ – „cache_hit“, „n_lru_nuked“. Geteilt: Lack nicht verfügbar; Partielles Edge-CDN ohne feinkörnige VCL-Steuerung. Siehe [Dynamischer Seiten-Cache](/de/blog/cache-page-dynamique/) und [CDN- oder Ursprungsoptimierung](/de/blog/cdn-ou-optimisation-origine/). Ohne ein Team zur Wartung der VCL kann ein verwaltetes CDN mit vordefinierten Regeln sicherer sein als ein schlecht abgestimmter Varnish.
## The Summit: Varnish belohnt diejenigen, die ihr Publikum kennen
:::Höhepunkt
**Varnish errät nicht, wer angemeldet ist – es erzwingt Ihre VCL.** Eine schlecht geschriebene Cookie-Regel stellt private Seiten schneller öffentlich bereit, als es Apache ohne Cache jemals tun würde.
:::
## Entscheide dich und gehe ohne blinden Fleck voran
Beginnen Sie mit der Bestandsaufnahme der Cookies und Routen, die immer umgangen werden sollten. Versionieren Sie die VCL in Git und testen Sie das Neuladen vor jeder Veröffentlichung. Schließen Sie die Ersatzschlüssel vom CMS an, um ohne manuelles PURGE zu spülen. Überprüfen Sie abschließend das anonyme Verhalten im Vergleich zum Mitgliederverhalten auf der Startseite, im Konto und im Warenkorb und überwachen Sie dann eine Woche lang die Trefferquote und Sperrungsfehler.
## Häufig gestellte Fragen
### 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.