Choosing Between Shopware 6 Built‑In Reverse Proxy and External Varnish for Cache Invalidation

Answer to the three specific questions

1. Does the built‑in reverse proxy provide sufficient invalidation granularity for frequent product updates on a high‑traffic site?

In most production setups, the built‑in reverse proxy is adequate for routine product updates, as it tags each cached entry with the entity’s primary key (e.g., product‑1234) and invalidates only those entries when the administration changes the product. However, if you generate a new tag for every SKU change or use nested tag hierarchies, the proxy may end up clearing a large portion of the cache, reducing hit rates. The granularity is therefore tied directly to how you structure tags in your update pipeline.

2. How does Varnish handle tag‑based invalidation compared to Shopware’s internal mechanism, especially regarding TTLs and purge propagation?

Varnish uses BAN or PURGE requests that target surrogate keys (e.g., product‑1234). When configured with the surrogate-key header, Varnish can invalidate exactly the objects that match the key, without touching unrelated cache entries. TTLs are controlled by the Cache‑Control header sent by Shopware; Varnish respects these values unless overridden in its own configuration. Propagation is immediate for a single Varnish instance, but in a multi‑node deployment you must ensure the BAN request is routed to all nodes, which can be achieved with the ban‑by‑key module or a CDN that propagates BANs automatically.

3. What are the security implications of misconfigured trusted proxies when using the built‑in reverse proxy versus an external Varnish setup?

The built‑in proxy limits invalidation to authenticated administration sessions, so an attacker cannot trigger a purge by forging a request. In contrast, an external Varnish or CDN requires a trusted‑proxy header (or a signed token) to accept BAN/PURGE requests. If this header is misconfigured or omitted, any host can send purge requests, potentially leaking personalized or locale‑specific content between users. Therefore, secure configuration of the trusted‑proxy mechanism is critical when using Varnish or a CDN.

Practical verification steps for this case

1. After a product update in Administration, open the Shopware log file var/log/cache_tag.log (or the equivalent in your environment) and confirm that entries for product‑{id} were removed within seconds of the update.

2. Send a test PURGE request to Varnish:

   curl -X PURGE -H "Host: storefront.example.com" -H "X-Forwarded-For: 127.0.0.1" -H "X-Trusted-Proxy: secret‑token" https://varnish.example.com/cache/product-1234
   

   Check for a 200 OK response and that subsequent GET requests for the same product return fresh content.

3. Verify TTL alignment by inspecting the Cache‑Control header sent by Shopware for a cached product page and comparing it to the max-age setting in Varnish’s vcl_recv or CDN configuration.

4. Test the trusted‑proxy guard by attempting a PURGE without the X-Trusted-Proxy header and ensuring the response is 403 Forbidden or 404 Not Found.

Missing diagnostic detail that could change the recommendation

Could you confirm whether your product update pipeline generates a new tag for every SKU change or reuses existing tags? This determines whether tag cardinality will limit the built‑in proxy’s granularity and may push you toward a surrogate‑key‑driven Varnish setup.