Cloudflare

A `cf-ray` header — weight 90. Cloudflare's documentation describes it as a hashed value identifying the data center that processed the request, ending in a three-letter location code.

A `Server: cloudflare` header — weight 90.

Nameservers under Cloudflare are read separately and reported as Cloudflare DNS.

DNS on Cloudflare and proxying through Cloudflare are different setups, and the diagnostic check reports them as separate facets.

`HIT` means the response came from Cloudflare's cache; `MISS` means it was eligible for cache and fetched from the origin because it was not there yet.

`BYPASS` means the asset was eligible but the origin response was not cacheable — for example `no-store` in a CDN cache header, or, in some configurations, a `Set-Cookie` header.

`DYNAMIC` means the asset was not eligible for cache at all: by default HTML and JSON are not among the file extensions Cloudflare caches, unless a rule says otherwise.

So `DYNAMIC` on HTML pages is the default, not a fault, while `BYPASS` everywhere usually points to cache directives or cookies the origin sends with every response.

A proxied record is answered with Cloudflare's shared anycast addresses, so web traffic goes through Cloudflare.

A DNS-only record is answered with the origin's actual address, which, in Cloudflare's own words, exposes the origin IP to anyone who queries it.

Only A, AAAA and CNAME records can be proxied; MX and TXT records are always DNS-only.

One DNS-only name pointing at the same server as the proxied site is enough for someone to reach the origin directly and bypass the protection.

In Flexible encryption mode, Cloudflare's documentation says visitors connect to Cloudflare over HTTPS while all connections between Cloudflare and the origin use plain HTTP.

The visitor still sees a valid certificate and a padlock, so nothing on the public side reveals it.

In Full mode Cloudflare matches the visitor's protocol when connecting to the origin and does not validate the origin's certificate; Full (strict) adds that validation.

This is the one Cloudflare setting that matters most and that no external audit can observe: it must be checked in the dashboard.

`infrastructure.cloudflare` reports each facet separately: DNS, proxy, cache status, and Workers and WAF only where signals exist.

`infrastructure.cdn` and `infrastructure.cache_state` report the edge and whether a response really came from cache.

`performance.cdn_cache_status` reports cache status across the pages crawled.

`infrastructure.origin_exposure` and `infrastructure.ip_dns_consistency` report signs that the origin is reachable around the edge.

`infrastructure.waf` and `infrastructure.ddos_protection` report protection signals, and say when they are not publicly verifiable.

Cloudflare's header reference says the `Cf-Ray` value is also sent to the origin, and recommends adding it to the origin's logs to match proxied requests with server log lines.

It notes that with Argo Smart Routing or tiered caching, the location code may reflect the data center that connected to the origin rather than the one the visitor reached.

When an audit reports an error on a Cloudflare-proxied page, the Ray ID in its evidence is what locates the same request in both Cloudflare's and the origin's logs.