Cloudflare DNS 里的橙色云和灰色云，到底差在哪？——一次真实部署踩坑后的完整复盘

TL;DR：橙色云（Proxied）= Cloudflare 替你把流量代理一遍，你获得 CDN/WAF/边缘证书，代价是所有请求都要绕经 CF 边缘节点；灰色云（DNS only）= Cloudflare 只做权威 DNS 解析，访客直连你的源站。多数教程会告诉你"开橙色云，免费又安全"，但在我最近一次部署中，橙色云让网站彻底无法访问，切回灰色云反而一切正常。这篇文章讲清楚两朵云的本质区别，以及什么时候橙色云是毒药。

1. 两朵云的本质：DNS 返回的内容不一样

先说最容易被忽略的一点——橙/灰云的开关不在"流量"设置里，而在 DNS 记录上。它决定的第一个东西，是域名解析出来的是什么 IP。

同样一条 A 记录 example.com → 1.2.3.4：

灰色云（DNS only）：
$ dig example.com
example.com.    300    IN    A    1.2.3.4        ← 你的源站真实 IP

橙色云（Proxied）：
$ dig example.com
example.com.    1      IN    A    104.21.49.130  ← Cloudflare 边缘节点（Anycast）
                1      IN    A    172.67.xxx.xxx

橙色云下，Cloudflare 不再对外发布你的源站 IP，而是发布它自己的 Anycast 地址——全球几百个边缘节点共享这些 IP，访客会被调度到"最近的"一个。注意 TTL 也变了：代理记录固定为 1（自动），灰色云则由你设置（默认 300 秒）。

一句话：灰色云的 Cloudflare 是"电话簿"，橙色云的 Cloudflare 是"电话簿 + 前台总机"。

2. 流量路径的差异

这是所有功能差异的根源。两种模式下，一个 HTTPS 请求走过的路径完全不同：

【灰色云】访客 ──────────HTTPS(你自己的证书)──────────▶ 源站
         一条直线，Cloudflare 不经手任何字节

【橙色云】访客 ──HTTPS──▶ CF 边缘节点 ──按SSL模式──▶ 源站
         │                        │
         └─ TLS 在边缘终止         └─ 这一段叫"回源"（origin fetch）
            用 CF 为你签发的        走 HTTP 还是 HTTPS、验不验证证书
            Universal SSL 证书      由 zone 的 SSL 模式决定

橙色云把一条 TLS 连接拆成了两段：

• 访客 → 边缘：这段用的是 Cloudflare 自动签发的 Universal SSL 证书（Let's Encrypt 或 Google Trust Services），你源站上有没有证书都无所谓，浏览器看到的永远是 CF 的有效证书。
• 边缘 → 源站（回源）：行为由 SSL/TLS 模式决定——
  • Flexible：回源走 http://源站:80 明文
  • Full：回源走 https://源站:443，不验证证书（自签也行）
  • Full (Strict)：回源走 HTTPS 且验证证书链

3. 橙色云给你什么，拿走什么

只 有开橙色云才生效的功能（本质都是"流量经过我，我才能处理"）：

开橙色云的代价：

1. 回源链路多了一跳，而且是跨地域的一跳（见第 4 节，这是重灾区）。
2. 代理端口有限：HTTP 只支持 80/8080/8880/2052/2082/2086/2095，HTTPS 只支持 443/2053/2083/2087/2096/8443。你想让 CF 代理回源到源站的 3000 端口？不行。
3. 访客看到的是 CF 的 IP：你的源站日志里记录的来源 IP 全变成 CF 节段（104.x/172.64.x…），要拿真实 IP 得读 CF-Connecting-IP 头。
4. 免费版没有中国大陆节点：这是下一节的主角。

灰色云则一切归零：没有缓存、没有 WAF、没有边缘证书，HTTPS 得自己在源站搞（比如 certbot 申请 Let's Encrypt），源站 IP 直接暴露。Cloudflare 对你来说就退化成一个高质量的免费权威 DNS 服务——顺带说，这个 DNS 本身就很好用：API 完整、响应快、支持 apex 的 CNAME flattening。

