Cloudflare gives every A, AAAA, and CNAME record a switch: the orange cloud. It decides whether DNS hands out your real server address or Cloudflare’s. This one toggle explains a lot of confusing dig output.

DNS-only

A DNS-only record (grey cloud) returns exactly what you typed. The client connects straight to it:

client -> configured destination

Your origin address is public. Cloudflare’s caching, WAF, and DDoS protection don’t touch this traffic. DNS is just DNS.

Proxied

A proxied record (orange cloud) returns Cloudflare anycast addresses instead of your origin. Traffic flows through Cloudflare first:

browser -> Cloudflare proxy -> origin server

The proxy can cache, apply WAF rules, add redirects, and terminate TLS at the edge. Your origin IP stays hidden.

So when you dig a proxied hostname and the result doesn’t match your server’s IP, nothing is broken. That’s the feature.

What can be proxied

Only A, AAAA, and CNAME records that carry HTTP or HTTPS traffic can use the ordinary proxy. MX and TXT records are always DNS-only.

Watch out for mail. Your MX record points to a hostname like mail.example.com. The A record for that hostname must stay DNS-only. If you proxy it, mail servers connect to Cloudflare’s web proxy on port 25, which doesn’t speak SMTP. Mail bounces, and DNS looks fine.

Proxying adds a second contract

With a proxy in the middle, two connections have to work. The browser must reach Cloudflare. Then Cloudflare must reach your origin, the origin must accept the hostname, and the TLS mode and certificate must match.

A perfectly healthy DNS answer can end in a Cloudflare 52x error page when the second connection fails. That’s an origin problem, not a DNS problem.

Don’t rely on hiding alone

A proxied record hides your origin IP, but hiding isn’t security. Lock the origin down so only Cloudflare’s traffic gets in. And check for a DNS-only sibling record, like direct.example.com or an old ftp entry, that points at the same server and leaks the address anyway.

Compare the evidence

Two commands, two layers:

dig A www.example.com +short
curl -I https://www.example.com/

dig shows where clients connect. curl exercises the full proxy-to-origin path. When curl fails and dig is right, stop editing DNS.

Try this: classify five records as proxied or DNS-only and describe the traffic path for each. The website A record, the website CNAME, the MX, a domain-verification TXT, and the mail server’s A record.

DNS-only and proxied records