Find Companies Using Varnish Cache: API Guide (2026)

Varnish Cache is a reverse caching proxy that sits in front of a web application and serves repeat requests from memory. Nobody installs it by accident. A company running Varnish has decided its traffic is heavy enough, or its backend expensive enough, that a dedicated caching tier pays for itself—and then put an engineer on writing VCL configuration to make it work. That deliberateness is exactly what makes a list of companies using Varnish valuable as a technographic signal.

This guide covers how Varnish detection actually works at the HTTP header level, how to confirm it on a single domain in one command, how to separate self-hosted Varnish from CDN edge caching, and how to run a whole prospect list through the DetectZeStack API to produce a Varnish-confirmed lead list with versions attached.

Why Build a List of Companies Using Varnish

Technographic data—what a company runs—qualifies prospects in ways firmographic data cannot. A confirmed Varnish deployment tells you several things at once:

• They operate real infrastructure. Varnish is self-hosted software configured through its own domain-specific language (VCL). A company running it has systems engineers, not just a hosted page builder. If you sell observability, CDN migration, performance tooling, or infrastructure services, that is your qualifying bar cleared in a single header.
• They care about performance at scale. Varnish exists to absorb traffic before it reaches the application tier. Publishers, e-commerce platforms, and high-traffic content sites are the classic profile—organizations where page latency is tied directly to revenue.
• They may be CDN-migration prospects. A self-hosted Varnish tier with no CDN in front is a company doing at the origin what managed edge networks sell as a service. For CDN and edge-compute vendors, that is the sharpest prospect filter available from public data.
• Version data feeds security workflows. Varnish frequently advertises its version in the Via header, and the detection carries a CPE identifier (cpe:2.3:a:varnish-software:varnish_cache), so security teams can map detections against vulnerability databases. Our CPE guide for security teams covers that pipeline.

The workflow below is the same one we documented for finding companies using Nginx—only the filter changes.

How Varnish Is Detected (Via, X-Varnish, and Age)

Varnish detection is pure header analysis, and the signals are unusually distinctive. A default Varnish deployment stamps every response it handles:

You can check any single domain manually in one command. Here is a real response from Varnish Software’s own site:

$ curl -sI https://www.varnish-software.com | grep -iE "^(via|x-varnish|age)"
x-varnish: 9334891 7543568
age: 833
via: 1.1 varnish (Varnish/6.0)

Header Signals That Confirm Varnish vs Other Caches

Not every caching header means Varnish, so it is worth being precise about which signals confirm and which merely suggest:

• Via: 1.1 varnish is a confirmation. Varnish writes its own name into the standard Via proxy header. When the operator has not suppressed it, the version rides along in parentheses—(Varnish/6.0)—and detection tooling parses it into a structured version field.
• X-Varnish is a confirmation. The numeric transaction IDs are Varnish internals leaking into the response. One ID means the request went to the backend; two IDs mean it was served from cache, with the second ID pointing at the request that originally stored the object. The variants X-Varnish-Cache, X-Varnish-Age, X-Varnish-Action, and X-Varnish-Hostname come from custom VCL and are equally conclusive.
• Age alone is not. The Age header is standard HTTP caching semantics—CDNs, Nginx proxy caches, and Apache Traffic Server all set it. Treat it as supporting evidence that a cache is in the path, never as proof of which one.
• X-Cache: HIT alone is not. This convention is used by many CDNs and proxies. Without a Varnish-specific header next to it, it identifies nothing.

Why Some Varnish Deployments Hide Behind a CDN

The honest limitation of every external scanner: you see the outermost hop. When a site puts a CDN in front of its Varnish tier, what survives to the client depends on the CDN’s header pass-through behavior—some edges forward origin headers like Via and X-Varnish largely intact, others rewrite or strip them. A clean pass-through still detects; a strict edge masks the origin completely. That means a negative result behind a CDN is an unknown, not a confirmed miss.

Fastly deserves a special note here. Its edge platform was originally built on a modified Varnish core, but it is a managed service and detection reports it as Fastly in the CDN category—not as Varnish. That distinction is exactly what you want as a prospector: a Fastly detection means the company pays for a managed edge, while a bare Via: 1.1 varnish with no CDN in the scan means they run and operate the caching tier themselves. For the full picture of what the edge layer reveals, see our guide to detecting the CDN and hosting provider of any website.

Find Companies Using Varnish with the DetectZeStack API

Manual curl -sI checks work for one domain, not for a thousand. The DetectZeStack API runs the full detection pass—HTTP headers and body fingerprints, DNS records, and TLS certificates—in a single call and returns structured JSON you can filter in a script. Varnish comes back as a named technology in the Caching category, with the version parsed out of the Via header when the site exposes it.

Try It Free with the /demo Endpoint

You can test right now against the public demo endpoint, no API key required (it is IP-rate-limited, so use it for spot checks, not bulk scans). This is a real response:

$ curl -s "https://detectzestack.com/demo?url=varnish-software.com" \
  | jq '.technologies[] | select(.name == "Varnish")'
{
  "name": "Varnish",
  "version": "6.0",
  "categories": ["Caching"],
  "confidence": 100,
  "description": "Varnish is a reverse caching proxy.",
  "website": "https://www.varnish-cache.org",
  "icon": "Varnish.svg",
  "cpe": "cpe:2.3:a:varnish-software:varnish_cache:*:*:*:*:*:*:*:*",
  "source": "http"
}

