How to check if a website uses Cloudflare

Method 1: check the response headers

Every response proxied by Cloudflare carries a cf-ray header, a request ID followed by a code for the Cloudflare data center that handled it, such as -FRA for Frankfurt. Most also show server: cloudflare, and cached content usually adds cf-cache-status with a value such as HIT, MISS or DYNAMIC.

To see the headers, open the browser's developer tools, go to the Network tab, reload, and click the first request. From a terminal, curl -I https://example.com prints them. The HTTP header checker lists every header with an explanation of what it means, without any setup.

Some sites also set Cloudflare cookies, such as __cf_bm from its bot protection features. Their presence supports the conclusion, but their absence proves nothing, because many proxied sites never set them.

Method 2: the /cdn-cgi/trace page

Cloudflare reserves the /cdn-cgi/ path on proxied sites for its own features. Opening https://example.com/cdn-cgi/trace on a site behind Cloudflare usually returns a short plain-text page with lines such as h= (the hostname), colo= (the data center code), ip= (your own address as Cloudflare sees it) and http= (the protocol version).

If the page loads with those fields, the hostname is proxied through Cloudflare. If it returns the site's normal 404 page, it almost certainly is not. Cloudflare's edge answers this path itself, so it responds even when the origin server is down. Check each hostname separately, because a domain can proxy www through Cloudflare while other subdomains go direct.

Method 3: the IP address and its network

Look up the IP address the domain resolves to. Cloudflare publishes its IP ranges at cloudflare.com/ips, and its network is registered as AS13335. If the address falls inside those ranges, traffic to that hostname goes through Cloudflare. The list covers both IPv4 and IPv6, so if the site also has an AAAA record, check that address too; a proxied hostname returns Cloudflare addresses for both.

This method has one blind spot in the other direction: an address outside Cloudflare's ranges proves the hostname is not proxied by Cloudflare right now, but the domain may still use Cloudflare for DNS.

Method 4: the nameservers

Domains using Cloudflare DNS have nameservers ending in ns.cloudflare.com, usually a pair with first names, such as ada.ns.cloudflare.com. That shows Cloudflare answers DNS queries for the domain. It does not, on its own, prove traffic goes through Cloudflare: each DNS record can be proxied (the orange cloud) or DNS only (the grey cloud), and DNS-only records point visitors straight at the server.

It works the other way too. Cloudflare's partial (CNAME) setup, available on Business and Enterprise plans, and Cloudflare for SaaS let a site route traffic through Cloudflare while keeping DNS elsewhere. In those cases the headers and IP address reveal Cloudflare even though the nameservers do not.

From a terminal, three commands cover every method. curl -sI https://example.com prints the response headers, where cf-ray and server: cloudflare confirm the proxy. dig +short example.com prints the addresses the name resolves to, for comparison with Cloudflare's published ranges. dig +short NS example.com shows whether the nameservers are Cloudflare's. Run them for each hostname that matters, at least the bare domain, www and any subdomain visitors use regularly, because the answer can differ between them.

What Cloudflare hides, and what it doesn't

Cloudflare's proxy replaces the origin server's IP address with its own. A plain IP lookup on a proxied site finds Cloudflare, not the hosting company, which is one reason site owners use it.

It does not hide everything. Headers that the origin server adds, such as fingerprint headers stamped by many managed hosts, usually pass through unchanged. The mail records (MX) often point at a server unrelated to Cloudflare, and sometimes reveal more about the setup. The hosting checker combines headers, the network behind the IP address and the nameservers, and reports the CDN, the DNS provider and the likely host separately, with the evidence for each.

Why it matters when troubleshooting

Knowing a site sits behind Cloudflare changes how you read its errors. Codes 520 to 526 come from Cloudflare and describe its connection to the origin server: 521 means the origin refused the connection, 522 that it timed out, 524 that it took too long to respond. Those point at the origin, even though the error page is Cloudflare's.

It also changes what the origin server sees. Requests arrive from Cloudflare's IP addresses, not the visitors', so access logs, rate limits and firewall rules on the origin see Cloudflare unless the server is configured to read the visitor's address from the CF-Connecting-IP header. An origin firewall that blocks Cloudflare's ranges produces errors for every visitor. And cached content means a change on the origin may not appear until the Cloudflare cache is purged.

Edge cases worth knowing

A few situations produce Cloudflare signals that mean something slightly different:

• Sites hosted on Cloudflare Pages or Workers return the same Cloudflare headers; in that case Cloudflare is the host as well as the CDN.
• A "Just a moment..." or verification page before the site loads is a Cloudflare challenge, which confirms the site is proxied.
• Some hosting platforms put Cloudflare in front of customer sites as part of their service, so the site owner may not have a Cloudflare account at all.
• Cloudflare Email Routing uses MX records on mx.cloudflare.net, which shows Cloudflare handles incoming mail, not web traffic.
• Only some hostnames may be proxied. Checking www, the bare domain and important subdomains separately avoids a wrong conclusion.