套了 CDN 还会被打穿？源站 IP 暴露的六个常见路径与收敛方法

直接回答： 代理 DNS 记录之后，解析域名拿到的是 Cloudflare 的地址而不是你的服务器——但这只挡住了「查解析」这条路。任何已经知道地址的人，或者能从历史解析、证书日志、邮件头、未代理子域名里找到地址的人，都可以直接把流量打到源站，边缘上什么都不会执行。收敛有四层：只放行 Cloudflare 公布的 IP 段（全套餐，官方标注为中等安全且受 IP 伪造影响）、AOP 回源鉴权（全套餐，需 Full 或 Full strict，与 Tunnel 不兼容）、Cloudflare Tunnel（全套餐，仅出向连接，源站无入站监听）、以及企业版专属的专属出口 IP、Magic Transit 与 CNI。Cloudflare 还明确建议接入之后轮换源站 IP，因为 DNS 记录属于公开信息。

先纠正一个前提：CDN 隐藏的到底是什么

当你把 DNS 记录设为代理状态，访客解析你的域名时拿到的是 Cloudflare 的 IP，而不是源站的真实地址。这确实有用，但它也是那个长期存在的误解的来源：它隐藏的是一次 DNS 查询的答案，不是那台服务器。

Cloudflare 自己的文档把这条限制写得很直白。如果有人发现了你的源站 IP——「例如通过历史 DNS 记录或邮件服务器配置」——他们就能直接把流量发到你的服务器，「完全绕过 Cloudflare 的安全防护」。

所以问题从来不是「CDN 能不能藏住我」，而是「这个地址是不是已经在别处泄露过；如果泄露过，有人拿它来做什么」。

为什么直连源站是另一类问题

经过边缘到达源站的流量，受你配置的一切约束：WAF 规则、bot 检测、限流、缓存、DDoS 缓解。直连源站的流量，这些一样都不经过——没有规则被执行，没有缓存被命中，攻击流量也没有在边缘被吸收。

这改变了攻击的成本结构。攻击者不再需要生成足以压垮一个由数百个数据中心组成的 anycast 网络的流量，只需要压垮一台服务器或一台负载均衡器。故障形态也变了：你的 Cloudflare 仪表盘可能一切正常，而源站已经挂了——这让事故更难定位。

源站 IP 泄露的六个常见路径

每一条都有对应的自查方法。

一、历史 DNS 记录。 在你把记录设为代理之前，A 记录指向某个地址，而那个答案是公开的。DNS 历史服务会一直保留它。Cloudflare 的文档把这条列为源站被发现的首要例子。

二、指向同一台主机的「仅 DNS」记录。 并不是每条记录都需要代理，但每一条解析到源站的未代理记录，都是一份公开的答案。MX、TXT、SPF 常常被忽略，多年前为了域名验证或某个合作伙伴接入而创建的记录也是。

三、同机部署的邮件服务。 如果源站同时跑邮件，地址会出现在 MX 记录、SMTP 横幅，以及应用发出的每一封邮件的信头里——重置密码、账单、通知。读一封自己系统发出的邮件，往往是最快的确认方式。

四、子域名与旁路服务。 预发环境、管理后台、对象存储的直连域名、监控探针、为某次接入单独建的 API 主机。其中任何一个解析到同一台主机，无论是否代理，都在对外公布这个地址。

五、证书透明日志。 公共 CA 会把签发的证书写入可公开检索的追加式日志。日志里的主机名会暴露命名规律；如果源站证书是直接签发的，还会带上主机本身的信息。

六、应用自身的输出。 报错堆栈里的内网地址、Webhook 回调里暴露的来源、API 响应中的内部主机名、重定向目标，以及生产环境里忘了关的调试端点。

怎么自查：一份可执行的验证顺序

从你的网络外部执行，并把结果记下来——这是事故发生时你会需要的基线。

