How to exclude pages from the Varnish cache

Keep dynamic pages (cart, checkout, account, admin) out of the Varnish full-page cache on TurboStack with a custom VCL pass rule.

Some pages must never be served from a shared full-page cache - the cart, checkout, customer account and admin - because they are personalized or change on every request. Caching them would risk showing one visitor another visitor's page.

Before you start

Varnish enabled on the application - see Configure Varnish.
Access to the host's Advanced > Varnish Options or the Source (YAML) view, where the rule is set.
The exact paths to exclude, as they appear in the address bar.

What Varnish already skips

You usually do not need to configure anything:

Varnish only caches GET and HEAD requests, and by default does not cache requests that carry cookies - so logged-in and checkout traffic already bypasses the cache.
TurboStack ships an app-aware Varnish Configuration Language (VCL) for supported storefronts (Magento, Shopware) that already bypasses the admin, cart and checkout.

Add your own rule only for a custom path the built-in configuration does not cover.

Add a custom exclusion

The supported way to add your own rule is the varnish_customvcl key (a host advanced option, set in the GUI under Advanced > Varnish Options or in the YAML view). Put your vcl_recv rule in it:

varnish_customvcl: |
  sub vcl_recv {
      # Never cache these paths - send them straight to the backend
      if (req.url ~ "^/(my-account|api/live)") {
          return (pass);
      }
  }

return (pass) tells Varnish to skip the cache and go straight to your application for matching requests. Publish the change to apply it. See Configure Varnish for the full list of Varnish keys.

Warning

Custom VCL is for expert use - a wrong rule can cache the wrong content or break the storefront. Match paths precisely and test before relying on it.

Note

Behind the scenes, VCL loads from /etc/varnish/conf.d/ in alphabetical order (the platform's own rules load from a 50-prefixed file). When varnish_customvcl is set, the platform renders an editable 50_main.vcl.sample on the host for reference. Do not create files there by hand over SSH: route your rule through varnish_customvcl so it survives a redeploy.

Verify a page is not cached

Request the page twice and look at the Age response header. A cached response shows a non-zero Age that grows on repeat requests; an excluded page stays at Age: 0 every time:

curl -sI https://www.example.com/my-account | grep -i age

If it did not work

An Age that keeps growing means the rule did not match. Check the path against the regular expression - ^/ anchors it to the start of the path - and confirm the publish finished in History. A publish that fails on the Varnish step means the VCL does not parse; the deploy log shows the line. See Why is my site slow?, or contact support.