CDN Detector

What a CDN detector tells you about a site

A CDN detector reads the response headers and DNS of any public URL and names the content delivery network sitting in front of it. A CDN sits quietly between a site and its visitors. It caches static files close to whoever's loading the page. It terminates TLS out at the edge, runs firewall rules, soaks up DDoS floods long before they ever reach the origin. Visitors never see it. But it can't help leaving prints all over the response headers and the DNS, and once you know where to look, honestly, they're loud. A cf-ray header outs Cloudflare in one line. An x-served-by carrying a cache-bos string? That's Fastly. x-amz-cf-id means CloudFront, and a CNAME ending in .azureedge.net hands you Azure Front Door. This thing reads all of that at once and rolls it into a single answer, instead of making you squint at a header dump.

It works two angles at once. First the HTTP layer: my server fires a request at the URL and reads back every header that comes off it. Then the DNS layer. It resolves A, AAAA and CNAME records, then checks whether any of those hostnames land in ranges I know belong to a CDN. Back comes a list of confirmed providers, plus the exact evidence that flagged each one. I reach for it when I'm vetting a vendor, or tearing down a competitor's stack, or chasing some weird latency bug. Or, often, just because a colleague pasted a URL in chat and I got curious.

How CDN detection actually works

1. Normalise the URL. I strip the path, the query, the fragment. Keep the scheme and hostname. If what you pasted doesn't parse, you get a warning instead of garbage.
2. Run an HTTP request through a server-side endpoint and grab the whole header set. Especially the weird non-standard ones that actually do the talking: via, x-served-by, cf-ray, fly-request-id, x-amz-cf-id, x-vercel-id.
3. Resolve DNS through a second endpoint. The apex first, then the www subdomain when there is one, pulling A, AAAA and CNAME records.
4. Match against the catalogue. Every provider carries its own fingerprints: header tokens, response patterns, CNAME suffixes, the odd IP range. One strong hit and I call it confirmed. Weak hits only? It drops to suspected. Either way you see the exact line that set it off. I'm not asking you to trust me blind.
5. Summarise. The strongest provider becomes the headline. Everything else lands under "Evidence", so you can spot when a site's fronted by more than one CDN, or sitting on something like Vercel that wraps another network underneath.

Common use cases for a CDN detector

• Vendor due diligence. Before you sign with a SaaS supplier, check they're actually behind a real CDN. Not just one naked origin hung out on the open internet.
• Performance troubleshooting. A page crawls from one region but flies from another? A misconfigured CDN is the usual suspect. Find out which one's serving the site before you blow an afternoon filing a ticket with the wrong vendor.
• Competitive teardown. Engineering and marketing both get nosy about what a competitor runs on. This hands you the answer in seconds.
• Security posture audit. No CDN signal at all means a site's wide open to volumetric DDoS. That's exactly why this lives in my monthly health check.
• Migration verification. Just moved CDNs? Confirm the new one's genuinely taking traffic and the old DNS record didn't get left behind to rot.
• Bug bounty and red team recon. The CDN shapes most of your attack surface. Knowing the provider, its rules, the WAF parked in front of an asset, that's where any honest engagement starts.

Limitations and privacy notes

Be honest with yourself about what this is. Educated guessing, not gospel. Some providers strip their telltale headers on purpose. Some self-hosted edge nodes deliberately cosplay as Cloudflare or Akamai. And a fair few "CDNs" are really other CDNs wearing a borrowed logo, because plenty of enterprise products are built on Fastly or CloudFront underneath. So "no CDN detected" doesn't always mean there's nothing there. Sometimes it just means the headers got scrubbed and the DNS is hiding behind a private CNAME. The flip side, though, I'd trust pretty far: a strong header hit is solid. A cf-ray value, an x-amz-cf-id field, a Vercel x-vercel-id. The provider itself emits those for diagnostics. You don't fake one by accident.

One more thing worth knowing. My server issues the request, not your browser. So CORS stays out of it, and your IP never gets handed to the origin you're poking at. The URL? Dropped the moment the answer comes back. The fingerprint catalogue ships right there in the page, and I refresh it whenever a provider quietly changes its signatures.

Frequently asked questions

Why does the same site report different CDNs at different times?

Big sites split traffic up more than you'd think. Marketing pages on one CDN, the API on another, static assets somewhere else again. Or you caught them mid-migration, DNS still flip-flopping between old and new. Point the detector at the exact path you actually care about, run it again, then read the Evidence tab to see what hit.

Can a site hide its CDN from this detector?

Yes. A determined operator absolutely can. Strip the diagnostic headers, hide behind a private CNAME, front the whole thing with their own subdomain, and there's barely anything left for me to grab. At that point the detector falls back to DNS clues, and those can be neutralised too. Someone who genuinely does not want you knowing what they run on usually wins that fight.

Is "no CDN detected" the same as "no CDN"?

Not quite. Plenty of small sites genuinely run bare, no CDN anywhere. But a big enterprise site can be parked behind one that has been made deliberately invisible. So when the target clearly is not small, read "no signal" as inconclusive. Not as proof there is nothing there.

Does the tool detect WAFs and security products?

Up to a point. When the WAF rides along with a major CDN (Cloudflare, Akamai, Fastly, AWS WAF), spotting the CDN spots the WAF for free. A standalone WAF with no CDN behind it, or some on-prem filter? Not in the catalogue yet. It is on my list. Just not in the tool today.

Is the URL I inspect logged?

No. The URL only travels as far as the site's public REST endpoints, purely to fetch the headers and DNS for that one lookup. I do not log it. The response is gone the second your page session ends. Nothing about your search sticks around afterward.