Reverse proxy (Varnish)

When Shopware is deployed behind Varnish, cached responses live both in P2Lab Cache (your origin’s HTTP cache) and in Varnish. Both need to be invalidated in lockstep when content changes. P2Lab Cache extends Shopware’s reverse-proxy mechanism to give you precise control over which Varnish tags get purged, using the xkey vmod.

Configure under Settings → Speed Boost → Reverse proxy.

Prerequisites

Shopware is already configured to use a reverse proxy (shopware.http_cache.reverse_proxy.enabled: true in your Shopware config, plus the xkey vmod loaded in Varnish).
Varnish exposes the standard purge endpoint Shopware ships with.

Without those, the reverse-proxy tab still saves settings but no purges are sent — there is no Varnish to talk to.

Enable Varnish cache

Toggle Reverse proxy → Settings → Enable Varnish Cache (on by default). When off, P2Lab Cache only invalidates its own local cache — Varnish keeps stale content until its own TTL expires.

Xkey invalidation strategy

Pick one of three strategies under Xkey Invalidation Strategy:

Default

Sends Shopware’s standard tag set unchanged. Behaves like vanilla Shopware reverse-proxy invalidation.

Use when you want the cache plugin to handle the local cache but not interfere with Varnish purges.

Precise

Strips Shopware’s broad tags and sends only the P2Lab-prefixed tags (p2c-*). The Varnish layer is then invalidated by exactly the same field-aware tag set the local cache uses.

Use this if your Varnish has aggressive caching and you do not want unrelated content to be purged on every entity update.

Smart (default)

Same field-level analysis as the Smart local invalidation mode. Computes the minimal tag set based on which fields actually changed, then sends only those tags.

Pair this with Core → Invalidation Mode: Smart for fully consistent local + Varnish behaviour.

Tag blocklist

Some tag categories trigger huge purges that you almost never want — translations, theme config, snippets. The Xkey Tag Blocklist lets you exclude entire categories from xkey purges. Toggleable categories:

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

Tick the categories you don’t want to trigger Varnish purges. The local cache is still invalidated as usual — only the xkey header sent to Varnish is filtered.

Header size handling

Long tag sets can exceed the maximum header length Varnish accepts (typically 8 KB). Two options help:

Split xkey Headers

Reverse proxy → Settings → Split xkey Headers (off by default). When on, instead of sending one giant xkey: tag1 tag2 … header, the plugin splits the tag set across multiple headers. Varnish concatenates them automatically.

Use when you frequently hit header-size limits and your Varnish setup supports it.

Shorten xkey Tags

Shorten xkey Tags (off by default). Replaces each tag with its MD5 hash. The hash is deterministic, so the cache layer can purge by hash as well — invalidations still work.

Use when individual tags are very long (e.g. nested entity tags) and even after splitting you exceed header limits. Trade-off: tag names become opaque in the reverse-proxy log.

Reverse-proxy log

Toggle Reverse proxy → Settings → Enable Reverse Proxy Log to record every xkey purge:

Timestamp
Operation type (purge / ban)
URL or tag set
Response status from Varnish
The entity (type + ID + number) that triggered the purge, when known

Browse the log from Reverse proxy log → List. Two specialised views help diagnose unexpected purges:

Entity timeline — show every xkey operation a given entity (product / category / CMS page) triggered
URL flow — show how a specific URL was purged over time and which entities caused it

Old log entries are pruned automatically after 30 days — see Scheduled tasks.

Stats endpoint

The dashboard’s reverse-proxy panel shows:

24-hour overview (total purges, distinct URLs, distinct tags, average response time)
Hourly breakdown chart
Top 20 most-purged tags

These come from the /api/_action/p2lab-cache/reverse-proxy-stats endpoint and are computed on demand from the log table.

When to disable Varnish integration

Disable Enable Varnish Cache if:

You’re testing locally and don’t run Varnish
You use a different reverse proxy (Nginx FastCGI cache, Cloudflare, Fastly) — for Cloudflare and Fastly, set CDN-Cache-Control in the dashboard and let the CDN expire entries on its own TTL
You want Varnish to expire entries by TTL only, not by purge