Search intent: informational/procedural — Magento developers configuring or debugging Varnish full-page caching. We cover why Varnish matters, exporting the VCL, its key mechanics, ESI, purging and verification. It pairs with our Redis configuration and cache types guides.

The reason Magento Varnish VCL is the highest-leverage caching work on a Magento store is simple: on a cache hit, the request never reaches PHP. Magento is a heavy application — dependency injection, layout rendering, dozens of database queries — and Varnish lets an anonymous visitor’s category page bypass all of it, returning cached HTML in single-digit milliseconds — the Varnish project introduction explains the model. Redis makes Magento’s own work faster; Magento Varnish VCL means Magento does no work at all for the majority of catalogue traffic. That difference is why Adobe recommends Varnish for production and why it should be configured before micro-optimising anything in the application layer.

You do not write Magento Varnish VCL from scratch — Magento generates it based on your configuration. Set the caching application to Varnish and configure the backend host, then export. The admin path is Stores → Configuration → Advanced → System → Full Page Cache, where you choose “Varnish Caching” and set the backend host and port, TTL and purge hosts; the CLI equivalents are shown below.

# tell Magento to use Varnish as the full-page cache
bin/magento config:set system/full_page_cache/caching_application 2
bin/magento config:set system/full_page_cache/ttl 604800

# export the generated VCL (Varnish 6/7 supported)
bin/magento varnish:vcl:generate 
  --export-version=6 
  --backend-host=localhost 
  --backend-port=8080 
  --output-file=/etc/varnish/default.vcl

sudo systemctl reload varnish
bin/magento cache:flush

The critical deployment detail is the request path. Varnish must sit in front of your web server — typically Varnish on port 80 with nginx or Apache moved to 8080 as the backend. If Varnish is installed but traffic still reaches nginx directly, nothing is cached and the Magento Varnish VCL is inert. Equally, the backend-host and backend-port in the generated VCL must match where your web server actually listens, or every request returns a 503 guru meditation error.

Three mechanisms in the generated Magento Varnish VCL are worth understanding, because they are what you will debug.

ESI hole-punching. A cached page is shared by all anonymous visitors, so anything personal — the mini cart, customer name, recently viewed — cannot be baked into it. Magento marks these blocks as private and Varnish assembles them separately via Edge Side Includes, so the shared page stays cacheable while private fragments are fetched per visitor. When someone reports “my cart shows another customer’s items”, the cause is almost always a block that should be private being cached as shared. Magento’s customer-data/section-load mechanism handles much of this client-side, but ESI remains part of the model.

Tag-based purging. Magento sends cache tags with each response (identifying the products, categories and CMS blocks used to build it). When a product changes, Magento issues a PURGE request to Varnish matching that tag, invalidating only the affected pages rather than the whole cache. This is why the purge_hosts ACL in the Magento Varnish VCL matters: if Magento’s server is not in the ACL, purge requests are rejected and you will serve stale prices after every product update — a subtle and expensive bug.

Grace mode. Varnish can serve slightly stale content while fetching a fresh copy in the background, which protects the origin during traffic spikes and backend slowness. Adobe’s Varnish configuration guide and the Varnish Cache documentation cover both in depth.

A Magento Varnish VCL that is deployed but not actually caching is depressingly common, and it looks identical to a working one until you measure. Two checks settle it. First, enable Magento’s cache debug header in developer mode and inspect responses — X-Magento-Cache-Debug: HIT confirms Varnish served the page from cache. Second, watch Varnish’s own statistics for the cache hit ratio under real traffic.

# does a category page report a cache HIT?
curl -sI https://example.com/category.html | grep -i -E "x-magento-cache-debug|age|x-cache"

# live hit/miss counters
varnishstat -1 | grep -E "cache_hit|cache_miss"

# watch purge requests arriving (edit a product to test)
varnishlog -q 'ReqMethod eq "PURGE"'

# confirm Magento thinks Varnish is the FPC (2 = Varnish)
bin/magento config:show system/full_page_cache/caching_application

Interpreting results: a healthy catalogue-heavy store should show a strong hit ratio for anonymous traffic. Consistent MISS on category pages usually means Varnish is not in the request path, or a cookie or query parameter is defeating caching. And remember that logged-in sessions and cart, checkout and account pages are never cached by Magento Varnish VCL — those rely on Redis and application-level tuning instead. Our Magento team deploys and debugs Varnish as part of performance work.