私有源站公开化之后：WAF、机器人与缓存放在哪一侧

把私有源站接到公网请求时，WAF、机器人管理和缓存应放在 Cloudflare 边缘代理侧，而不是在源站前面再加一层公网设备。源站保留私有 IP，Cloudflare 通过你已有的 Cloudflare One 连接回源；请求在 Cloudflare 网络完成 TLS 终止、WAF、规则和缓存，再进入私有网络。这个结论来自 Cloudflare 2026 年 10 月 30 日的 GA 公告。它解决的是“公网可达”，不是“公网暴露”，也不替代源站自身的身份认证与业务授权。

“公开化”改变的是可达路径，不是信任边界#

据 Cloudflare 2026 年 10 月 30 日公告，用户可以把一条代理（proxied）A 或 AAAA 记录指向私有 IP，Cloudflare 通过现有的 Cloudflare One 连接到达源站。源站保持私有 IP，不需要开放入站防火墙端口；使用 Cloudflare WAN 时源站无需安装连接器，使用 Cloudflare Mesh 时连接器运行在私有网络内，可服务多个源站。

对 RFC 1918 私有 IPv4、RFC 6598 CGNAT 地址段 100.64.0.0/10 和 RFC 4193 唯一本地 IPv6 地址段 fc00::/7，私有网络路由会自动启用，且不能关闭；公告称通过 API 尝试关闭会返回错误。若源站使用只能经私有网络到达的公网 IP，可以手动启用该设置。

这里有一个容易被忽略的边界变化。推断：过去的边界常是“公网 IP + 防火墙端口”，现在则更多落在“Cloudflare 账户权限 + Cloudflare One 连接 + 私有路由配置”上。源站不再直接面对公网，但代理账户和网络连接成为新的关键路径，需要按生产入口的权限来管理。

各组件放在哪一侧#

公告的表述是：WAF、机器人管理、限流、缓存、转换与重写规则、Workers 对私有源站“像对公共源站一样工作”。这给出了组件位置的基本答案。

这张表是工程建议，不是公告逐条列出的部署要求。公告同时列出了限制：Argo Smart Routing 和 Dedicated CDN Egress IPs 暂不支持，源站健康检查需要 Load Balancing。公告称完整限制见开发者文档，但本次材料未提供该文档链接，具体条目待核实。

WAF 与机器人管理：放边缘，但不要当成授权层#

把 WAF 放在边缘的直接理由是：请求在到达私有网络之前就能被检查，源站不需要为了防护再开一个公网入口。机器人管理也适合放在这里，因为它需要看到客户端请求，而不是等请求穿过私有网络后才判断。

但边界要写清楚。WAF 拦截的是请求特征，机器人管理判断的是流量形态，两者都不能回答“这个令牌是否属于该租户”“这个用户能否读取这条记录”。工程建议是：边缘做第一道拦截和限流，源站保留令牌校验、对象级授权、审计日志和幂等控制。对服务间 API，机器人管理还可能把正常自动化误判为异常，上线前应保留观察和灰度阶段，而不是直接全量阻断。

缓存：默认不缓存私有响应，除非能证明可共享#

缓存放在边缘的收益很直接：命中时请求不必回源。但对私有 API，这也是风险最集中的位置。若缓存命中，请求可能根本不到源站，源站的鉴权逻辑也就不会执行。因此缓存策略必须和授权策略一起设计，而不能先在边缘打开缓存、再指望源站兜底。

工程建议是：带用户身份、租户差异或权限差异的响应，默认不缓存；先对无身份差异的静态资源或公开 GET 响应启用缓存，再逐步扩大范围。需要确认缓存键是否包含影响响应的维度，例如租户、语言、授权状态；也要确认 Cache-Control、Vary 和 Set-Cookie 的处理方式。公告只说缓存对私有源站“像公共源站一样工作”，并未在材料中给出逐项默认行为，具体默认值应按文档核实，不能凭经验假定。

位置选择可以先用一个问题判断：这个响应能否被另一个用户或另一个租户安全复用？不能，就不应放在共享缓存里。

配置核对顺序#

1. 确认账户已开通 Private Origins 权限；公告说明需向账户团队申请。
2. 准备 Cloudflare One 连接：IPsec、GRE、CNI、Cloudflare Tunnel 或 Cloudflare Mesh。
3. 启用 Unified Routing；公告注明使用 Cloudflare Tunnel 时不需要。
4. 若通过 Cloudflare WAN 或 Mesh 连接，为 Cloudflare 源地址范围配置返回路由：IPv4 为 100.64.0.0/12，IPv6 为 2606:4700:cf1:5000::/64。注意这与自动启用私有路由的 CGNAT 网段 100.64.0.0/10 不是同一个范围。
5. 创建指向私有 IP 的代理 A 或 AAAA 记录，确认“Use private network routing”已启用。
6. 现有 WAF、缓存和机器人管理配置会按主机名生效，不需要为回源另建一套。

公告还提到一个 beta 期常见故障：请求超时且源站收不到流量时，先查返回路由。缺少 Cloudflare 源地址范围的返回路由，是当时最常见的配置失败原因。

API 自动化：private_routing 是 DNS 记录上的标志#

对通过 API 自动化部署的团队，私有路由是标准 DNS 记录上的一个附加属性。以下示例来自公告，未在本文环境执行；zone_id、域名和私有 IP 均为占位，不能直接用于生产。

POST /zones/{zone_id}/dns_records
{
  "type": "A",
  "name": "app.example.com",
  "content": "10.0.0.50",
  "ttl": 300,
  "proxied": true,
  "private_routing": true
}

公告解释，代理平台会查询 Cloudflare 的 Origin API，返回结果带有 private_routing: true 时，请求不再直接连私有 IP，而是交给私有网络层，再经 IPsec、GRE、Cloudflare Tunnel、CNI 或 Cloudflare Mesh 到达源站。这说明 private_routing 不只是一个展示字段，而是路由决策信号；自动化时应把它纳入 DNS 记录的创建、变更和回滚流程。

尚未发布的能力与适用边界#

本次 GA 覆盖的是“公网流量到达私有源站”。公告称，私有到私有流量仍在开发中，目标是 2027 年初开启封闭测试；这不是已发布能力，不能按现成功能设计。公告也明确，当前不支持 Argo Smart Routing 和 Dedicated CDN Egress IPs，源站健康检查依赖 Load Balancing。

本文面向在 API.PLUS 上发布接口的开发者，但以上结论只适用于 Cloudflare 公告描述的私有源站能力。API.PLUS 自身是否提供同类私有回源配置，材料未涉及，不能据此推断，待核实。实际落地时，先画清请求路径，再决定 WAF、机器人管理和缓存的位置：边缘负责拦截与可共享缓存，源站保留私有网络、最终授权和审计。