大多数迁移到 Cloudflare 的团队都会将橙色云和灰色云之间的选择视为配置细节。他们为所有内容激活代理，认为保护越多越好，并在几周后当[数据库3]开始返回超时且没有任何错误消息时发现错误，或者当他们意识到源 IP 始终暴露在真正重要的记录中时。
代理模式实际上做了什么
当 A 或 CNAME 记录处于代理模式时，Cloudflare 的权威 DNS 不会返回您的源服务器的 IP。它从 Cloudflare 本身返回一个任播 IP。客户端连接到网络的边缘节点之一，该节点完成 TLS、检查请求，然后才将流量转发到其服务器 - 可以选择启用缓存、应用 WAF 规则，并让工作人员在中途拦截请求。
服务器的真实 IP 对公共 DNS 是隐藏的。对注册表的任何外部查询都会返回 Cloudflare IP，而不是您的 IP。这具有具体的含义：想要绕过 WAF 的攻击者需要通过另一种方式发现源 IP：泄露的日志、crt.sh 中的历史 TLS 证书、电子邮件标头或直接连接到未经代理公开的辅助服务。
无论区域内部配置如何，外部可见的 TTL 始终为 300 秒。 Cloudflare 控制外部解析器接收和缓存的内容 - 内部配置仅用于 Cloudflare 自己的名称服务器之间的同步。
仅 DNS 模式提供什么
使用灰色图标时，Cloudflare 仅充当权威 DNS。名称查询返回服务器的真实IP。边缘没有 TLS 终止，没有 WAF，没有缓存，路径中没有 Worker。客户端直接连接到源服务器 - Cloudflare 永远不会看到流量。
对于 MX 记录，缺少代理是强制性的。电子邮件传送流程要求发送服务器直接连接到 MX 记录中指示的电子邮件服务器。如果 MX 记录尝试通过 Cloudflare 代理，则 SMTP 将到达不知道如何处理端口 25 上的流量的边缘节点 - 并且电子邮件根本不会到达。 Cloudflare 甚至不允许您在 MX 记录上启用代理；默认仅 DNS，无法更改。
这同样适用于受支持端口上除 HTTP 或 HTTPS 之外的任何 TCP 服务。 Cloudflare 代理支持端口 80 和 443 上的 HTTP/HTTPS 以及一组受限制的记录替代端口 - 8080、8443 和其他一些端口。该集合之外的所有内容对于代理来说都是不可见的。
代理记录背后的数据库陷阱
这是事件中最悄无声息出现的场景。 A 记录指向在端口 3306 上运行 MySQL 的服务器。团队打开代理模式，因为“我们需要更多保护”。客户端尝试连接到端口 3306，但现在正在连接到 Cloudflare 边缘节点，该节点不会路由任意 TCP 流量。连接打开、等待并由于超时而关闭。没有明确的错误消息。 MySQL 甚至看不到连接尝试。
对于端口 5432 上的 PostgreSQL、端口 6379 上的 Redis、以及除 HTTP 之外的任何二进制协议，也会发生同样的情况。代理只是丢弃它无法解释的流量。要公开这些服务，注册表必须处于仅 DNS 模式 - 直接后果是服务器的 IP 公开可见。
直接 SSH 的子域注册也属于此类。如果团队维护指向堡垒服务器的 0 记录，则它只需是 DNS。 Proxied 将以同样的方式断开连接。
审核您所在区域暴露的内容
值得定期询问的问题很简单：哪些区域记录处于仅 DNS 模式，以及通过它们的流量是否受到其他方式的保护？
DNS 仅记录公开可用于直接攻击源的 IP，绕过代理记录中配置的任何 WAF 规则。如果服务器同时出现在代理记录和不同的仅 DNS 记录中 - 或者如果 IP 在过去某个时刻暴露并在 Shodan 等服务中建立索引 - 代理的保护效果是部分的。
为了彻底消除 HTTP 服务中的源 IP 暴露，Cloudflare Tunnel 彻底解决了该问题。源服务器使用 cloudflared 守护程序建立与 Cloudflare 网络的出站连接。用户流量到达边缘，通过隧道到达服务器，服务器永远不需要接受传入连接 - 没有开放端口，没有暴露的 IP。对于 HTTP 之外的任意 TCP 流量，Cloudflare Spectrum 涵盖了这种场景，但仅限于 Enterprise 计划。
在考虑关闭配置之前要检查什么
随着时间的推移，区域不断增长，积累了由不同人在不同环境中创建的记录，这些记录的意图有时没有记录在案。代理模式下的 2% 通配符对于动态创建的子域来说是合法且有用的，但它可能掩盖了这样一个事实：该通配符中的特定记录是手动创建为 DNS 的，原因已无人记得。
TXT 和 CAA 记录永远不会被代理 - 这是客户需要直接读取的数据，Cloudflare 不会干涉。 SRV 和 NS 也在代理之外。在这些情况下，界面甚至不显示该选项。
配置代理或仅配置 DNS 并不是迁移过程中的一次性决定。当新的服务暴露时，当服务器拓扑发生变化时，尤其是当源IP发生变化时，它需要被修改——因为旧值可能会继续在缓存或并行注册表中循环，而没有人注意到也需要更新。
另请阅读
- [DNSSEC 与 Cloudflare：它保护什么、不保护什么以及如何顺利激活4
- [Cloudflare 负载均衡和地理转向：当 DNS 成为智能流量层5
- [Cloudflare DNS：远远超出解析名称的网络基础设施6
- [Cloudflare 电子邮件路由：在您的域上接收电子邮件 - 以及不包括的内容77
- [Cloudflare WAF：托管保护真正阻止了什么以及它通过了什么8
- [WAF + 速率限制 + 机器人管理：边缘保护三重奏9