Cloudflare Checker: Separate Detection from Account Protection

A public Cloudflare check can inspect signals in a response suggesting that Cloudflare serves a URL. It cannot inspect private firewall rules, certify the site's security or calculate a verified percentage of attacks prevented.

Check what the response actually supports

Inspect the final URL, response headers and relevant delivery signals. Record the requested host and time because configurations can vary by route and hostname. A response associated with Cloudflare does not prove that every DNS record is proxied or that a particular security feature is enabled. Missing public evidence can also be inconclusive.

Distinguish three separate questions

A header score addresses only part of the first or configuration question. It does not answer all three.

Worked example: the homepage and API behave differently

Suppose the homepage shows edge-delivery signals while an API hostname does not. Check the exact DNS records and proxy status with an authorized account, then inspect the respective routes. Do not claim a site-wide bypass solely from one public request. Likewise, do not enable broad blocking without testing legitimate API clients. This is an illustrative investigation.

Review protection through authorized records

Use account analytics and event records to understand actions taken, the relevant period and applicable plan limits. Edge requests are not a direct count of human visitors. A blocked or challenged request is not automatically a confirmed prevented loss, and allowed traffic is not automatically safe.

Run Cloudflare Checker for public signals. Treat its findings as a starting point for configuration review and avoid publishing account tokens or private event details.

See Cloudflare's official proxied DNS records documentation for the difference between proxied and DNS-only records.