What Does the Orange Cloud Mean in Cloudflare?

In the Cloudflare dashboard, every A, AAAA, and CNAME record has a small cloud icon next to it. Orange means proxied. Gray — spelled grey in much of the world, and often searched that way — means DNS only. So the meaning of the orange cloud comes down to one question about that record: proxied vs DNS only. It looks like a cosmetic toggle and it is not: it decides whether Cloudflare is a CDN and firewall in front of your site, or merely the place where your DNS records happen to live.

Orange cloud vs grey cloud: proxied vs DNS only

The difference between the orange cloud and the grey cloud starts one step earlier than most people expect — at the DNS answer itself, before any HTTP request exists.

Everything else follows from those two answers:

One consequence is worth spelling out: a grey-clouded record publishes your server’s real address, which is what makes “I moved to Cloudflare and still got hit directly” possible.

Which records can be orange-clouded

Only A, AAAA, and CNAME records — the ones that resolve a name to an address. MX, TXT, NS, SRV, CAA and the rest are always DNS only, and the dashboard offers no toggle for them: proxying works by handing out Cloudflare anycast addresses instead of yours, and there is nothing to substitute in a TXT or MX record.

Three behaviours that surprise people:

• Mixed records on the same name are treated as proxied. If one A record for www is orange and another is gray, Cloudflare proxies both.
• Proxying is inherited along a CNAME chain. If a name anywhere in the chain is proxied, the request is proxied — and a proxied CNAME is always flattened, because the answer it returns is a Cloudflare address rather than the target name.
• Some CNAME targets are blocked from proxying on purpose. DKIM and validation targets — dkim.amazonses.com and its subdomains, subdomains of acm-validations.aws and onmicrosoft.com, zmverify.zoho.com — cannot be orange-clouded, because a proxied answer would break the very check they exist for.

Pointing a proxied record at a hostname in a different Cloudflare account is refused — that is Error 1014, CNAME Cross-User Banned, unless the owner of the target has onboarded your hostname through Cloudflare for SaaS. That sanctioned version is Orange-to-Orange routing.

The proxy only covers certain HTTP and HTTPS ports

The orange cloud is an HTTP/HTTPS reverse proxy, not a general network tunnel. By default it handles these ports:

Everything outside that list — SSH on 22, RDP on 3389, SMTP on 25, a database port, a game server — is not proxied. The hostname now resolves to Cloudflare, which has no reason to forward those ports to your machine, so the connection simply fails. Grey-cloud that hostname, or put it behind Cloudflare Spectrum, which proxies non-HTTP ports — all TCP and UDP ports on the Enterprise plan.

The alternate ports (everything above except 80 and 443) are proxied but not cached by default. If you serve a site on 8443 and wonder why the cache hit rate is zero, that is why.

When DNS only (the grey cloud) is the right answer

Reach for DNS only whenever the far end is not plain HTTP/HTTPS to your own origin:

• Mail. MX records cannot be proxied at all, and a hostname used for mail delivery (mail.example.com) should stay grey. Cloudflare does not proxy SMTP on port 25, so proxying it points senders at Cloudflare and delivery stops.
• Domain verification. Verification CNAMEs and TXT records must return the exact value the third party expects; a proxied answer returns Cloudflare addresses instead and verification fails.
• Non-HTTP services. SSH, RDP, FTP, game servers — anything on a port outside the list above.
• Sites hosted on a SaaS platform that terminates its own TLS — Wix, Squarespace, Webflow — unless the platform is explicitly integrated with Cloudflare. Two proxies both terminating TLS and both redirecting to HTTPS is how you get certificate errors and redirect loops.
• Endpoints validated by IP. If a partner allowlists your server’s address, proxying replaces it with Cloudflare’s.

A rule of thumb: if the hostname serves web traffic on a standard port and you control the origin, orange-cloud it. Everything else stays grey.

When the toggle causes an error

Most orange-cloud incidents look like one of these.

SSH or a custom port stopped working right after you switched

Expected. That port is not proxied. Move the service to its own hostname and grey-cloud that hostname, keeping the web hostname orange.

Mail stopped being delivered

Check whether the hostname your MX record points to is proxied, and give mail its own DNS-only hostname. (Cloudflare does try to save you: if an MX record points at a proxied name, it prepends _dc-mx to the answer so mail bypasses the proxy — a safety net, not a design to rely on.)

522, 521, or 524 errors appeared

These exist only because traffic is now proxied: Cloudflare is reaching your origin and not getting a usable answer. 521 means the origin refused the connection and 522 means it timed out — usually a firewall that does not allow Cloudflare’s IP ranges. 524 means the origin accepted the connection but exceeded the proxy read timeout.

Redirect loop or certificate error appeared

Usually the SSL/TLS encryption mode: with Flexible, Cloudflare talks to your origin over plain HTTP, and an origin that redirects HTTP to HTTPS will loop forever. Use Full (strict) with a valid certificate on the origin — the differences between the modes, and which error each one produces, are in the guide to Cloudflare’s encryption modes.

Your origin IP leaked anyway

Look for other records in the same zone — mail, ftp, cpanel, a forgotten staging subdomain — still pointing at the same server. And while a newly added domain is pending activation (up to 24 hours), records behave as DNS only even when marked proxied; rotate the origin IP after activation to close that window.

Client certificates (mTLS) stopped validating

On a proxied record TLS terminates at Cloudflare, which opens a second connection to your origin — so the origin never sees the visitor’s client certificate. Validate client certificates at Cloudflare instead, or have Cloudflare forward the certificate details to your origin in a header.

Windows authentication prompts in a loop

Integrated Windows Authentication, NTLM and Kerberos are incompatible with proxied records: NTLM authenticates the TCP connection rather than the request, and Cloudflare does not guarantee that consecutive requests reuse the same connection. That hostname needs to be DNS only.

Your app now sees Cloudflare addresses as the visitor IP

Expected: the origin’s peer is Cloudflare. Read the real client address from the CF-Connecting-IP header (or X-Forwarded-For) instead of the socket.

How to turn the orange cloud on or off

In the dashboard: open your domain, go to DNS → Records, Edit the record, and click the cloud under Proxy status. It takes effect immediately, though resolvers may hold the previous answer for up to five minutes.

Over the API: proxy status is the proxied boolean on the record:

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" \
  --request PATCH \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --json '{"proxied": true}'

From your phone: that toggle is the reason this site exists — Orange Cloud is a native iOS and Android client for Cloudflare, and flipping proxy status is one tap in the DNS list.

What if both ends are orange?

If your proxied record points at a hostname that is itself proxied — typically a SaaS platform using Cloudflare for SaaS, such as a Shopify store on your own domain — the request crosses two Cloudflare zones and both sets of settings apply, in order. Cloudflare calls this Orange-to-Orange, or O2O: Cloudflare Orange-to-Orange (O2O), explained.

FAQ