Reverse proxy (Varnish)

Gdy Shopware jest deployowany za Varnishem, cache’owane odpowiedzi żyją zarówno w P2Lab Cache (HTTP cache Twojego origin), jak i w Varnishu. Oba trzeba inwalidować w sposób spójny, gdy treść się zmienia. P2Lab Cache rozszerza mechanizm reverse-proxy Shopware, by dać Ci precyzyjną kontrolę nad tym, które tagi Varnisha zostaną purgowane, używając vmoda xkey.

Konfiguruj pod Settings → Speed Boost → Reverse proxy.

Wymagania wstępne

Shopware jest już skonfigurowany do użycia reverse proxy (shopware.http_cache.reverse_proxy.enabled: true w konfiguracji Shopware, plus załadowany vmod xkey w Varnishu).
Varnish wystawia standardowy endpoint purge, który Shopware ship’uje.

Bez tego zakładka reverse-proxy nadal zapisuje ustawienia, ale żadne purge nie są wysyłane — nie ma Varnisha, z którym można rozmawiać.

Włącz cache Varnisha

Przełącz Reverse proxy → Settings → Enable Varnish Cache (on domyślnie). Gdy off, P2Lab Cache inwaliduje tylko własny lokalny cache — Varnish trzyma stale treści do wygaśnięcia własnego TTL.

Strategia inwalidacji xkey

Wybierz jedną z trzech strategii w Xkey Invalidation Strategy:

Default

Wysyła standardowy zestaw tagów Shopware bez zmian. Zachowuje się jak waniliowa inwalidacja reverse-proxy Shopware.

Używaj, gdy chcesz, by plugin cache obsługiwał lokalny cache, ale nie ingerował w purge Varnisha.

Precise

Usuwa szerokie tagi Shopware i wysyła tylko tagi z prefiksem P2Lab (p2c-*). Warstwa Varnisha jest wtedy inwalidowana dokładnie tym samym, świadomym pól zestawem tagów co lokalny cache.

Używaj, jeśli Twój Varnish ma agresywne cache’owanie i nie chcesz, by niepowiązana treść była purgowana przy każdej aktualizacji encji.

Smart (domyślny)

Ta sama analiza pól co tryb Smart lokalnej inwalidacji. Wylicza minimalny zestaw tagów na podstawie faktycznie zmienionych pól, potem wysyła tylko te tagi.

Paruj to z Core → Invalidation Mode: Smart dla pełnej spójności zachowania lokalnego + Varnisha.

Blocklista tagów

Niektóre kategorie tagów triggerują wielkie purgi, których prawie nigdy nie chcesz — translations, theme config, snippets. Xkey Tag Blocklist pozwala wyłączyć całe kategorie z xkey purge. Przełączalne kategorie:

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_*

Zaznacz kategorie, które nie powinny triggerować purgów Varnisha. Lokalny cache jest dalej inwalidowany normalnie — tylko nagłówek xkey wysłany do Varnisha jest filtrowany.

Obsługa rozmiaru nagłówków

Długie zestawy tagów mogą przekraczać maksymalną długość nagłówka, którą akceptuje Varnish (typowo 8 KB). Dwie opcje pomagają:

Split xkey Headers

Reverse proxy → Settings → Split xkey Headers (off domyślnie). Gdy on, zamiast wysyłać jeden gigantyczny xkey: tag1 tag2 …, plugin dzieli zestaw tagów na wiele nagłówków. Varnish je automatycznie konkatenuje.

Używaj, gdy często uderzasz w limity rozmiaru nagłówków i Twój setup Varnisha to wspiera.

Shorten xkey Tags

Shorten xkey Tags (off domyślnie). Zastępuje każdy tag jego hashem MD5. Hash jest deterministyczny, więc warstwa cache może purgować po hashu też — inwalidacje wciąż działają.

Używaj, gdy pojedyncze tagi są bardzo długie (np. zagnieżdżone tagi encji) i nawet po splitowaniu przekraczasz limit nagłówka. Trade-off: nazwy tagów stają się nieczytelne w logu reverse-proxy.

Log reverse-proxy

Przełącz Reverse proxy → Settings → Enable Reverse Proxy Log, by zapisywać każdy xkey purge:

Timestamp
Typ operacji (purge / ban)
URL lub zestaw tagów
Status odpowiedzi z Varnisha
Encja (typ + ID + number), która wywołała purge, gdy znana

Przeglądaj log z Reverse proxy log → List. Dwa wyspecjalizowane widoki pomagają diagnozować nieoczekiwane purgi:

Entity timeline — pokaż każdą operację xkey, którą dana encja (produkt / kategoria / CMS page) wywołała
URL flow — pokaż, jak konkretny URL był purgowany w czasie i które encje to spowodowały

Stare wpisy logu są automatycznie usuwane po 30 dniach — zobacz Zadania zaplanowane.

Endpoint statystyk

Panel reverse-proxy w dashboardzie pokazuje:

24-godzinny overview (total purges, distinct URLs, distinct tags, średni czas odpowiedzi)
Wykres rozbicia godzinowego
Top 20 najczęściej purgowanych tagów

Pochodzą z endpointa /api/_action/p2lab-cache/reverse-proxy-stats i są wyliczane na żądanie z tabeli logu.

Kiedy wyłączyć integrację z Varnishem

Wyłącz Enable Varnish Cache, jeśli:

Testujesz lokalnie i nie uruchamiasz Varnisha
Używasz innego reverse proxy (Nginx FastCGI cache, Cloudflare, Fastly) — dla Cloudflare i Fastly ustaw CDN-Cache-Control w dashboardzie i pozwól CDN-owi wygasać wpisy na własnym TTL
Chcesz, by Varnish wygasał wpisy tylko po TTL, nie po purge