The source: "http" field tells you this was a header-layer match, which is why confidence is 100. The version 6.0 was lifted straight out of Via: 1.1 varnish (Varnish/6.0), and the CPE identifier is ready for vulnerability tooling.

When all you need is a yes/no answer for one technology on one domain, the /check endpoint is the cheapest call:

$ curl -s "https://detectzestack.p.rapidapi.com/check?url=varnish-software.com&tech=varnish" \
  -H "X-RapidAPI-Key: YOUR_KEY" \
  -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"
{
  "domain": "varnish-software.com",
  "technology": "Varnish",
  "detected": true,
  "confidence": 100,
  "version": "6.0",
  "categories": ["Caching"],
  "response_ms": 2619,
  "cached": false
}

The tech parameter is case-insensitive, and the response echoes back the canonical name. A detected: false behind a strict CDN is an unknown, per the masking caveat above—keep those domains in a separate column rather than discarding them.

Full curl Walkthrough: From Domain List to Varnish-Confirmed Leads

For list building, POST /analyze/batch accepts up to 10 URLs per request and analyzes them concurrently. Each entry in the response carries either a full analysis result—the same shape as a single /analyze response—or an error string for domains that could not be fetched.

Here is a complete, copy-pasteable pipeline using nothing but bash, curl, and jq. It reads domains.txt (one domain per line), sends batches of 10, and appends every Varnish-confirmed domain to varnish_leads.csv with its detected version and total technology count:

#!/usr/bin/env bash
# find-varnish.sh — filter a domain list down to Varnish-confirmed leads
KEY="YOUR_KEY"
HOST="detectzestack.p.rapidapi.com"

echo "domain,varnish_version,tech_count" > varnish_leads.csv

# Process domains.txt in batches of 10 (the /analyze/batch maximum)
xargs -n 10 < domains.txt | while read -r batch; do
  urls=$(printf '%s\n' $batch | jq -R . | jq -s '{urls: .}')
  curl -s -X POST "https://$HOST/analyze/batch" \
    -H "X-RapidAPI-Key: $KEY" \
    -H "X-RapidAPI-Host: $HOST" \
    -H "Content-Type: application/json" \
    -d "$urls" |
  jq -r '.results[]
    | select(.result != null)
    | . as $r
    | $r.result.technologies[]
    | select(.name == "Varnish")
    | [$r.result.domain, .version, ($r.result.meta.tech_count | tostring)]
    | @csv' >> varnish_leads.csv
done

wc -l varnish_leads.csv

A 1,000-domain list becomes 100 batch calls. Domains that fail to resolve or time out appear in results[] with an error field instead of a result, and the select(.result != null) guard skips them cleanly. For throughput planning, retry queues, and a production-ready Python version of this scanner, see how to batch scan 1,000 websites.

Three fields matter most when reading the results:

• confidence — Varnish hits are header matches, so expect 100. Lower-confidence entries elsewhere in the scan come from DNS (80) and TLS (70) layers.
• version — present when the Via header carries it. An empty string means the operator suppressed the version banner; the detection is still valid, you just lose the security-workflow angle for that domain.
• meta.scan_depth — "full" means the HTTP fetch succeeded and header detection ran. "partial" means only DNS and TLS layers completed, so an absent Varnish entry tells you nothing—put that domain in a retry queue, not your rejects file.

Varnish vs CDN Edge Caching: What Detection Tells You About a Company

Because the same scan reports both the caching layer and the CDN layer, the combination is more informative than either signal alone:

These reads are heuristics, not rules, but they compound well with the rest of the stack in the same response. A Varnish detection next to a publisher-grade CMS suggests a media company; Varnish next to Magento suggests e-commerce performance work. The same layered analysis applies to the big managed edges—we cover Akamai’s header fingerprints in finding companies using Akamai.

Get Started with Your API Key

The free tier includes 100 requests per month with no credit card—enough to validate the pipeline on a sample of your prospect list before scaling up. Sign-up is instant through RapidAPI:

1. Get a key at rapidapi.com/mlugoapx/api/detectzestack.
2. Spot-check a domain you know: curl -s "https://detectzestack.p.rapidapi.com/check?url=yourdomain.com&tech=varnish" -H "X-RapidAPI-Key: YOUR_KEY" -H "X-RapidAPI-Host: detectzestack.p.rapidapi.com"
3. Run the batch script above against your first 100 domains.

Conclusion

Finding companies using Varnish comes down to two headers—Via: 1.1 varnish and X-Varnish—applied at scale with honest handling of CDN-masked origins. A single /check call answers the one-domain question; /analyze/batch turns a raw domain list into a Varnish-confirmed lead list with versions attached; and the CDN context in the same response tells you whether you are looking at a self-hosted caching tier or a managed edge, which is the difference between two very different kinds of prospect.

The same pipeline generalizes to any technology in the detection database: swap the jq filter and you are segmenting by web server, CMS, or payment stack instead of caching layer.