Varnish

What Is Varnish?

Varnish is a high-performance HTTP reverse proxy and web accelerator that sits in front of web servers to cache responses and serve them at extremely high speed. Rather than letting every request travel all the way to an application server and database, Varnish stores ready-made copies of pages and assets in memory and returns them directly, which can reduce response times dramatically and shield the origin from traffic spikes.

Varnish Cache is open-source software, first released in 2006 and developed in the open by the Varnish Cache project, with a commercial distribution and support offered by Varnish Software. It is widely deployed in front of high-traffic websites, news publishers, ecommerce stores, and APIs, and it is one of the most recognizable caching layers on the public web because it stamps its own fingerprints onto the HTTP responses it serves.

It is important to be precise about what Varnish is and is not. Varnish is not a web server in the sense that Apache or Nginx are; it does not, by itself, run application code, execute PHP, or read files from disk to build a page. Instead it is a caching reverse proxy that you place in front of one or more origin servers. When a request can be answered from the cache, Varnish answers it without bothering the origin at all. When it cannot, Varnish forwards the request to the backend, stores the response according to its rules, and hands it back to the visitor. This division of labor is the whole point: the origin does the expensive work once, and Varnish serves the cheap copy many times.

Varnish is also not a content delivery network on its own, although it is frequently the engine inside one. Several large CDNs and edge platforms build their caching tier on Varnish or on technology derived from it, which is why the signals described below sometimes appear even when a site is fronted by a commercial CDN rather than a self-managed Varnish box. Understanding that relationship helps when you are trying to work out exactly where in a site's delivery chain the caching is happening.

How Varnish Works

At the center of Varnish is an in-memory object store. When a response is deemed cacheable, Varnish keeps the object in RAM (with optional disk-backed storage for very large caches) and serves subsequent matching requests directly from memory. Because RAM is orders of magnitude faster than regenerating a page from an application and database, a "cache hit" is returned almost instantly and places no load on the origin.

Varnish's behavior is controlled by the Varnish Configuration Language (VCL), a small domain-specific language that operators use to express caching policy. VCL is compiled to native code for speed, and it lets administrators decide, request by request, what to cache, for how long, which cookies and headers to consider, when to bypass the cache, and how to normalize requests so that more of them result in hits. This programmability is a defining feature: rather than a handful of fixed settings, VCL gives engineers fine-grained control over the entire request and response lifecycle through hooks such as vcl_recv, vcl_backend_response, and vcl_deliver.

A request moves through Varnish in stages. It arrives and is evaluated in vcl_recv, where Varnish decides whether to look in the cache or pass straight to the backend. On a hit, the stored object is delivered. On a miss, Varnish contacts a configured backend (the origin web server), receives the response, evaluates it in vcl_backend_response to decide whether and how long to store it, and then delivers it to the client while keeping a copy. Varnish supports multiple backends, health checks, and load balancing across them, so it can also act as a traffic director in front of a pool of origins.

Two capabilities make Varnish especially valuable under stress. The first is grace mode, which lets Varnish keep serving a slightly stale cached object while it refreshes the content in the background, so visitors are not blocked waiting for the origin. The second is the closely related ability to serve stale content when the backend is unhealthy, which keeps a site online even if the application tier is struggling. Combined with the request-coalescing behavior that collapses many simultaneous requests for the same uncached object into a single backend fetch, these features explain why Varnish is a go-to tool for sites that face sudden traffic surges.

Operators interact with a running Varnish instance through tools such as varnishadm for administration, varnishlog for detailed request logging, and varnishstat for live metrics. Cache invalidation is handled through purges and bans, which let teams remove or expire specific objects when content changes, so that a cached page does not outlive the data it represents.

How to Tell if a Website Uses Varnish

Varnish leaves clear, well-documented fingerprints in HTTP response headers, which is exactly the layer StackOptic inspects from the server side. Because Varnish operates at the HTTP level rather than in the page markup, the most reliable signals are in the headers rather than the HTML body.

The Via header. Varnish identifies itself in the standard Via response header, typically with a value like 1.1 varnish (and sometimes a version, such as 1.1 varnish (Varnish/6.0)). The Via header exists precisely to record proxies in the request path, and Varnish populates it by default, making this one of the most dependable tells.

