CDN Detection: Spot Cloudflare, CloudFront, Fastly or Akamai

Almost every site you visit today is served through a content delivery network, and figuring out which one is a recurring task for anyone debugging performance, planning a migration, or doing competitive research. The HTTP Archive's Web Almanac 2025 chapter on CDNs shows CDN adoption now spans a large majority of measured sites, with a handful of providers dominating the field. The good news is that most CDNs leave fingerprints — in DNS records, in HTTP response headers, and even in the way they negotiate TLS. This guide walks through the signals you can actually rely on, where they break down, and how to read a CDN checker's output without over-interpreting it.

What a CDN actually does

A content delivery network is a distributed set of edge servers that sit between a visitor and the website's origin server. Instead of every request travelling to a single origin, the CDN serves cached copies from a location close to the user, terminates TLS at the edge, and often filters traffic through a web application firewall on the way in. Cloudflare's own primer, What is a CDN?, frames it as reducing latency by shortening the physical distance content travels — and that edge-termination model is precisely why CDNs are detectable. Because the edge node, not the origin, answers your request, the response carries the CDN's own routing, caching and diagnostic metadata.

That has two consequences for detection. First, the IP address you connect to belongs to the CDN, not the origin — so a plain reverse-IP lookup tells you about the CDN, not who really hosts the site. Second, the edge inserts or rewrites headers, and those headers are where the most reliable fingerprints live.

DNS signals: CNAMEs, Anycast IPs and nameservers

DNS is the first place to look, because pointing a site at a CDN almost always means changing where the domain resolves.

CNAME records. The clearest tell is a CNAME (or, for apex domains, a flattened/ALIAS record) that points the hostname at a provider-controlled domain. d111111abcdef8.cloudfront.net is unmistakably Amazon CloudFront; a target ending in .fastly.net or .global.fastly.net is Fastly; .akamaiedge.net, .akamai.net or .edgekey.net is Akamai. Cloudflare is the exception here — it usually does not expose a CNAME, because it works by hijacking the domain's authoritative DNS instead (see below).

Nameserver patterns. Run a quick NS lookup. If the authoritative nameservers are something like someone.ns.cloudflare.com, the domain is managed through Cloudflare's full proxy mode. Akamai's managed DNS shows up as nameservers under akam.net. Nameserver delegation is a strong signal because it is hard to fake and trivial to read.

Anycast IPs. CDNs announce the same IP prefix from many locations (Anycast), so the address you resolve maps to a published provider range rather than a single data centre. Cloudflare's well-known ranges (such as 104.16.0.0/13 and 172.64.0.0/13) and CloudFront's published egress ranges are easy to check against. An IP that falls inside a known CDN block is good corroboration — but treat it as supporting evidence, not proof, because providers add and rotate ranges.

HTTP header signals: the most reliable layer

Once you have a connection, the response headers are the richest source of truth. The general-purpose ones are documented on MDN's HTTP headers reference; below are the provider-specific ones that matter for fingerprinting.

The generic caching and proxy headers tell you a CDN is present, even before you know which:

1. via — names an intermediary proxy; CloudFront stamps something like 1.1 <hash>.cloudfront.net (CloudFront).
2. x-cache — reports a cache Hit/Miss; used by both CloudFront and Fastly (often as HIT, MISS chains for Fastly).
3. age — present whenever a shared cache is serving the response, which most CDN edges do.
4. server-timing — increasingly used by edges to expose internal timing; Cloudflare emits cf metrics here on some plans.

The provider-specific headers are what let you name the CDN with confidence:

A couple of caveats on headers. server: cloudflare and x-amz-cf-id are very hard to spoof meaningfully because they are added by the edge, so they are among the most trustworthy signals. Conversely, a generic x-cache or via on its own only tells you some cache is in the path — it could be a CDN, a reverse proxy, or even a corporate cache — which is exactly the kind of ambiguity covered in why a hosting checker can be wrong with CDNs and reverse proxies.

Why some CDNs are intentionally hard to fingerprint

Not every provider wants to be identified. Akamai, in particular, defaults to stripping most of its diagnostic headers in production; the verbose x-akamai-* and x-check-cacheable headers often only appear when a debug header (such as Pragma: akamai-x-cache-on) is sent, and even then many configurations refuse to honour it. That is a deliberate posture: exposing edge internals is a small attack-surface and information-leak risk, so enterprise CDNs lean toward silence.

There are other reasons fingerprints disappear. Customers can rename or suppress headers in their edge configuration. Multi-CDN setups route the same hostname through different providers depending on the visitor, so two checks minutes apart can show two different CDNs. And a site can sit behind a CDN-on-a-CDN arrangement — for example, an origin already on Fastly that someone fronts with Cloudflare — leaving you to detect only the outermost layer. The honest takeaway is that a clean fingerprint is a positive result, but its absence is not proof a CDN isn't there.

How HTTP/2, HTTP/3 and TLS hint at edge delivery

Beyond headers, the connection itself carries weaker but useful signals.

Protocol support. CDNs are typically early and aggressive adopters of new transport protocols. HTTP/2 is nearly universal among them, and broad HTTP/3 (QUIC) support — advertised via an alt-svc: h3=... header — strongly suggests a modern edge rather than a bare origin server, since most origin stacks still don't speak HTTP/3 directly. The Web Almanac data consistently shows HTTP/3 adoption concentrated behind the large CDNs.

TLS fingerprinting. The TLS handshake leaks identity too. The certificate issuer is a hint — Cloudflare-proxied sites very often present certificates issued through Google Trust Services or Let's Encrypt provisioned by Cloudflare, and the certificate's SAN list or the absence of the origin's own CA can be telling. More advanced tooling uses JA3/JA3S server fingerprints (a hash of TLS handshake parameters) to cluster servers by stack, and CDN edges tend to share a recognisable handshake profile. These signals are circumstantial — they narrow the field rather than name a provider — so treat them as tie-breakers on top of DNS and header evidence.

Practical output examples

Here is what the signals look like in practice. A response fronted by Cloudflare:

A response from CloudFront:

A response from Fastly:

And an Akamai edge that hasn't stripped everything:

Read these together, not in isolation. Cross-referencing a CloudFront CNAME with x-amz-cf-pop, or a Cloudflare nameserver with a cf-ray, turns a guess into a confident identification — and immediately separates the CDN layer from the question of who actually hosts the website.

Summary

1. DNS gives you the first signal: provider CNAMEs (*.cloudfront.net, *.fastly.net, *.akamaiedge.net) and Cloudflare/Akamai nameserver delegation.
2. HTTP headers are the most reliable layer: cf-cache-status/cf-ray for Cloudflare, x-amz-cf-id/x-amz-cf-pop for CloudFront, x-served-by for Fastly, server: AkamaiGHost for Akamai.
3. Generic via, x-cache and age confirm a cache exists but don't name the provider — beware false positives.
4. TLS and HTTP/3 (alt-svc: h3) support are circumstantial corroboration, not proof.
5. Some CDNs, Akamai especially, strip their headers on purpose; multi-CDN and stacked-CDN setups can hide or change the answer between checks.

As edges keep absorbing more of the stack — compute, storage, even databases at the edge — the line between "CDN" and "host" will keep blurring, and single-signal detection will get less reliable. The durable approach is the one above: combine DNS, headers and TLS, and weigh them together rather than trusting any one clue.

Want to skip the manual lookups? Run a domain through our checker and it cross-references DNS, CDN headers and TLS in one pass, then tells you both the CDN and the underlying host.