Download websites that use Varnish

About Varnish

A cache is designed not to be noticed. Everything a reverse proxy does well makes it harder to see from outside, because a successful cache answers in place of the machine behind it and leaves the visitor with no reason to wonder what happened. That is an awkward property for a detection dataset, and it is the first thing to say about this technology rather than the last.

Varnish sits in front of an origin server and serves stored copies of responses out of memory. Released in 2006 under the BSD licence, with commercial support from Varnish Software, it is configured in its own rules language rather than through a settings page, which is the detail that matters most for interpretation. Nobody ends up with this software by accident. Somebody chose it, wrote rules for it and tested them, which means a detection implies an engineering decision, an origin worth protecting and enough traffic to justify the work.

That inference is what separates this from the rest of the Caching entries. A hosted delivery network can be switched on with a change to a name server record by somebody who has never seen a cache header. A self-managed accelerator implies a team that runs its own infrastructure and treats performance as something to be engineered rather than bought. For a vendor selling observability, security filtering, managed delivery or origin hosting, that population is a far better fit than a general list of busy websites.

As of September 2026 we detect the software on 2,821,951 sites, 1,512,136 of them resolving to United States, with .com the common suffix. We resolve 21 distinct version strings, and 7.0 is the reading we record most frequently. The version readings exist at all only because the proxy announces itself in the response unless told not to, which is precisely the announcement that hardening guides tell operators to remove.

So the undercount here is not an accident of measurement, it is a selection effect, and it runs against the grain of the inference above. The installations we can see are disproportionately the ones left in a default configuration, which means hosting platforms that ship the cache as standard and smaller teams that never got to the hardening checklist. The most sophisticated deployments, run by exactly the teams the technology implies, are the ones most likely to be silent. Treat the count as a visible subset rather than a total, and treat the version distribution as a description of that subset only.

Even as a subset, the population answers questions no single lookup can. How many sites in a given market run a self-managed cache rather than a hosted delivery network? Which content management systems and commerce platforms appear behind it, and does that mix differ by country or suffix? Which version readings persist in the tail, and what else is running on those same hosts? Each of those is a filter over a whole population, and each is the kind of question that precedes a market entry decision, a research paper or an outbound campaign.

A per-domain check tells you whether one site sits behind this cache today, which is useful when you are about to make a call and useless when you are deciding whether to make any. The downloadable list carries the domain, the resolved country, the suffix, the version where we could read one, and the rest of the detected stack for the same site, which is the format the second question needs.