X-Varnish headers. Varnish adds an X-Varnish header containing one or two transaction IDs. A single ID indicates a cache miss; two IDs (the current request ID plus the ID of the cached object) indicate a cache hit. Seeing X-Varnish at all is strong evidence of Varnish, and the number of IDs even tells you whether the response was served from cache.

Cache-status headers. Many Varnish deployments add a custom header such as X-Cache: HIT or X-Cache: MISS (sometimes X-Cache-Hits with a count) via VCL. These are configured rather than automatic, but they are a common convention and reinforce the diagnosis when present alongside X-Varnish.

Age and behavior under repeated requests. Cached responses carry an Age header showing how long the object has been in cache, and you can watch the Age value grow across repeated requests. Hitting the same URL twice and seeing the response time drop and the X-Varnish header switch from one ID to two is a practical confirmation that caching is active.

Here is how to check each signal yourself:

Method	What to do	What Varnish reveals
curl -I	Run curl -I https://example.com	Via: ... varnish, X-Varnish, Age, and any X-Cache header
Browser DevTools	Open the Network tab, select the document request, read Response Headers	The same Via, X-Varnish, and X-Cache headers per request
Repeated request	Request the URL twice and compare	X-Varnish changing from one ID to two, growing Age, faster timing on the hit
Wappalyzer	Run the extension on the live page	Frequently identifies "Varnish" under caching/server
BuiltWith	Look up the domain	Reports Varnish in the server/CDN profile when headers are exposed

A fast terminal check is curl -sI https://example.com | grep -iE "via|x-varnish|x-cache|age". If you see a varnish token in Via or any X-Varnish header, the site is being served through Varnish. For background on reading these headers, see our guide on how to read a website's HTTP headers, and for the broader picture of identifying a site's delivery layer, see how to find out what technology a website uses.

A few caveats make multi-signal analysis worthwhile. Security-conscious operators sometimes strip or rename the Via and X-Varnish headers in VCL so that the caching layer does not advertise itself, and some CDNs that are built on Varnish rewrite these headers under their own brand. When the obvious headers are hidden, the behavioral signal, a response that gets faster on a second request and carries a climbing Age value, still points to caching even if it cannot name the software with certainty. Because Varnish is so often combined with a separate front-line CDN and a back-end web server, the most accurate conclusion comes from reading the full set of response headers together rather than relying on any single line. Server-side analysis is well suited to this because it fetches the raw headers directly. If you want to distinguish a self-hosted Varnish layer from a managed edge network, our guide on how to tell if a website uses Cloudflare or another CDN is a useful companion, and you can compare Varnish with an edge platform like Fastly, whose network is itself built on a Varnish-derived core.

Key Features

• In-memory caching. Stores responses in RAM for near-instant delivery, dramatically reducing origin load and latency.
• VCL programmability. A compiled configuration language gives precise, request-level control over caching policy, normalization, and routing.
• Grace mode and stale-while-revalidate. Serves slightly stale content during background refreshes and when the backend is unhealthy, improving resilience.
• Request coalescing. Collapses simultaneous requests for the same uncached object into a single backend fetch, preventing stampedes.
• Backend health checks and load balancing. Distributes traffic across multiple origins and routes around unhealthy ones.
• Flexible invalidation. Purges and bans remove or expire cached objects precisely when content changes.
• Rich observability. varnishlog, varnishstat, and related tools expose detailed, real-time insight into cache behavior.

Pros and Cons

Pros

• Exceptional throughput and low latency for cacheable content, often improving page speed and Core Web Vitals.
• Protects origins from traffic spikes and can keep a site available even when the application tier falters.
• Highly configurable through VCL, allowing caching policy to be tuned to almost any site's needs.
• Open source with no licensing fees for the community edition, plus a commercial option for enterprises.

Cons

• VCL has a learning curve, and getting caching rules right (especially around cookies and personalization) takes expertise.
• Caching dynamic, per-user content requires careful design to avoid serving the wrong response to the wrong visitor.
• Varnish historically caches HTTP only, so TLS termination is typically handled by a separate component in front of it.
• As infrastructure, it adds an operational layer to deploy, monitor, and maintain compared with relying solely on a managed CDN.

