Was ist Varnish Cache: Installation und Grundkonfiguration von Varnish Cache Server

Varnish Cache ist ein Reverse-Proxy-Cache, der vor dem Webserver HTTP-Antworten im Arbeitsspeicher ablegt und gleiche Anfragen beantwortet, ohne den Ursprungsserver zu fragen. Als wir Varnish 6.6.2 auf einem AlmaLinux-9.8-Server vor WordPress setzten, wurden die Seiten wegen max-age=0 nicht gecacht; wir haben das gelöst, indem wir in VCL eine Speicherdauer festgelegt haben.

Welche Anfragen gecacht werden und wie lange sie gespeichert bleiben, legst du in einer VCL-Datei (Varnish Configuration Language) fest.

1️⃣ Konzept von Varnish Cache: Reverse-Proxy-Cache

Varnish prüft bei jeder Anfrage zuerst, ob eine gespeicherte Antwort vorhanden ist. Wird mit einer gespeicherten Antwort geantwortet, ist das ein Cache-Treffer (HIT); muss die Antwort vom Ursprungsserver (Backend) geholt werden, ist es ein Cache-Fehlschlag (MISS). Eine bei einem Fehlschlag geholte Antwort wird für die Speicherdauer abgelegt und für die nächsten Anfragen verwendet.

Das Open-Source-Varnish unterstützt kein TLS und kann HTTPS-Anfragen daher nicht direkt annehmen. Auf Port 443 übernimmt Nginx oder HAProxy das TLS und gibt die Anfrage dann an Varnish weiter.

Das Open-Source-Projekt Varnish Cache heißt ab Version 9.0, erschienen im März 2026, Vinyl Cache. Den Namen Varnish Cache trägt weiterhin die Version, die Varnish Software mit zusätzlichen TLS-Funktionen verteilt.

2️⃣ Varnish Cache Server installieren

Unter AlmaLinux 9 installierst du es mit dem Paket varnish aus dem Standard-Repository (AppStream); dieses Paket ist Varnish 6.6.2, also die Version vor der Umbenennung.

dnf -y install varnish

Nach der Installation prüfst du die Version mit [varnishd -V].

varnishd -V

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

Die Pakete der RHEL-Familie behalten die Version 6.6.2, deren Support durch das Projekt beendet ist, und liefern sie nur mit zusätzlichen Sicherheitskorrekturen aus. Das im Juni 2025 erschienene Paket 6.6.2-7 enthält die Korrektur einer HTTP-Request-Smuggling-Schwachstelle (CVE-2025-47905).

Bei der Installation werden auch [/etc/varnish/default.vcl] und [/usr/lib/systemd/system/varnish.service] angelegt.

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

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

[-a :6081] legt den Port fest, der Anfragen annimmt, und [-s malloc,256m] die 256MB Arbeitsspeicher, die als Cache-Speicher dienen.

3️⃣ Grundkonfiguration: Backend und Port

In der Standard-VCL-Datei [/etc/varnish/default.vcl] ist von Anfang an Port 8080 desselben Servers als Backend eingetragen.

vcl 4.1;

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

Bei Apache änderst du den Wert von [Listen] in [httpd.conf] auf 8080, damit Apache die von Varnish weitergegebenen Anfragen annimmt.

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

Bei Websites mit HTTPS lässt du Varnish auf Port 6081 und bindest Nginx, das das TLS übernimmt, so an, dass es die Anfragen an Varnish weitergibt.

Ein Aufbau, bei dem Varnish Anfragen direkt auf Port 80 annimmt, passt zu Websites, die nur HTTP nutzen. Dann legst du wie in der Installationsanleitung von Varnish Software eine Kopie der Service-Datei an und änderst in der Zeile [ExecStart] 6081 in 80.

systemctl edit --full varnish

Die im Editor gespeicherte Kopie wird unter [/etc/systemd/system/varnish.service] angelegt, und der geänderte Port bleibt auch bei Paket-Updates erhalten.

systemctl enable --now varnish

Egal welchen Aufbau du wählst: Zum Schluss richtest du mit dem Befehl enable und der Option now den automatischen Start beim Booten ein und startest Varnish sofort.

4️⃣ Funktion prüfen: X-Varnish- und Age-Header

Nachdem Varnish läuft, prüfst du anhand der Antwort-Header, ob WordPress-Seiten tatsächlich aus dem Cache kommen. Die Anfrage geht ohne Umweg über Nginx direkt an Port 6081 von Varnish; Domain und HTTPS gibst du daher mit den Headern [Host] und [X-Forwarded-Proto] mit.

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] ist die Nummer, die Varnish der Anfrage gibt, und [Via: 1.1 varnish] zeigt, dass die Antwort über Varnish gelaufen ist. [Age] ist die Zeit (in Sekunden), seit die Antwort im Cache gespeichert wurde.

Auch als wir dieselbe Anfrage 3 Sekunden später erneut schickten, hatte [X-Varnish] nur eine Nummer und [Age] war 0 – wieder hatte der Ursprungsserver geantwortet. Eine Regel, die das Cache-Plugin in [.htaccess] eingetragen hatte, hängt an HTML [max-age=0] an, sodass die Standardkonfiguration von Varnish die Speicherdauer mit 0 Sekunden berechnete.

Anfragen mit Cookies umgehen in der Standardkonfiguration ebenfalls den Cache. Das gilt auch für Cookies von Analyse-Tools, sodass alle Anfragen von Besuchern mit solchen Cookies an den Ursprungsserver gehen.

Die VCL unten gibt Login- und Admin-Anfragen sowie Anfragen, die weder GET noch HEAD sind, an den Ursprungsserver weiter und cacht die übrigen Anfragen, nachdem die Cookies entfernt wurden. Antworten mit 0 Sekunden Speicherdauer, die keine Cookies setzen, werden 10 Minuten gespeichert; Antworten, die das Speichern untersagen wie [no-cache], werden nicht gespeichert.

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

Nach einer Änderung an der VCL-Datei lädst du sie mit [systemctl reload varnish] neu. Unten siehst du die zweite von zwei Antworten, als wir dieselbe Anfrage zweimal an Varnish mit dieser VCL geschickt haben.

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)

Die zweite Anfrage, 3 Sekunden nach dem Anwenden der VCL gesendet, hatte zwei Nummern in [X-Varnish], und [Age] war 3. Zwei Nummern bedeuten, dass der Cache geantwortet hat; die zweite Nummer gehört zu der Anfrage, die die Seite vom Ursprungsserver geholt und gespeichert hat.

Die Anfrage mit Login-Cookie hatte eine Nummer und wurde vom Ursprungsserver beantwortet, die Anfrage nur mit dem Cookie des Analyse-Tools dagegen aus dem Cache.

🔢 FAQ & empfohlene Inhalte

ℹ️ Affiliate-Hinweis
Die Inhalte dieser Website enthalten Affiliate-Links. Kauft ein Besucher über einen dieser Links ein Produkt oder eine Dienstleistung, erhält die Website vom Verkäufer eine Provision. Der Betrag, den der Käufer zahlt^{(bei Aktionsrabatten sinkt er ↓)}, steigt dadurch nicht. Angegebene Preise, Rabatte und Lagerbestände entsprechen dem Stand bei Erstellung und können abweichen; prüfe sie daher vor dem Kauf beim Verkäufer. Produkte werden nach eigenen Kriterien ausgewählt und bewertet, und Provisionen beeinflussen weder die Reihenfolge noch den Inhalt der Bewertungen.