1. 逐条清点记录。 把 zone 里的记录过一遍，列出所有「仅 DNS」而非代理的记录，标注其中哪些解析到与源站相同的地址。
2. 测试直连路径。 带上正确的 Host 头，用 HTTPS 直接连源站地址，把响应和走边缘的同一个请求做对比。如果直连返回的是你的应用，而不是拒绝或超时，说明源站可达。
3. 检索证书透明日志，用你的域名搜，也留意你不认识的主机名。
4. 查 DNS 历史服务，查主域名，也查你能想到的每一个子域名。
5. 触发一封外发邮件或一次 Webhook，读原始信头与载荷，看有没有你并不打算公开的地址。
6. 检查每个子域名的代理状态，包括那些为一次性项目创建的。

如果第 2 步成功了，无论你是否找到泄露点，都应该把这个地址当作已经暴露。先轮换、先收敛；溯源是次要问题。

收敛的四层手段，从弱到强

Cloudflare 把源站保护分成四层，并对每一层给出评级。评级很重要——它告诉你自己实际买到的是什么。

层	手段	安全强度	可用性	代价与工作量
网络层	只放行 Cloudflare 公布的 IP 段	中等——IP 伪造可以绕过	全套餐	低，但需要持续跟踪地址段变化
传输层	AOP 回源鉴权	强	全套餐，需 Full 或 Full strict	证书管理；与 Tunnel 不兼容
应用层	Cloudflare Tunnel	强	全套餐，需运行 cloudflared	改变网络架构；源站无入站监听
网络层（企业版）	Magic Transit、CNI、专属出口 IP	强	仅 Enterprise	按合同单独采购

三个运维细节决定这些手段是否按预期生效：

• 白名单意味着要维护这份名单。 Cloudflare 公布自己的地址段，并说明它们不常变动、新段会在投入生产前先加入公开列表、且可以通过 API 让配置保持更新。请自动化这件事——过期的白名单迟早会挡掉正常的边缘流量。
• AOP 需要正确的 SSL 模式。 SSL 模式为 Off 或 Flexible 时它不生效；而且 zone 级、按主机名级、全局级这三级配置相互独立——启用其中一个不会自动启用另外两个。
• AOP 与 Tunnel 在同一个主机名上互斥。 Cloudflare 明确写道，AOP「对经 Cloudflare Tunnel 路由的主机名不生效」，因为隧道流量已经用连接器凭证完成了认证。按主机名二选一。

共享 IP 段不够用时的企业版选项

白名单是有效的，但 Cloudflare 的 IP 段被所有代理状态的主机名共用——也就是说放行它们，等于放行了可能来自其他客户 zone 的流量。对无法接受这一点的团队，官方文档给出的替代方案是：

• 专属出口 IP（Smart Shield Advanced），让源站防火墙面对一组更小且稳定的源地址。
• BYOIP（自带 IP），由 Cloudflare 在所有节点宣告你自有或租用的地址段。
• 静态 IP 地址，通过客户团队为域名配置。
• Magic Transit，通过 BGP 宣告在网络层保护整个 IP 段，而不是代理 Web 请求——这是针对不同问题的另一种架构。
• Cloudflare Network Interconnect（CNI），用于专线直连。

还有一个中间选项值得知道：Business 与 Enterprise 客户可以上传自定义 SSL 证书，这能在不改套餐的前提下减少自己域名与其他客户域名共用的 Cloudflare IP 数量。

收敛之后还要做的两件事

轮换源站 IP。 Cloudflare 明确建议这一步，理由正是 DNS 记录属于公开信息。白名单并不能抹掉「旧地址已经出现在别人的记录里」这个事实。如果源站是云上实例、地址可变，这是常规操作；如果是固定的物理地址，这就是一个项目，值得在事故之前而不是事故之中规划。

然后监控结果。 源站错误率告警告诉你请求是不是在源站失败；健康检查与负载均衡让你在某个源站不健康时有地方可切。这些和收敛是互补关系，不是替代关系——收敛减少的是「谁能到达源站」，监控告诉你的是「源站什么时候出问题」，与谁在访问无关。