Varnish vs Alternatives

Varnish competes with other caching and reverse-proxy approaches, from web servers with built-in caching to edge platforms. The table below clarifies where it fits.

Technology	Type	Caching model	Best for
Varnish	Dedicated reverse-proxy cache	In-memory, VCL-controlled	High-traffic sites needing programmable, self-managed caching
Nginx	Web server / reverse proxy	Built-in proxy cache	Teams wanting caching plus serving and TLS in one component
Fastly	Edge cloud / CDN	Varnish-derived, globally distributed	Global edge caching with managed infrastructure
Cloudflare	CDN / security platform	Managed edge cache	Sites wanting CDN, caching, and security in one service
Apache Traffic Server	Reverse-proxy cache	In-memory and disk	Large-scale proxy caching at the infrastructure level

For teams choosing between self-managed caching and a managed edge, the trade-off is control versus operational simplicity. Varnish offers the deepest control through VCL; managed CDNs offer global reach without running servers. Many architectures combine them, placing Varnish near the origin and a CDN at the edge.

Use Cases

Varnish is most at home in front of high-traffic, content-heavy websites where the same pages are requested many times. News and media publishers use it to absorb sudden surges when a story goes viral, serving cached articles to huge audiences without overwhelming the CMS. Ecommerce sites use it to accelerate category and product pages while carefully bypassing the cache for carts and checkout.

It also suits busy blogs and marketing sites built on database-driven platforms, public APIs that return frequently repeated responses, and any origin that needs protection from traffic spikes. Because Varnish can serve stale content when the backend is down, it is valuable for resilience as well as raw speed.

A representative scenario is a large publication whose homepage and top articles are read by millions but updated only periodically. Varnish caches those pages and serves them from memory, so the application servers handle only cache misses and editorial updates rather than every reader. Another is an ecommerce store that caches anonymous browsing traffic aggressively while using VCL rules to ensure logged-in shoppers and checkout flows always reach the origin, balancing speed with correctness.

From a technology-research perspective, detecting Varnish on a site tells you that the operator has invested in a serious caching strategy, which usually indicates meaningful traffic and an engineering team comfortable managing infrastructure. That is useful context for vendors, agencies, and analysts profiling a site's sophistication and likely scale.

Frequently Asked Questions

Is Varnish a web server or a CDN?

Neither, strictly speaking. Varnish is a reverse-proxy cache (an HTTP accelerator) that sits in front of a web server. It does not run application code like a web server, and it is not a globally distributed network like a CDN, though several CDNs are built on Varnish technology. In practice it is deployed alongside a web server such as Nginx or Apache and, often, behind a CDN.

What does the X-Varnish header mean?

X-Varnish carries one or two transaction IDs that Varnish assigns to requests. A single ID means the response was a cache miss fetched from the origin, while two IDs mean it was a cache hit served from a stored object (the second ID identifies that object). Seeing the header at all is strong evidence the site is served through Varnish, and the ID count tells you whether caching is working.

Can Varnish cache HTTPS sites?

Yes, but Varnish itself classically handles HTTP, so TLS is usually terminated by a separate component in front of it, such as a load balancer, an Nginx instance, or a CDN, which then passes plain HTTP to Varnish on the internal network. The visitor still experiences a fully encrypted HTTPS connection; the decryption simply happens at the layer ahead of Varnish.

How do I know if a page was served from the Varnish cache?

Request the page and inspect the response headers. Two X-Varnish IDs, an Age header greater than zero, and a custom X-Cache: HIT header (if the operator added one) all indicate a cache hit. A practical test is to request the same URL twice with curl -I and watch the Age value climb and the response speed up on the second request.

Does Varnish help SEO?

Indirectly, yes. By serving cached pages from memory, Varnish can substantially reduce load times and time to first byte, which supports better Core Web Vitals and a smoother crawl experience for search engines. Speed is one ranking and user-experience factor among many, so Varnish helps most when combined with good content, sound information architecture, and a healthy origin.

Want to identify Varnish and the rest of a site's delivery stack automatically? Run any URL through StackOptic at https://stackoptic.com.