How to Tell If a Website Uses Cloudflare (or Another CDN)

Most production websites today sit behind a content delivery network, and Cloudflare is so common that it is a sensible first guess for any site. Detecting the CDN is quick — it announces itself in the response headers and the DNS — and it is worth knowing, because the CDN shapes a site's performance and security and explains why an IP lookup often returns the network rather than the real server. This guide shows how to tell if a site uses Cloudflare or another CDN, and what that tells you.

It is a focused companion to how to find out where a website is hosted and how to find a website's IP address.

What a CDN is and why sites use one

A content delivery network is a globally distributed set of edge servers that sit between visitors and a site's origin server. It caches content close to users for speed, absorbs and filters traffic for security (including DDoS protection and a web application firewall), and offloads work from the origin. Because of these benefits, a large share of the web now runs behind a CDN, and detecting which one is in use is a core part of understanding a site's infrastructure. The trade-off, from a detection standpoint, is that the CDN becomes the public face of the site — so what you can see is the edge, not the origin.

Method 1: Read the response headers (fastest)

The quickest and most reliable check is the HTTP response headers. Open DevTools, go to the Network tab, reload, click the main document request, and read the response headers — or run curl -sI https://example.com from a terminal. Each CDN leaves distinctive markers:

Header signature	CDN
cf-ray, server: cloudflare, cf-cache-status	Cloudflare
x-amz-cf-id, via: ... cloudfront, x-cache: Hit from cloudfront	Amazon CloudFront
x-served-by, x-cache, via: ... varnish	Fastly
x-akamai-..., server: AkamaiGHost	Akamai
server: Vercel, x-vercel-id	Vercel
server: BunnyCDN	Bunny

A single matching header usually settles which CDN is in front. The cf-ray header in particular is Cloudflare's signature and is present on essentially every Cloudflare-proxied response.

Method 2: Check the DNS

DNS is the other strong signal. A domain proxied through Cloudflare typically uses Cloudflare nameservers (visible in its NS records) and resolves to an IP in Cloudflare's published ranges. For other CDNs, a CNAME pointing at the provider's domain is the giveaway — for example a CNAME to a CloudFront or Fastly hostname. So a quick dig NS example.com and a WHOIS lookup on the resolved IP often confirm the CDN independently of the headers, which is useful when headers have been customised.

Method 3: Confirm via the IP owner

Following from the DNS, a WHOIS or RDAP lookup on the site's resolved IP returns the owning organisation — and if that organisation is Cloudflare, Fastly, Amazon or Akamai, you have your answer. This is the same step covered in how to find a website's IP address: the IP you get for a CDN-fronted site belongs to the CDN, which both confirms the CDN and explains why you cannot see the origin from the IP alone.

Cloudflare is the common case

It is worth setting expectations: according to W3Techs, Cloudflare is the most widely used CDN and reverse proxy on the web, by a wide margin. So for a randomly chosen site that uses any CDN, Cloudflare is the most likely answer, and cf-ray is the header you will see most often. That does not mean you should assume it — the checks above take seconds — but it does mean Cloudflare is the sensible first hypothesis, with the other major CDNs (CloudFront, Fastly, Akamai, Vercel for modern apps) accounting for much of the rest.

What detecting the CDN tells you — and doesn't

Detecting the CDN tells you how a site is delivered: it is cached and protected at the edge, served from locations near users, and shielded behind the CDN's network. It explains performance characteristics and why the site is resilient. What it does not tell you is the origin host — the CDN deliberately hides the real server's IP, so detecting Cloudflare reveals the edge while leaving the origin private by design. This is the single most important nuance: "the site uses Cloudflare" is a complete and honest answer about the edge, but it is not the same as "the site is hosted on Cloudflare's servers" in the origin sense. For the origin, you are back to the techniques (and limits) in the hosting guide.

A worked example

You want to know the CDN for a site at app.example. You run curl -sI https://app.example and immediately see server: cloudflare and a cf-ray header — Cloudflare, confirmed in one command. To double-check, you run dig NS app.example and the nameservers end in cloudflare.com, and a WHOIS on the resolved IP returns Cloudflare's organisation. Three independent signals all point to Cloudflare, so you can state it with full confidence. You also note a cf-cache-status: HIT on a static asset, telling you that asset was served from Cloudflare's edge cache rather than the origin. In under a minute you know the CDN, that it is actively caching, and — implicitly — that the origin is hidden behind it. That is a complete edge-layer read from a single terminal command plus two quick confirmations.

Why it matters for performance and security

Beyond curiosity, the CDN is a meaningful fact. For performance, a CDN with good cache hit rates is a major speed advantage, and its presence (or absence) is part of any performance assessment — see Core Web Vitals explained. For security, a CDN with a WAF changes a site's threat profile and is relevant to a security review. For troubleshooting, knowing traffic flows through a CDN tells you where to look when something breaks — an edge rule, a cache problem, or the origin. And for competitive research, the CDN choice is part of a rival's infrastructure story. It is a small fact that informs several larger judgements.

What else the CDN reveals about a site

The CDN is a surprisingly informative single fact. A site on an enterprise CDN with a configured web application firewall signals a security-conscious, well-resourced operation; a site on a free Cloudflare plan suggests a leaner setup. The CDN choice also hints at the rest of the stack: Vercel's edge usually means a Next.js front end, Netlify points to a JAMstack build, and Shopify stores ride Shopify's own CDN. Even the presence of a serious CDN tells you the operator cares about performance and resilience, while its absence on a high-traffic site is itself notable. So reading the CDN is rarely just trivia — it is a doorway into how seriously a site is engineered and, often, what framework sits behind it.

When CDN detection is ambiguous

Detection is usually clean, but a few situations muddy it. Some sites use two CDNs — one for the main site and another for media or a specific subdomain — so the CDN serving the homepage may not serve everything. Multi-CDN setups deliberately split traffic across providers for resilience, so repeated checks can show different answers. And a site may use a CDN purely for DNS or DDoS protection without proxying all content, which weakens the header signals. When the headers and DNS seem to disagree, check more than one resource (the document, an image, an API call) and you will usually see the full, layered picture rather than a single confusing snapshot. As ever, more than one signal beats relying on the homepage alone.

How accurate is CDN detection?

Very accurate for the presence of a CDN and which one — the headers and DNS are hard to fake while still using the service, so a cf-ray plus a Cloudflare-range IP is conclusive. The accuracy limit is the origin: detecting the CDN is reliable, but seeing through it to the real host is usually impossible by design. So treat "which CDN?" as a question you can answer confidently, and "what is the origin behind it?" as one that is often deliberately unanswerable — and remember that a confident, correct "it uses Cloudflare" is a genuinely useful result in its own right, not a consolation prize.

The workflow

1. Read the response headers (curl -sI or DevTools) for CDN signatures like cf-ray.
2. Check DNS — nameservers and CNAMEs pointing at the CDN.
3. WHOIS the resolved IP to confirm the owning network.
4. Note the cache-status header to see the edge in action.
5. Treat the origin as hidden when a proxy CDN is in front.

Go deeper

• The infrastructure trace: how to find out where a website is hosted.
• Find the IP first: how to find a website's IP address.
• Why CDNs matter for speed: Core Web Vitals explained.

Want the CDN, host and full stack identified automatically? Analyse any site with StackOptic — free, no sign-up.