Every A, AAAA, and CNAME record in a Cloudflare zone carries two decisions: the data (type and target) and the proxy status. The proxy status decides what everyone else sees. A proxied record answers with Cloudflare’s addresses and sends HTTP and HTTPS through Cloudflare; a DNS-only record publishes exactly what you stored.
The captures below come from and.guide, whose DNS is hosted on Cloudflare, so you can put your own output next to them.
What a proxied record returns
Live capture, 26 September 2026. Our delegation, then the apex from Cloudflare’s resolver (1.1.1.1), Google’s (8.8.8.8), and one of our authoritative nameservers:
$ dig +nocmd and.guide NS +noall +answer
and.guide. 3600 IN NS roan.ns.cloudflare.com.
and.guide. 3600 IN NS frida.ns.cloudflare.com.
$ dig +nocmd @1.1.1.1 and.guide A +noall +answer
and.guide. 300 IN A 172.66.44.244
and.guide. 300 IN A 172.66.47.12
$ dig +nocmd @1.1.1.1 and.guide AAAA +noall +answer
and.guide. 300 IN AAAA 2606:4700:310c::ac42:2cf4
and.guide. 300 IN AAAA 2606:4700:310c::ac42:2f0c
$ dig +nocmd @8.8.8.8 and.guide A +noall +answer
and.guide. 300 IN A 172.66.47.12
and.guide. 300 IN A 172.66.44.244
$ dig +nocmd @roan.ns.cloudflare.com and.guide A +noall +answer
and.guide. 300 IN A 172.66.47.12
and.guide. 300 IN A 172.66.44.244What to read from it:
- The addresses belong to Cloudflare, not to an origin. 172.66.44.244 and 172.66.47.12 fall inside 172.64.0.0/13, and the IPv6 pair inside 2606:4700::/32. Both ranges are on Cloudflare’s published IP list. This site runs on Cloudflare Pages, so there is no origin server behind them at all.
- The TTL is 300 everywhere, including at the authoritative server. That is Cloudflare’s
AutoTTL, which proxied records always use. - Each IPv6 address ends in its IPv4 twin, written in hex:
ac42:2f0cis 172.66.47.12. That is a pattern in this capture, not something to build on. - Both resolvers agree with the authoritative server, so nothing here is waiting on caches.
The stored target stays hidden
When you attach an apex domain to a Cloudflare Pages project, Pages creates the DNS record for you as a CNAME.
Live capture, 26 September 2026. Asking our authoritative nameserver for a CNAME at the apex:
$ dig +nocmd @roan.ns.cloudflare.com and.guide CNAME +noall +comments +authority
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43288
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; AUTHORITY SECTION:
and.guide. 1800 IN SOA frida.ns.cloudflare.com. dns.cloudflare.com. 2414193944 10000 2400 604800 1800The aa flag marks an authoritative answer, and ANSWER: 0 means there is no CNAME to show. Cloudflare flattens proxied CNAMEs, and any CNAME at the zone apex, into address answers. The dashboard or the API is the only place to read the stored target, so don’t “repair” a proxied record because dig doesn’t echo what you typed. The CNAME flattening guide covers the apex case in more depth.
The HTTP side: server and cf-ray
Live capture, 26 September 2026. Response headers for the apex and for www, filtered to the lines that identify the request path:
$ curl -sI https://and.guide/ | grep -iE "^(HTTP|server|cf-ray|alt-svc)"
HTTP/2 200
server: cloudflare
cf-ray: a41314c638575704-ICN
alt-svc: h3=":443"; ma=86400
$ curl -sI https://www.and.guide/ | grep -iE "^(HTTP|location|server|cf-ray)"
HTTP/2 301
location: https://and.guide/
server: cloudflare
cf-ray: a41314c5af3d095c-HKGserver: cloudflare plus a cf-ray ID is the signature of a request that passed through Cloudflare’s proxy. Cloudflare documents the three letters after the dash as the data center that handled the request. Across our runs that day, the apex was always answered in ICN (Seoul), while www was answered in HKG (Hong Kong) twice and NRT (Tokyo) once. The alt-svc line advertises HTTP/3.
The www hostname gets its own Cloudflare address pair.
Live capture, 26 September 2026. The same resolver, asked about www:
$ dig +nocmd @1.1.1.1 www.and.guide A +noall +answer
www.and.guide. 300 IN A 172.67.138.236
www.and.guide. 300 IN A 104.21.70.196
$ dig +nocmd @1.1.1.1 www.and.guide AAAA +noall +answer
www.and.guide. 300 IN AAAA 2606:4700:3035::ac43:8aec
www.and.guide. 300 IN AAAA 2606:4700:3031::6815:46c4These are still Cloudflare addresses (104.16.0.0/13 and 172.64.0.0/13), but not the apex’s pair. www is a separate proxied record whose only job is the redirect, while the apex is attached to Pages, as described in the Cloudflare Pages custom domain guide. Two proxied names in one zone don’t have to share addresses. To decide whether a name is proxied, compare its answer with Cloudflare’s published ranges or look for cf-ray, not with a sibling hostname.
A record type you didn’t create
Query www for type HTTPS (type 65) and you get an answer nobody typed into the dashboard.
Live capture, 26 September 2026. DiG 9.10.6 prints type 65 as raw hex, so we decoded it through Cloudflare’s DNS-over-HTTPS JSON API:
$ curl -s -H 'accept: application/dns-json' 'https://cloudflare-dns.com/dns-query?name=www.and.guide&type=HTTPS' | jq -r '.Answer[] | "\(.name) \(.TTL) \(.data)"'
www.and.guide 220 1 . alpn=h3,h2 ipv4hint=104.21.70.196,172.67.138.236 ech=AEX+DQBBegAgACC7qEZkgW2KJxglVK52B5L+RN3FIyTY0YGe9CBJrCxaRwAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:3031::6815:46c4,2606:4700:3035::ac43:8aecCloudflare generates HTTPS records on the fly for proxied names when the zone uses Universal SSL with HTTP/2 or HTTP/3, and it does not serve HTTPS records you add by hand for proxied names. This one advertises HTTP/3 (alpn=h3,h2), repeats the A and AAAA addresses as hints, and carries an Encrypted Client Hello configuration; base64-decoding the ech= value reveals the public name cloudflare-ech.com. Our Pages-attached apex returned no HTTPS record when we queried it the same day, so a missing HTTPS record is not a fault on its own.
What DNS only would publish instead
Our zone has no DNS-only web record to show, because a Pages site has no origin server. The difference is predictable, though:
| Proxied | DNS only | |
|---|---|---|
| A/AAAA answer | Cloudflare anycast addresses | The address you stored |
| CNAME answer | Flattened into Cloudflare addresses | The alias chain, with the target visible |
| TTL | Auto (300 seconds), not editable |
Auto (300 seconds), or 60 seconds to 1 day (30 seconds minimum on Enterprise) |
curl -sI output |
server: cloudflare and cf-ray |
Whatever the origin sends; no cf-ray |
| Origin address | Not in DNS | Public to anyone who queries |
| HTTPS (type 65) record | Generated by Cloudflare | Only if you add one yourself |
| Cloudflare HTTP analytics and security | Apply | Don’t apply |
In practice, a DNS-only api.example.com A record set to 203.0.113.10 answers exactly that, with the TTL you chose, and curl -sI shows the origin’s own server header. Switching an existing record from Proxied to DNS only therefore publishes its origin address, so review firewall rules before you flip it. The same exposure happens while a newly added zone is still pending: Cloudflare treats proxied records as DNS only until the zone is active.
Choosing proxy status per record
| What the record serves | Proxy status | Reason |
|---|---|---|
| Website or API on ports 80 and 443 | Proxied | Cloudflare recommends proxying every A, AAAA, and CNAME record that serves web traffic |
| HTTP or HTTPS on another port | Proxied only if the port is on Cloudflare’s list | The proxy listens on HTTP ports 80, 8080, 8880, 2052, 2082, 2086, 2095 and HTTPS ports 443, 2053, 2083, 2087, 2096, 8443 |
| SSH, mail protocols, game servers, other TCP or UDP | DNS only | Non-HTTP traffic needs DNS only or Spectrum, which covers all ports only on Enterprise |
| Host named in an MX record | DNS only | Mail doesn’t pass through the HTTP proxy |
| Domain-verification CNAME | DNS only | The verifier has to see the exact CNAME; TXT and MX records can’t be proxied at all |
| Custom domain on a SaaS or hosting platform | Follow the platform’s instructions | Many platforms validate their certificates over HTTP; Vercel, for one, says to use DNS only on Cloudflare or pass its ACME path through (details) |
| Windows authentication (NTLM, Kerberos) | DNS only | Incompatible with the proxy |
| CNAME to Mailchimp, Zoho, Keap, AWS SES, Microsoft, Intercom, or AWS Certificate Manager targets | DNS only (enforced) | Cloudflare blocks proxying for these targets |
Don’t switch a web record to DNS only just because the first proxied request failed. A 52x error or a redirect loop usually points at origin reachability or the SSL/TLS encryption mode; Cloudflare SSL errors and redirect loops walks through those.
TTL: what you can and cannot change
- Proxied records always use
Auto, which Cloudflare currently sets to 300 seconds. There is no TTL to edit. - DNS-only records use
Auto(300 seconds) or a custom value from 60 seconds to one day. Enterprise zones can go down to 30 seconds. - Caches can still hide a change: Cloudflare itself warns that local DNS caches may take longer than five minutes to update.
So the TTL you can lower ahead of a migration is the one on DNS-only records. Lower it at least one old-TTL period before the change, as described in DNS propagation: TTLs, caches, and verification.
CNAME behavior inside a Cloudflare zone
- A CNAME at the zone apex is flattened on every plan.
- Proxied CNAMEs are flattened, which is why the apex capture above shows only A and AAAA answers.
- DNS-only CNAMEs below the apex are returned as CNAMEs unless a paid zone turns on Flatten all CNAMEs. Cloudflare warns that this setting can break third-party verification, because the verifier no longer sees the CNAME.
- A flattened CNAME whose target has no A or AAAA records returns an empty answer (NODATA), which is easy to misread as a propagation delay.
A verification routine after every change
- Find the zone’s nameservers and ask one of them directly. Proxied records should return addresses in Cloudflare’s ranges; DNS-only records should return exactly the stored value.
- Ask two public resolvers. If they disagree with the authoritative answer, they are serving a cached copy; wait out the old TTL instead of editing the record again.
- Request the URL with
curl -sIand readserver,cf-ray, the status code, and anylocation. - For HTTPS, confirm the certificate covers the exact hostname you are testing.
dig +short NS example.com
dig +nocmd @your-ns.ns.cloudflare.com app.example.com A +noall +answer
dig +nocmd @1.1.1.1 app.example.com A +noall +answer
dig +nocmd @8.8.8.8 app.example.com A +noall +answer
curl -sI https://app.example.com/ | grep -iE "^(HTTP|server|cf-ray|location)"Symptoms that look like DNS problems
| What you see | Usual explanation | Next check |
|---|---|---|
dig returns Cloudflare addresses instead of your server |
The record is proxied; this is expected | curl -sI for cf-ray; the stored value in the dashboard |
dig returns your origin even though you chose Proxied |
The zone is still pending, for example because the registrar doesn’t delegate to Cloudflare yet | dig NS; the zone’s status in the dashboard |
| A vendor can’t find its verification CNAME | The record is proxied, or Flatten all CNAMEs is on | Set the record to DNS only; query the authoritative server for the CNAME |
| SSH or an unusual port times out | Proxied record, unsupported port or protocol | Serve that service from a DNS-only hostname |
| 52x errors while DNS looks right | Origin reachability or the SSL/TLS mode | The origin, not the DNS record |
| An old answer is still visible after five minutes | A cache between you and Cloudflare | Compare authoritative and recursive answers |