Reverse Proxy (Varnish)

Wenn Shopware hinter Varnish deployt wird, leben gecachte Antworten sowohl in P2Lab Cache (HTTP-Cache Ihres Origins) als auch in Varnish. Beide müssen synchron invalidiert werden, wenn sich Inhalt ändert. P2Lab Cache erweitert den Reverse-Proxy-Mechanismus von Shopware, um Ihnen präzise Kontrolle darüber zu geben, welche Varnish-Tags gepurged werden — über den xkey-VMOD.

Konfigurieren unter Einstellungen → Speed Boost → Reverse Proxy.

Voraussetzungen

Shopware ist bereits so konfiguriert, dass es einen Reverse Proxy nutzt (shopware.http_cache.reverse_proxy.enabled: true in der Shopware-Konfiguration, plus geladener xkey-VMOD in Varnish).
Varnish bietet den Standard-Purge-Endpoint an, den Shopware mitbringt.

Ohne diese Voraussetzungen speichert der Reverse-Proxy-Tab seine Einstellungen, aber es werden keine Purges gesendet — es ist kein Varnish da, mit dem geredet werden könnte.

Varnish-Cache aktivieren

Schalter Reverse Proxy → Einstellungen → Varnish-Cache aktivieren (an Standard). Wenn aus, invalidiert P2Lab Cache nur den eigenen lokalen Cache — Varnish behält veralteten Inhalt bis zum eigenen TTL-Ablauf.

xkey-Invalidierungsstrategie

Wählen Sie eine von drei Strategien unter xkey-Invalidierungsstrategie:

Default

Sendet Shopwares Standard-Tag-Set unverändert. Verhält sich wie die normale Reverse-Proxy-Invalidierung Shopwares.

Verwenden Sie diese, wenn das Cache-Plugin den lokalen Cache verwalten soll, aber Varnish-Purges nicht beeinflussen darf.

Precise

Entfernt Shopwares breite Tags und sendet nur die P2Lab-prefix-Tags (p2c-*). Die Varnish-Schicht wird dann mit exakt demselben feldbewussten Tag-Set invalidiert wie der lokale Cache.

Verwenden Sie diese, wenn Ihr Varnish aggressiv cacht und Sie nicht möchten, dass nicht verwandte Inhalte bei jedem Entitäts-Update gepurged werden.

Smart (Standard)

Dieselbe feldbasierte Analyse wie der lokale Smart-Invalidierungsmodus. Berechnet das minimale Tag-Set auf Basis der tatsächlich geänderten Felder und sendet nur diese Tags.

Paaren Sie das mit Core → Invalidierungsmodus: Smart für vollständige Konsistenz von lokalem und Varnish-Verhalten.

Tag-Blocklist

Manche Tag-Kategorien lösen riesige Purges aus, die man fast nie will — Übersetzungen, Theme-Config, Snippets. Die xkey-Tag-Blocklist erlaubt es, ganze Kategorien vom xkey-Purge auszuschließen. Schaltbare Kategorien:

theme — theme.*
translator — translator.*
config — config.*, system-config-*
route — *-route-*
snippet — snippet-*
rule — rule-*
media — media-*
property_group — property-group-*
manufacturer — manufacturer-*
sales_channel — sales-channel-*
product_stock — p2c-product-stock_*

Markieren Sie die Kategorien, die keine Varnish-Purges auslösen sollen. Der lokale Cache wird weiterhin normal invalidiert — nur der xkey-Header an Varnish wird gefiltert.

Header-Größenbehandlung

Lange Tag-Sets können die maximale Header-Länge überschreiten, die Varnish akzeptiert (typisch 8 KB). Zwei Optionen helfen:

xkey-Header aufteilen

Reverse Proxy → Einstellungen → xkey-Header aufteilen (aus Standard). Wenn an, wird statt eines einzelnen riesigen xkey: tag1 tag2 …-Headers das Tag-Set auf mehrere Header verteilt. Varnish konkateniert automatisch.

Verwenden, wenn Sie häufig Header-Größenlimits treffen und Ihr Varnish-Setup das unterstützt.

xkey-Tags kürzen

xkey-Tags kürzen (aus Standard). Ersetzt jedes Tag durch seinen MD5-Hash. Der Hash ist deterministisch, sodass die Cache-Schicht auch per Hash purgen kann — Invalidierungen funktionieren weiterhin.

Verwenden, wenn einzelne Tags sehr lang sind (z. B. verschachtelte Entitäts-Tags) und Sie auch nach Splitting Header-Limits überschreiten. Trade-off: Tag-Namen werden im Reverse-Proxy-Log opak.

Reverse-Proxy-Log

Schalten Sie Reverse Proxy → Einstellungen → Reverse-Proxy-Log aktivieren an, um jeden xkey-Purge zu protokollieren:

Zeitstempel
Operationstyp (purge / ban)
URL oder Tag-Set
Antwortstatus von Varnish
Die Entität (Typ + ID + Nummer), die den Purge ausgelöst hat, falls bekannt

Browsen Sie das Log von Reverse-Proxy-Log → Liste. Zwei spezialisierte Ansichten helfen, unerwartete Purges zu diagnostizieren:

Entitäts-Timeline — alle xkey-Operationen, die eine bestimmte Entität (Produkt / Kategorie / CMS-Seite) ausgelöst hat
URL-Flow — wie eine bestimmte URL über die Zeit gepurged wurde und welche Entitäten dies ausgelöst haben

Alte Log-Einträge werden nach 30 Tagen automatisch gelöscht — siehe Geplante Tasks.

Statistik-Endpoint

Das Reverse-Proxy-Panel des Dashboards zeigt:

24-Stunden-Überblick (Gesamt-Purges, eindeutige URLs, eindeutige Tags, durchschnittliche Antwortzeit)
Stündliche Aufschlüsselungsgrafik
Top 20 meistgepurgte Tags

Diese kommen vom Endpoint /api/_action/p2lab-cache/reverse-proxy-stats und werden on demand aus der Log-Tabelle berechnet.

Wann die Varnish-Integration deaktivieren

Deaktivieren Sie Varnish-Cache aktivieren, wenn:

Sie lokal testen und kein Varnish laufen lassen
Sie einen anderen Reverse Proxy nutzen (Nginx FastCGI Cache, Cloudflare, Fastly) — für Cloudflare und Fastly setzen Sie CDN-Cache-Control im Dashboard und lassen das CDN nach eigenem TTL ablaufen
Sie möchten, dass Varnish Einträge nur per TTL ablaufen lässt, nicht per Purge