Fastest fix: in the Cloudflare dashboard go to your zone, open DNS then Records, and look at the cloud icon next to each A / AAAA / CNAME row. Orange (“Proxied”) routes traffic through Cloudflare’s edge; grey (“DNS only”) sends it straight to your origin. If your site broke “out of nowhere,” you (or a vendor’s instructions) almost certainly flipped the wrong one. For an HTTP-01 SSL challenge that’s stuck pending, set the apex/www record to grey, let the cert issue, then flip it back to orange. For everything else, match the cloud state to the table below.
That one icon does far more than a CDN switch. Orange rewrites the public TLS chain, hides the origin IP behind Cloudflare’s anycast addresses, runs every request through the WAF, and applies your Page Rules, Workers, and Cache Rules. Grey turns all of that off and answers DNS with your real origin IP. Flipping between the two is the single most common cause of “I changed nothing and it broke” in any Cloudflare-fronted stack. Symptoms range from sudden SSL warnings, to WebSocket disconnects every 100 seconds, to a CA refusing to issue, to your origin getting hammered by direct attacks the next day.
Cloudflare’s current label for the toggle (as of June 2026) is Proxy status: “Proxied” (orange) vs “DNS only” (grey). Older docs and the rest of this article use the orange/grey shorthand interchangeably.
Common causes
Each scenario below is “flipped the wrong cloud.” Knowing which one you’re in tells you which way to flip.
1. Origin SSL cert provider needs grey cloud during issuance
Let’s Encrypt’s HTTP-01 challenge hits http://yourdomain.com/.well-known/acme-challenge/.... If the cloud is orange, Cloudflare’s edge answers first and serves its own response, not your origin’s challenge file, so the CA cannot validate and issuance hangs in pending. (DNS-01 challenges are unaffected by proxy status, which is why managed platforms increasingly prefer them.)
How to spot it: your platform (Vercel, Render, Fly, custom origin) shows “SSL pending” / “Issuing” for hours. The Cloudflare DNS panel shows orange (Proxied) next to the A or CNAME record for the apex or www.
2. WebSocket connection dropped at edge
Cloudflare proxies WebSockets on every plan, including Free and Pro, but it closes a connection after 100 seconds with no data in either direction (as of June 2026). If your app uses long-lived sockets (Phoenix Channels, Socket.IO, real-time collaboration) and goes idle, connections die every ~100s on orange. A direct (grey) connection to the origin keeps them alive as long as your origin allows.
How to spot it: sockets drop roughly every 100s, close codes show 1006 or 1001 (“going away”). The same socket against a grey-cloud / direct origin stays up for hours.
3. Apex CNAME returns the wrong IP depending on cloud state
You set yourdomain.com as a CNAME to app.platform.com. DNS doesn’t allow a CNAME at the apex, so Cloudflare flattens it — and (correcting a common myth) Cloudflare flattens the apex CNAME by default on every plan whether the record is orange or grey. The difference is what IP it returns: orange returns Cloudflare’s anycast IPs (104.x / 172.67.x); grey returns the platform’s real IP that app.platform.com resolves to right now.
How to spot it: dig yourdomain.com +short returns Cloudflare ranges on orange and the platform’s own IP on grey. Real failures here usually come from the platform side — many managed hosts reject requests whose Host header arrives via Cloudflare’s IPs, or expect their own CNAME target unproxied. (True apex-CNAME NXDOMAIN only happens when the apex CNAME lives on a non-Cloudflare resolver that does not flatten.)
4. Origin protected only because Cloudflare hides the IP
You enabled orange weeks ago, then toggled to grey for some reason (cert issuance, debugging, vendor instruction). DNS now returns your origin IP directly, so attackers who previously could not find your origin can hammer it.
How to spot it: origin load spikes; access logs show direct hits that are not from Cloudflare’s published IP ranges, and the cf-connecting-ip header is absent on those requests.
5. SSL Full vs Flexible mismatch surfacing on toggle
When orange, Cloudflare’s SSL/TLS encryption mode (Flexible / Full / Full (strict)) determines how it talks to your origin. If your origin redirects HTTP to HTTPS and Cloudflare is on Flexible, you get an infinite redirect loop. If your origin’s cert is self-signed or expired and you’re on Full (strict), you get a 526.
How to spot it: ERR_TOO_MANY_REDIRECTS (Flexible + origin redirects to HTTPS); Error 525 (handshake to origin failed — no TLS listening, or protocol/cipher mismatch); Error 526 (handshake succeeded but Cloudflare rejected the origin cert in Full (strict)).
6. Page Rules / Workers only run when orange
Page Rules, Workers, Transform Rules, Cache Rules — none of them execute for grey-cloud records. If you flip grey for a “DNS test” and forget, your edge logic is silently disabled.
How to spot it: headers your Worker injects are missing, the Cloudflare cache hit ratio drops to zero, and the cf-ray response header is absent in browser DevTools.
Before you start
- Open DNS then Records in the Cloudflare dashboard and note the current Proxy status (orange/grey) of each record in scope (apex, www, any subdomain).
- Check the encryption mode under SSL/TLS then Overview: Off / Flexible / Full / Full (strict), or the newer Automatic SSL/TLS (see Step 3).
- Identify which platform owns each subdomain (origin server, Vercel, Fly, etc.) — different platforms need different cloud states.
- Have your origin’s direct IP handy in case you need to test with
curl --resolve.
Information to collect
dig yourdomain.com +short— Cloudflare IPs (usually 104.x or 172.67.x) vs your origin IP.curl -sI https://yourdomain.com— look forcf-ray:andserver: cloudflare.- The SSL/TLS encryption mode from the SSL/TLS then Overview tab.
- A screenshot of the DNS record list with the cloud icons visible.
- Any recent change log: who toggled, when, and why.
Step-by-step fix
Apply the pattern that matches your situation.
Step 1: Decide the correct end state per record
| Record | Recommended cloud | Why |
|---|---|---|
| Origin servers you run (VM/container) | Orange (Proxied) | DDoS + caching + WAF; set mode to Full (strict) with a valid origin cert |
| Apex / www on a managed host (Vercel, Netlify) | Usually grey (check host docs) | Many managed hosts terminate TLS themselves and reject Cloudflare-proxied Host headers |
Apex CNAME to <platform>.com | Per platform guidance | Cloudflare flattens it either way; orange returns CF IPs, grey returns platform IPs |
| WebSocket-heavy subdomain | Grey, or Business+ plan | Free/Pro orange closes idle sockets at 100s |
| Mail records (MX, SPF, DKIM, DMARC) | Always grey | Mail servers don’t speak HTTP; Cloudflare won’t let you proxy MX anyway |
Step 2: Turn grey while issuing the SSL cert
1. Cloudflare dashboard -> DNS -> Records
2. Click the orange cloud next to the apex (or www) record
3. It turns grey ("DNS only")
4. Wait ~30 seconds for the change to take effect at Cloudflare's edge
5. Re-trigger SSL issuance at your platform
6. Wait for "Issued" / "Active" status
7. Click grey back to orange if you want Cloudflare in frontAfter issuance you can re-enable orange. Your platform’s cert stays on the origin; Cloudflare layers its own edge cert on top. If your platform supports a DNS-01 challenge instead, you can leave the record orange and skip this dance entirely.
Step 3: Set the right SSL/TLS encryption mode for Cloudflare-to-origin
In the dashboard go to SSL/TLS then Overview. As of June 2026 many zones now default to Automatic SSL/TLS, which probes your origin and ramps the chosen mode from 1% of traffic upward; it will not downgrade you if a cert expires. If you set a mode manually, use this table:
| Origin state | Required Cloudflare mode |
|---|---|
| Origin has a public CA cert (Let’s Encrypt, etc.) | Full (strict) |
| Origin has a Cloudflare Origin CA cert | Full (strict) |
| Origin has a self-signed cert only | Full |
| Origin only listens on HTTP :80 | Flexible (avoid in production) |
Full connects over HTTPS but does not validate the origin cert, so it accepts self-signed or expired certs. Full (strict) additionally requires a trusted, unexpired cert whose hostname matches — that strictness is what surfaces a 526. Flexible makes the Cloudflare-to-origin hop plain HTTP while reporting HTTPS to the user: it looks “secure” but isn’t, and it triggers ERR_TOO_MANY_REDIRECTS when the origin also redirects to HTTPS. The free Cloudflare Origin CA cert (valid up to 15 years, trusted by Cloudflare’s edge) is the cleanest way to qualify for Full (strict).
Step 4: For WebSocket needs, choose grey or upgrade plan
If your app needs long-lived sockets:
- Option A: add a client-side heartbeat (ping/pong) every 30-60s so the connection is never idle for 100s. This is the cheapest fix and keeps you on orange.
- Option B: move WebSocket traffic to a dedicated subdomain (
ws.yourdomain.com) and keep that record grey; HTTP traffic at the apex stays orange. - Option C: upgrade to Cloudflare Business or Enterprise, where the idle timeout is higher/configurable.
- Option D: use Cloudflare Spectrum (Enterprise) for full TCP proxying without the WebSocket HTTP envelope.
Step 5: If you need grey cloud for testing, set a reminder to flip back
A common pattern: flip grey to debug, forget, weeks pass. Set a reminder:
echo "CHECK CLOUDFLARE: did we re-enable orange on apex?" | at now + 2 hoursOr a Slack/Linear/calendar task. Forgetting orange means silently losing WAF, DDoS protection, Workers, and cache.
Step 6: Verify origin IP exposure if grey
If you intentionally went grey, audit your exposure:
dig yourdomain.com +short
# returns the origin IP directly -- anyone can find itMitigations:
- Restrict the origin firewall to Cloudflare’s published IP ranges (see
https://www.cloudflare.com/ips/) — but only if you plan to flip back to orange. - If the record will stay grey, treat the origin as fully exposed: a real firewall, fail2ban, and normal DDoS preparation.
How to confirm it’s fixed
curl -sI https://yourdomain.comreturns acf-ray:header when you expect orange, and omits it when you expect grey.dig yourdomain.com +shortreturns Cloudflare ranges (104.x / 172.67.x) for orange, your origin IP for grey.- In browser DevTools, the certificate chain shows a Cloudflare-issued edge cert (issuer like “Cloudflare Inc ECC CA-3” / “WE1”) when orange, and your origin’s CA (e.g. Let’s Encrypt) directly when grey.
- WebSocket connections survive past 100s once you added a heartbeat, went grey, or upgraded.
- For orange records, the dashboard shows non-zero requests against your Workers / Page Rules / Cache Rules.
Long-term prevention
- Treat the cloud icon as a production toggle that requires teammate review, not a casual flip.
- Pin the intended state of each record in a DNS-as-code repo (Terraform
cloudflare_recordwithproxied = true/false) so a PR diff catches accidental flips. - Watch DNS changes via Cloudflare’s audit log and review it weekly.
- Pair every grey-cloud event with a deadlined follow-up task to flip back.
- Standardize on Full (strict) plus a Cloudflare Origin CA cert on every origin — that removes the Flexible/Full ambiguity entirely.
Common pitfalls
- Going grey to issue a cert and forgetting to go back to orange — silently losing CDN, WAF, and origin masking.
- Choosing Flexible because “it just works in the browser” — the Cloudflare-to-origin hop is plain HTTP, so any auth header travels in cleartext.
- Trying to proxy (orange) an MX record; Cloudflare blocks it, and the resulting error confuses people.
- Assuming a grey apex CNAME returns NXDOMAIN on Cloudflare — it doesn’t; Cloudflare flattens the apex either way, so the real issue is usually the platform rejecting Cloudflare’s IPs or
Hostheader. - Forgetting that orange terminates client TLS at the edge, so an origin cert mismatch is invisible in the browser but breaks Full (strict) with a 526.
FAQ
Q: Why does my Let’s Encrypt cert say “Cloudflare” in the browser?
Because the browser is seeing Cloudflare’s edge cert, issued by Cloudflare to your domain. Your origin’s Let’s Encrypt cert lives on the Cloudflare-to-origin hop (or doesn’t exist, if you’re on Flexible). When orange, the browser never sees the origin cert.
Q: Can I have orange on apex but grey on www, or vice versa?
Yes. Each record carries its own proxy status. Just make sure any root-to-www (or www-to-root) redirect accounts for which side has Cloudflare in front, so you don’t loop or leak the origin.
Q: My WebSockets work fine on orange. Did the 100s limit go away?
No — the 100-second idle close still applies on Free and Pro as of June 2026. Yours survive because the connection isn’t actually idle (Socket.IO and most clients send periodic pings), you’re on a higher plan, or your sockets are short-lived. The cap is per idle TCP connection with no data, not per logical session.
Q: What’s the difference between Error 525 and Error 526?
525 means the TLS handshake between Cloudflare and your origin failed outright — no TLS listening on the origin, or a protocol/cipher mismatch. 526 means the handshake succeeded but Cloudflare rejected the origin certificate under Full (strict) because it’s expired, self-signed, untrusted, or for the wrong hostname. Fix the origin cert (a Cloudflare Origin CA cert is the easiest), or temporarily drop to Full to confirm the cert is the cause.
Q: Does the proxy status affect my SSL cert issuance?
Only for HTTP-01 challenges, which travel over HTTP and get intercepted by an orange edge. Switch the record to grey during issuance, or use a DNS-01 challenge, which is independent of proxy status.
Related reading: SSL cert delay, SSL mixed content warning, HTTPS not forced, and A vs CNAME confusion.