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.

One consequence is worth spelling out: a gray-clouded record publishes your server’s real address, which is what makes “I moved to Cloudflare and still got hit directly” possible. Cloudflare can only protect requests it actually receives.

Which records can be orange-clouded

Only A, AAAA, and CNAME records — the record types that resolve a name to an address. MX, TXT, NS, SRV, CAA and the rest are always DNS only, and the dashboard will not offer you a toggle for them. The reason is structural rather than arbitrary: 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.
• Some CNAME targets are blocked from proxying on purpose. DKIM and validation targets such as dkim.amazonses.com, acm-validations.aws, or subdomains of onmicrosoft.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 also 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

This is the single biggest trap for newcomers. 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, a dev server on 3000 — is not proxied. The hostname now resolves to Cloudflare, and Cloudflare has no reason to forward a connection on those ports to your machine, so the connection simply fails. Gray-cloud that hostname, or put it behind Cloudflare Spectrum, which proxies non-HTTP ports — all TCP and UDP ports on the Enterprise plan.

Note also that the alternate ports (2052, 2053, 2082, 2083, 2086, 2087, 2095, 2096, 8880, 8443) 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 the gray cloud is the right answer

Reach for DNS only whenever the service on the other 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 gray. Cloudflare does not proxy SMTP on port 25, so proxying the mail host 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 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 and similar — unless that 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 for webhooks or API calls, 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 gray.

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 gray-cloud that hostname, keeping the web hostname orange.

Mail stopped being delivered

Check whether the hostname your MX record points to is proxied. Give mail its own DNS-only hostname rather than sharing the web hostname. (Cloudflare does try to save you here: if an MX record points at a proxied name, it dynamically 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 only exist because traffic is now proxied: Cloudflare is reaching your origin and not getting a usable answer. A 521 means the origin refused the connection, 522 means it timed out — both usually a firewall that does not allow Cloudflare’s IP ranges, or an origin that is down. A 524 means the origin accepted the connection but took longer than the proxy read timeout to respond.

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 the other records in the same zone — mail, ftp, cpanel, a forgotten staging subdomain — that still point at the same server. Also remember that while a newly added domain is still pending activation (up to 24 hours), records behave as DNS only even when marked proxied; rotating the origin IP after activation closes that window.

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 switch it

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

Over the API: proxy status is the proxied boolean on the DNS record. A partial update is enough:

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 by Cloudflare — 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 a defined order. Cloudflare calls this Orange-to-Orange, or O2O, and it has its own rules about which zone wins: Cloudflare Orange-to-Orange (O2O), explained.

FAQ