How to check what CDN a website uses

Signal 1: response headers

Open the browser's developer tools, reload the page and inspect the first request, or use the HTTP header checker to list every header with an explanation. Typical signatures:

• Cloudflare: server: cloudflare, a cf-ray header, and often cf-cache-status.
• Amazon CloudFront: x-amz-cf-id and x-amz-cf-pop headers, a via header ending in (CloudFront), and x-cache values such as "Hit from cloudfront".
• Fastly: x-served-by values starting with cache-, x-cache and x-cache-hits, and often via: 1.1 varnish.
• Akamai: often few obvious headers on normal responses; server: AkamaiGHost appears on some responses, and the DNS CNAME is usually the clearer signal.
• Bunny CDN: server values starting with BunnyCDN, plus cdn-pullzone and cdn-cache headers.
• Google Cloud CDN and Google's load balancers: via: 1.1 google.
• Azure Front Door: an x-azure-ref header.
• Vercel and Netlify, which serve sites from their own edge networks: x-vercel-id and x-vercel-cache, or server: Netlify and x-nf-request-id.
• Sucuri's firewall and CDN: x-sucuri-id and x-sucuri-cache.

Signal 2: the CNAME record

Most CDN setups, apart from Cloudflare's full DNS setup, point the site's hostname at the CDN with a CNAME record. Look up the hostname with a DNS tool, or run dig www.example.com CNAME, and read the target. Chains of several CNAMEs are common, for example a name at the site's own domain pointing to a provider name that points to another; the last names before the IP address usually identify the CDN:

• cloudfront.net: Amazon CloudFront.
• edgekey.net, edgesuite.net or akamaiedge.net: Akamai.
• fastly.net or a name containing fastly: Fastly.
• b-cdn.net: Bunny CDN.
• azurefd.net: Azure Front Door.
• vercel-dns.com, or a netlify.app address: Vercel or Netlify.
• A cdn.cloudflare.net target: Cloudflare in a partial (CNAME) setup.

Signal 3: the IP address network

Every IP address belongs to a network registered to a company. Look up the address the hostname resolves to, and check which network owns it. A Cloudflare, Fastly or Akamai network answers the question directly.

This signal is weaker for CDNs run by large cloud providers. An Amazon network address could be CloudFront or an ordinary server on AWS, so combine it with the headers. Large CDNs also route visitors to nearby locations, through anycast addresses or location-aware DNS, so the address you see may differ from the one a visitor on another continent gets; the network that owns it stays the same. The DNS propagation check shows the A, AAAA and CNAME records from several public resolvers, which also reveals when a site serves different CDNs to different regions.

Is the CDN actually caching the page?

Finding a CDN in front of a site does not mean it caches the HTML. Many CDNs cache images, scripts and stylesheets by default but pass HTML requests through to the origin unless configured otherwise. Cloudflare, for example, marks uncached HTML with cf-cache-status: DYNAMIC.

Cache headers tell you what happened to each response. HIT means the CDN served a stored copy; MISS means it fetched from the origin, often storing it for next time. An age header shows how many seconds the cached copy has existed. If the HTML always shows MISS or DYNAMIC, the page's speed still depends on the origin server, which the TTFB checker measures.

The origin's own headers can also prevent caching. A Cache-Control value of private or no-store, or a Set-Cookie header on every page, tells most CDNs not to store the response, whatever their settings say.

Why it is useful to know

For site owners and developers, the CDN determines where to look when something goes wrong. Each CDN has its own error codes and error pages, its own cache to purge after a change, and its own logs. A stale page after an update, a strange error code or a request blocked by a firewall rule usually traces back to the CDN layer, and knowing which provider runs it saves a round of guessing.

For anyone researching a site, the CDN shows how its traffic is delivered and protected. It does not, on its own, reveal where the site is hosted, because the CDN sits in front of the origin server. Finding the host takes the other signals the hosting checker combines.

When the answer is complicated

Some setups do not fit a single label:

• Stacked CDNs. A site can put one CDN in front of another, such as Cloudflare in front of a hosting platform's own CDN. Headers from both may appear.
• Host-integrated CDNs. Many hosting platforms include a CDN, so the CDN headers may reflect the host's choice rather than the site owner's.
• Stripped headers. Some sites remove identifying headers deliberately; then the CNAME and the IP network carry the answer.
• Generic headers. x-cache is used by several CDNs and by caching servers such as Varnish on an ordinary host, a via header only shows that some proxy handled the response, and an age header means some cache served it, not which one. Treat them as hints and look for a provider-specific header or a CNAME that names the provider before concluding.
• Different CDNs for different content. Images and scripts are often served from a separate hostname, such as a static or media subdomain, on a different CDN from the HTML.

A quick checklist

Work through the signals in order and stop when they agree:

1. 1Fetch the page's response headers and look for the signatures above.
2. 2Look up the hostname's CNAME record and read the target domain.
3. 3Check which network owns the resolved IP address.
4. 4Repeat for the asset hostnames that serve images and scripts.
5. 5Check the cache status headers to see whether the HTML itself is cached.