4. 实战复盘：橙色云在中国大陆源站场景下的三连坑

背景：我把一个自托管应用（openGym）部署在腾讯云国内服务器上，域名挂在 Cloudflare 免费版。以下所有报错都是部署当晚真实抓到的。

坑一：橙色云 + Full 模式 → 525

curl https://my.domain
HTTP/1.1 525 SSL handshake failed    ← Cloudflare 边缘报的

525 的定义：CF 边缘与源站的 TLS 握手失败。但我从国内本机直连源站 443，握手完全正常——同一个端口、同一张自签证书。

坑二：降到 Flexible 模式 → 被注入 302

curl https://my.domain
HTTP/1.1 302 Found
Location: https://dnspod.qcloud.com/static/webblock.html?d=my.domain   ← 备案拦截页

诡异的地方在 nginx 日志里。源站 access log 中，来自 CF 节段（104.23.x.x）的请求状态码全是 499——nginx 专属状态码，意思是"客户端在响应完成前主动断开"。也就是说：请求到达了 nginx，但有什么东西抢在响应之前给访客发了一个 302，然后掐断了连接。nginx 自己从头到尾没发过任何 302。

坑三：诊断结论——拦截发生在国际回源链路

对照实验定位问题：

结论：拦截不在我的服务器上，而在 CF 边缘回源必经的国际链路上，按域名匹配——HTTP 匹配 Host 头，TLS 匹配 SNI 字段。域名后缀进了针对列表，橙色云的"回源"这一段在国际链路上裸奔，被中间设备透明注入/重置。而灰色云的国内直连根本不经过这段链路，自然无事。

这里还有个认知纠偏：很多人以为"备案拦截"只发生在自己的服务器/接入商那一层。实际上对未备案域名，国际入口的干扰 + 云厂商的治理是两层独立的机制，你的流量走哪条路决定了撞上哪一层。

解法：灰色云 + Let's Encrypt

【被拦】访客 → CF 边缘(海外) → 国际链路(被注入/重置) → 源站
【修复】访客 ──国内直连──▶ 源站 nginx (LE 证书, DNS-01 签发)

两个细节值得一提：

1. 证书用 DNS-01 验证签发。如果走 HTTP-01，Let's Encrypt 的验证服务器（在海外）访问 /.well-known/acme-challenge/ 时同样要跨国际链路，同样可能被注入打断——证书都签不下来。DNS-01 只需要写一条 TXT 记录，全程不过 HTTP。
2. 灰色云 ≠ 和 Cloudflare 一刀两断。域名解析还挂着 CF 的权威 DNS，证书自动续期用的还是 CF 的 DNS API token——只是 HTTP 流量不再经过它了。

5. 怎么选：决策框架

最后补三个实战提示：

• 切换是即时生效的（代理记录 TTL=1 的设计初衷之一），橙→灰回切时注意灰色记录的 TTL（默认 300s）和各地递归 DNS 的缓存。
• 混用时认清哪些功能是代理专属的：Always Use HTTPS、缓存规则、WAF 在灰色云记录上一律无效，别配了半天规则纳闷为什么不生效。
• 想确认某条记录当前是橙是灰，不用开面板：dig 出来的 TTL 是 1 且 IP 在 104.x/172.6x/188.114.x 等CF 节段，基本就是橙色云。

6. 结语

橙色云和灰色云不是"高级版和基础版"，而是两个不同的产品形态：代理层 vs 纯 DNS。橙色云把你的流量接管到全球边缘网络，换来缓存、防护和免费证书；灰色云把路让开，让访客和源站直接见面。

"开橙色云总是更好"是个漂亮的错觉。当你的源站和访客都在国内、域名又没有备案时，橙色云引入的那段国际回源链路足以让整个站点瘫痪——我的那次部署，最终答案就是关掉那朵橙色的云。

Cloudflare 依然是我最喜欢的免费基础设施之一，只是现在我知道了：它的正确姿势，有时是只当一个优秀的电话簿。