(Open) questions in my Varnish context

Re: Point 1 – “No known cache service detected” but X-Cache shows HIT

This is a false negative from our header-based detection. The detection uses heuristics that look for specific header patterns, and not all Varnish configurations expose the headers our detection expects.

The cache debug relying on headers heuristics can never cover 100% of setups out there – some services simply will hide cache header, and then it is expected (and quite normal!) for debug cache page to assume you have no cache setup.

The key fact: you’re seeing X-Cache: HIT – this confirms Varnish IS caching your content. The “no cache service detected” message is simply wrong in your case.

We just released version 5.5.3 which includes a new End-to-End Cache Test (in Proxy Cache → Check Caching → first tab). This test doesn’t rely on header detection at all – it actually creates a test post, verifies caching works, triggers a purge, and confirms purging works.

Please update and run this test for a definitive answer.

About purging: The plugin will still send PURGE requests to your cache when content is updated. Whether they work depends on your Varnish configuration accepting them. The new E2E test will verify this for you.

Re: Point 2 – Also, the “Cache-control:” value is empty as I removed max-age and ExpiresDefault from .htaccess while I do these tests.

WordPress does not send Cache-Control for posts by default. It means that Varnish will cache with whichever is default cache lifetime in your server environment.

If you’re seeing Cache-Control coming from your WordPress, it may be two of these major things:

* Bad plugins (ANY plugin not just cache, etc.) – those are typically that start PHP session with no reason whatsoever by performing session_start() in PHP code, the end result is negative cache control, and Set-Cookie being present in the response – this same like to say to Varnish “don’t cache me”
* Good plugins would emit Cache-Control with a date in the future (so that Varnish knows to cache specific pages with a fine-grained cache lifetime).

Only way to tell for sure, is to disable all the plugins and examine response headers from your website while enabling plugins one by one.

https://github.com/dvershinin/varnish-http-purge/wiki/Troubleshooting

About “Purge Cache” from the menu not working:

This is curious since the E2E test uses the same purge mechanism. A few things to check:

• Cache IP setting: Go to Proxy Cache → Settings and check if a Cache IP is configured. If it’s empty, try setting it to 127.0.0.1 or localhost. Some hosts require this to be explicitly set.
• What the menu purges: The “Purge Cache” button in the admin bar sends a full-site regex purge (/.*), whereas the E2E test purges a specific URL. Your host’s Varnish might accept specific URL purges but block regex/wildcard purges for security.
• Ask your host: Since you mentioned using their control panel works — your host may have intentionally disabled regex PURGE requests (or simply never supported) or requires a specific kind of request for complete cache clear which is known only to them. You may want to ask: “I want to clear my whole Varnish cache using curl, what should I run on the command line?” – you can follow up here, and maybe there’s a new purge method to be born for a host-specific cache clear.
• If specific-URL purges work (E2E test) but full-site purges don’t (menu), that’s actually fine for normal operation — the plugin automatically purges relevant URLs when you edit content. The “Purge Cache” button is really only needed for emergency full-site clears.

About Age=0:

If X-Cache-Age shows proper values on actual pages but Age header is 0, your host is likely stripping the standard Age header while keeping their custom X-Cache-Age header. This is just a cosmetic difference — your caching is working.

Glad the E2E test helped clarify things!

soft purge is definitely a good thing!

@didierjm great write up!

Worth noting about .htaccess like the following: ExpiresDefault "access plus 30 days"
… might instruct both browsers and Varnish to cache pages for 30 days, which is often undesired (depends on actual setup).

Plugins like Cacheability Pro solve this by allowing you to fine tune Cache-Control sent by WordPress to make use of s-maxage instruction which is what applies only to Varnish:

Cache-Control: max-age=60, s-maxage=86400

In this example, page is cached for up to a minute *in browser*, while instructing Varnish to cache for a day.

In fact, s-maxage should be set even to months to make the Varnish cache highly efficient – cache never goes stale, because it is cleared automatically by Proxy Cache Purge.

P.S. An alternative to s-maxage modifications via plugins is editing Varnish VCL configuration directly, but in shared hosting that is likely not available.

@didierjm Thanks for the update!

Actually, max-age=0 with s-maxage is the correct Varnish configuration pattern. Here’s what it means:

Cache-Control: max-age=0, s-maxage=86400

• max-age=0 → browsers always revalidate with the server (no browser caching)
• s-maxage=86400 → Varnish caches for 24 hours

This is actually optimal for WordPress because:

1. Browsers always get fresh content from Varnish
2. Varnish serves cached content at lightning speed
3. When you edit a post, Proxy Cache Purge clears only Varnish — browsers automatically see the update on next request

The duplicate max-age=0 in headers you mentioned is a separate issue — that would indeed be a bug that was now addressed in the recent Cacheability release. That said, it can’t possibly detect max-age you set in .htaccess – you either use a plugin to do it, or rely on .htaccess alone. The plugin way gives you flexibility that .htaccess doesn’t.

Good news: We just released Proxy Cache Purge 5.6.5 which now correctly recognizes max-age=0 with s-maxage > 0 as valid Varnish configuration. Previously, the cache detection would flag this as “not properly caching” — that false warning is now fixed.

Since you’re running 4 blogs across 3 servers, you might find GetPageSpeed Amplify useful — it’s a free monitoring dashboard that shows Varnish cache hit ratios, backend health, and object stats across all your servers in one place.

Glad everything is working for you!