如果你跑在 AWS 上，还有一件事值得查：Cloudflare 使用 172.64.0.0/13 作为公网出口地址空间，它不是 RFC 1918 私有地址空间。如果 VPC 路由表里有一条覆盖 172.16.0.0/12 或更宽的 172.16.0.0/8、且指向内部目标（Transit Gateway、VPN 网关、NAT 网关或 VPC 对等连接）的路由，它会在流量到达互联网网关之前就把它截走，导致使用该地址段的数据中心返回 521、522。修法是加一条更具体的路由，把 172.64.0.0/13 指向互联网网关。这个问题不会出现在安全组审计里，因为安全组是在实例层评估的。

这些手段解决不了什么

• 源站容量。 收敛挡掉的是不想要的调用方，它不增加余量。如果源站本来就撑不住正常的峰值流量，没有攻击的日子它也会挂。
• 应用层漏洞。 直连源站只是其中一条路径；通过边缘利用一个漏洞是另一条，AOP 和 Tunnel 对后者毫无作用。
• 内网横向移动。 一旦网络内部已经有东西失陷，这些控制手段都不在攻击路径上。
• 第三方依赖故障。 源站可能因为某个依赖挂掉而不可达，全程没有任何攻击者参与。
• 把入口集中到一家供应商这个取舍本身。 这是主动选择，代价与边界可以参考网站遭受 DDoS 攻击时，CDN 能否解决问题？。

常见问题

Cloudflare 能完全隐藏源站 IP 吗？ 它对「解析你主机名的人」隐藏了源站：代理状态的 DNS 记录返回的是 Cloudflare 的地址。但它无法抹掉接入之前就公开过的地址，也无法阻止其他渠道的泄露。「已隐藏」应该理解为「DNS 不再对外公布」，而不是「没人知道」。

只放行 Cloudflare 的 IP 段就够了吗？ 这是基线，而 Cloudflare 把它评为中等安全，因为 IP 伪造可以绕过。更强的配置是 AOP 回源鉴权或 Cloudflare Tunnel。实践中的顺序是：先用白名单减少噪声，再加上两者之一。

AOP 能和 Cloudflare Tunnel 一起用吗？ 同一个主机名上不行。Cloudflare 明确说明 AOP 对经 Tunnel 路由的主机名不生效，因为隧道流量已经通过连接器凭证完成认证。按主机名选择其一。

真的需要换源站 IP 吗？ Cloudflare 建议接入之后就换，理由是 DNS 记录属于公开信息，代理之前的那条答案可能已经被记录在别处。是否紧急，取决于这个地址现在还能不能从公网访问——而这正是上面那份验证顺序要确定的事。

源站保护需要 Enterprise 吗？ 主要的三件都不需要。IP 白名单、AOP 回源鉴权、Cloudflare Tunnel 在所有套餐都可用。需要 Enterprise 的是 Magic Transit、CNI、Smart Shield Advanced 的专属出口 IP，以及 BYOIP 与静态 IP。

为什么会看到 521、522 错误？ 原因有很多，其中一个值得先查云上的路由。Cloudflare 的公网出口地址空间包含 172.64.0.0/13，它不属于私有地址空间；VPC 路由表里一条把更宽的 172.x 指向内部目标的路由会把这部分流量截走。加一条更具体的 172.64.0.0/13 路由指向互联网网关即可。

相关阅读

• 网站遭受 DDoS 攻击时，CDN 能否解决问题？
• 出海企业如何选择 DDoS 防护服务？
• 已经在用 AWS、阿里云、腾讯云了，还需要 Cloudflare 吗？
• 海外网站遭遇 CC 攻击怎么办？

如果你希望有人帮你确认源站是否还能从公网直连，这个检查只需要几分钟，也不需要你开放任何基础设施权限——和我们一起评估现有架构。