How to Detect Cloudflare and Other CDNs on a Website
A CDN or reverse proxy changes what a visitor sees of the server behind it. Knowing which edge network a site uses tells you about performance, security posture and what you can and cannot learn about the origin. This guide shows the checks and their limits.
CDN, reverse proxy and what they hide
A content delivery network keeps copies of static files near visitors. A reverse proxy goes further and sits in front of the origin server for every request. Cloudflare, Fastly, Akamai, Amazon CloudFront and others offer both. When a site uses a proxy mode, the visitor's browser talks to the edge, and the origin's address and software are not directly visible.
This is good for owners and a nuisance for researchers: a header that says Server: cloudflare describes the edge, not the application. Detecting the CDN is therefore its own question, separate from detecting the CMS, and the two answers can differ.
Check 1: response headers
Fetch headers with curl -sI https://example.com or read them in DevTools. Cloudflare's documentation lists the headers it adds. The two most common signs are:
cf-ray: a request identifier ending in a three-letter data centre code, for instance a value ending in-SJC. Cloudflare documents it as encoding information about the data centre and the visitor's request. Its presence is a strong sign that the response passed through Cloudflare.server: cloudflare: the edge server's name. Strong, although a site could in principle forge it.
Other networks have their own markers. Fastly responses commonly include x-served-by and x-cache values naming cache nodes; CloudFront adds x-amz-cf-id and x-amz-cf-pop and usually reports via with a CloudFront identifier; Akamai deployments often show x-akamai-* headers when debug pragma headers are enabled, and otherwise rely on server: AkamaiGHost for some products. Vercel adds x-vercel-id and Netlify adds x-nf-request-id. Header details evolve; check the provider documentation for current values.
Check 2: DNS
The name server records often tell the story. Sites that use Cloudflare's DNS have name servers under cloudflare.com with a pair of first names such as two person names in the hostname. Note the difference:
- Cloudflare DNS only. The domain's name servers are Cloudflare's, but records may be "DNS only" and point straight to the origin, so no proxying happens.
- Cloudflare proxy. The A record resolves to a Cloudflare address range, and traffic passes through the edge.
Both show Cloudflare name servers. Only the second gives you the headers above. The guide to DNS name servers and providers explains how to read these records, and the domain checker shows a domain's name servers so that you can see the DNS provider.
A CNAME to a vendor hostname is a common pattern for other services: a CNAME to a CloudFront distribution hostname, a Fastly service host or a platform hosting address indicates that CDN or host directly.
Check 3: IP address ranges
Large providers publish their address ranges. Cloudflare publishes its IPv4 and IPv6 ranges at cloudflare.com/ips. If a domain's A record falls within a published range, traffic goes to that network. AWS likewise publishes ip-ranges.json, which identifies CloudFront and other service addresses. This check works even when headers are stripped and requires no request to the site, but it only tells you the network, not whether the site is the customer's application or a shared edge.
Check 4: cookies and challenge pages
Some edge products set cookies. Cloudflare's bot management and some security features set cookies whose names start with __cf or cf_, such as __cf_bm. A name alone is informative and, for privacy, it is the only part worth reading: the value is an opaque token and not relevant. TLDlive Lens matches cookie names only, never values. A "Checking your browser" or "Just a moment" interstitial is a further sign of Cloudflare's challenge page.
Check 5: the /cdn-cgi/ path
Requests to paths beginning with /cdn-cgi/ are handled by Cloudflare at the edge, such as /cdn-cgi/trace, which prints diagnostic lines about the connection on sites that serve it. Because these are not application paths, a response there shows the edge is Cloudflare. Owners can disable or block the trace page, so a failure is inconclusive.
Reading the combination
| Evidence | Conclusion |
|---|---|
| cf-ray header and Cloudflare IP range | Proxied through Cloudflare |
| Cloudflare name servers, A record to a non-Cloudflare address | Cloudflare DNS only; origin is exposed |
| Fastly or CloudFront headers, CNAME to the vendor | That CDN, possibly with another in front |
| No CDN headers, address in a single hosting company's range | Likely served directly from a host |
| Two vendors' headers at once | Multi-CDN or a CDN in front of a hosting platform with its own edge |
Layered setups are common: a site on a hosted platform may sit behind the platform's own CDN, itself fronted by Cloudflare. Report the outermost layer you can prove and note any inner ones.
Why you usually cannot find the origin
Searching for the origin address behind a proxy is a security topic with a dual use. Owners are told to restrict origin access so that only the CDN can reach it, which defeats such searches. For research and domain evaluation you rarely need the origin; the technologies visible in the page itself are enough. This guide does not describe ways to bypass a CDN's protection. If you are the owner, check that your origin only accepts connections from your provider.
Why CDN statistics need care
Because a large share of sites use Cloudflare's free plan, CDN adoption charts are dominated by a handful of names, and many sites use two layers. TLDlive's technology analytics, on /technologies, count a domain once per technology, so a site with several layers appears in each CDN category. For a view of the extensions that use proxied hosting most, compare the CDN category across TLDs rather than reading absolute percentages.
TLDlive Lens shows the detected CDN in the popup next to the DNS data, so you can see edge, framework and CMS in one place. How the matching works without collecting personal information is explained in technology fingerprinting and privacy.
Sources
- Cloudflare Docs, HTTP headers (CF-Ray): developers.cloudflare.com
- Cloudflare IP ranges: cloudflare.com/ips
- AWS, IP address ranges: docs.aws.amazon.com
- Fastly documentation, debugging headers: fastly.com/documentation
Frequently asked questions
How do I know if a website uses Cloudflare?
Look for a cf-ray response header and server: cloudflare, or check whether the name servers and A record belong to Cloudflare. The first two prove proxying; Cloudflare name servers alone only prove DNS hosting.
Does using Cloudflare change SEO?
Using a CDN is neutral for ranking by itself. Faster delivery can help user experience, while misconfigured challenge pages or blocked crawlers can hurt. Search engines can crawl Cloudflare-proxied sites normally.
Can a site use a CDN without any of these headers?
Yes. Owners can remove or rewrite headers, and some CDNs add none by default. DNS and IP-range checks still usually reveal the network.
Is knowing the CDN useful for domain buyers?
It shows how professionally the previous owner ran the site and whether DNS depends on a provider account you would need to take over. It is one input among several in an expired domain review.