02 · DNS 与橙云代理怎么选

按流量类型判断 A、AAAA、CNAME 应该开启橙云，还是让邮件、验证与非 HTTP 服务保持灰云。

CDN · PHASE 1入门约 18 分钟DNS · Proxied · DNS only

先记住判断标准

橙云不是“让 DNS 更快”的装饰开关。它表示该主机名的 HTTP/HTTPS 流量先进入 Cloudflare。只有确实承载可代理 Web 流量的记录才应该开启。

一张决策树

flowchart TD
  A[这条记录做什么] --> B{类型是 A / AAAA / CNAME?}
  B -->|否| G[DNS only]
  B -->|是| C{承载 HTTP 或 HTTPS?}
  C -->|否| G
  C -->|是| D{用于邮件 / 域名验证 / 另一 CDN?}
  D -->|是| G
  D -->|否| E{上游明确支持 Cloudflare 代理?}
  E -->|否或不确定| G
  E -->|是| F[Proxied 橙云]

常见记录应该怎么选

场景	示例	建议	原因
网站与公开 Web 应用	`@`、`www`、`app`	Proxied	让 CDN、WAF、DDoS 防护和分析进入链路
HTTP API	`api`	通常 Proxied	可应用代理层安全与性能策略，但要检查上游 IP 验证
邮件交换	MX、`mail`	DNS only	普通邮件协议不经过 Cloudflare HTTP 代理
SPF、DKIM、DMARC	TXT、验证 CNAME	DNS only	需要向外部系统返回原始验证值
SaaS 域名验证	`_verify`、ACM 验证 CNAME	DNS only	代理或全局 CNAME flattening 可能破坏验证
SSH、FTP、RDP、游戏端口	`ssh`、`ftp`	DNS only	标准橙云不是任意 TCP/UDP 代理
指向另一 CDN 的 CNAME	CloudFront、Fastly 等	通常 DNS only	双重代理可能产生 TLS、路由或归属冲突

橙云实际改变了什么

观察点	Proxied	DNS only
DNS 回答	Cloudflare Anycast 地址	配置的真实源站地址
Web 请求路径	先到 Cloudflare	客户端直连目标
CDN/WAF/HTTP 分析	可用	不在这条路径上
源站 IP	常规 Web 解析中被隐藏	直接暴露
DNS TTL	Cloudflare 管理的 Auto	由记录设置控制

橙云不等于源站已经隐藏

历史 DNS、邮件记录、未代理子域名和主动扫描仍可能暴露同一源站 IP。代理状态不是源站防火墙；生产源站还应限制入口并保留必要的运维通道。

配置与验证

先给每条记录写用途

不要从图标开始判断。先写清楚“谁访问它、使用什么协议、第三方是否要求看到原始记录或源 IP”。用途不明的记录先保持 DNS only 并查清所有者。

为 Web 记录开启代理

在 DNS → Records 中，只为满足条件的 A、AAAA、CNAME 开启 Proxied。若同一名称有多个 A/AAAA 且至少一个开启代理，Cloudflare 会把该名称下这些记录整体作为代理处理。

理解 apex CNAME

Cloudflare 的 CNAME flattening 可以让根域名使用 CNAME，并返回最终 IP。它也支持 Pages 根域名，但对某些依赖原始 CNAME 回答的验证流程可能产生影响。

同时验证 DNS 与 HTTP

dig A www.example.com +short
dig MX example.com +short
curl -sS -D - -o /dev/null https://www.example.com/

Web 主机名开启代理后通常返回 Cloudflare 地址；MX 应继续指向真实邮件服务；HTTP 响应中的 cf-ray 可以证明请求到达 Cloudflare，但不能证明缓存命中。

三个容易误判的结果

没有 CF-Cache-Status：可能只是内容不参与缓存，不代表橙云失效。
修改后仍看到旧地址：先考虑递归解析器和本地缓存，不要立刻反复改记录。
验证 CNAME 失败：确认它是 DNS only，并检查是否把 CNAME flattening 设置到所有记录。

需要更短的概念解释可查看DNS、橙云与代理状态。下一步进入端到端 TLS。