Why Check for Cloudflare Can Show Different Results From Different Global Locations

Updated

Check for Cloudflare queries the domain from several global locations and reports what each one sees. Different results across those locations are normal, and they usually come from three things: DNS answers are cached and served per-region, Cloudflare's CDN/proxy and SSL behavior is evaluated at the edge closest to each query location, and CNAME-based setups can make a domain look like it is or isn't using Cloudflare depending on which record a resolver follows. Treat each line as an indicator from one vantage point, not as a single definitive verdict.

What the tool is actually doing

The page describes a scan that checks "global locations" and then reports, per check:

  • DNS — whether it found DNS entries for Cloudflare, with "Found in" and "Not found in" location lists.
  • CDN/Proxy — whether the domain "is using Cloudflare CDN/Proxy" or not.
  • SSL — whether the domain "is using Cloudflare SSL" or not.

Because each of those is answered from more than one location, the tool is effectively running the same question several times from different points on the network. When the answers disagree, the disagreement is the finding.

Why DNS results differ by location

DNS is distributed and cached, so two resolvers can legitimately return different answers for the same name at the same moment.

  • Propagation lag. If a domain was recently moved onto or off Cloudflare, some locations may still hold the old answer until their cached record expires.
  • Anycast and resolver choice. Cloudflare's own nameservers are anycast, so a query from one region may reach a different physical server than a query from another. The record returned should match, but the path and the resolver's cache state can differ.
  • Split or geo-steering DNS. A domain can return different records depending on where the query originates. If part of the world is pointed at Cloudflare and part isn't, the tool will correctly show Cloudflare found in some locations and not in others.

This is why the tool separates "Found in" from "Not found in" rather than collapsing everything into one yes/no.

Why CDN/Proxy and SSL results differ by location

The CDN/Proxy and SSL checks are about what the edge actually serves, and that is evaluated from wherever the check runs.

  • Proxy status is per-hostname, but the response is per-edge. A hostname that is proxied through Cloudflare should look proxied everywhere, but if a location is hitting an origin directly — through a stale DNS answer, a bypass record, or a different network path — that location can report "NOT using Cloudflare CDN/Proxy."
  • SSL is negotiated per connection. Whether Cloudflare SSL is detected depends on the certificate and handshake presented to that specific query location. A location that reaches the origin instead of Cloudflare sees the origin's certificate, so it reports "NOT using Cloudflare SSL" even though other locations see Cloudflare's.
  • Partial rollouts. If a domain is being migrated, some edges may already be behind Cloudflare while others are not yet, producing a genuine mix.

CNAME setups are the main source of ambiguous results

The tool explicitly flags that a domain "could be using a CNAME configuration." This is the case most likely to produce confusing or contradictory output.

With a CNAME, the name you check may not itself contain Cloudflare records — it points at another name that does. Depending on which record a given resolver follows and how deep it resolves the chain, one location can conclude the domain is on Cloudflare while another sees only the intermediate target and concludes it isn't. The result is not a bug in the tool; it reflects that "is this domain on Cloudflare?" has no single answer when the answer lives one or more CNAME hops away.

How to read a mixed result

What you see Most likely cause What to do
Cloudflare found in some locations, not others Propagation lag or geo-steering DNS Re-run later; if it persists, the domain genuinely differs by region
DNS found, but CDN/Proxy not detected A location is reaching the origin directly Check for bypass or grey-clouded records
CDN/Proxy detected, SSL not detected That location saw the origin certificate Verify the Cloudflare SSL mode and edge certificate
"Could be using a CNAME configuration" The record points at another name Trace the CNAME chain to its final target

The practical takeaway

A single location's answer tells you what that location sees. The value of Check for Cloudflare is the spread: if every location agrees, you have a strong indicator. If they disagree, you have learned something real about the domain's DNS, proxy, or certificate configuration — usually propagation, geo-steering, a direct-to-origin path, or a CNAME chain. Confirm anything that matters by resolving the DNS records yourself and inspecting the certificate the domain actually presents, rather than relying on any one line of the scan.