私网源站接入公网流量：WAF 与缓存链路的信任边界怎么划

结论先说：私网源站接入公网流量后，信任边界不在“公网 IP 有没有暴露”，而在请求进入私有网络之前，Cloudflare 边缘做了什么判定。网络可达性、边缘策略、应用身份是三条不同的边界，混在一起划，最容易出现“WAF 配了就等于安全了”的误判。

本文依据 Cloudflare 2026 年 10 月 30 日的 Private Origins 正式可用公告展开（来源）。文中涉及的机制描述来自该公告；涉及如何划分边界的判断属于分析建议，会明确标注。

一、“源站保持私有”改变了路径，没有改变请求发起方的构成#

公告描述的做法是：把一条代理（proxied）A 或 AAAA 记录指向私网 IP，Cloudflare 通过客户已有的 Cloudflare One 连接到达源站。源站保留私网 IP，不需要开入站防火墙端口，也不需要源站上跑 connector 软件（Cloudflare WAN 场景）。

这里容易产生的误读是：既然公网无法直接连到源站，那么能到达源站的请求就都是可信的。这个推论不成立。任何能访问该 hostname 的公网客户端，仍然是候选请求方；变的只是这些请求要先经过 Cloudflare 边缘。所以真正的判定点是边缘放行了什么，而不是私网地址隐藏了什么。

把“网络不可达”当作“身份已认证”，是从公网源站迁移到私网源站时最常见的一步错位。

二、三条边界分别划在哪里#

网络边界：连接方式与回程路由

公告列出的私有连接方式包括 IPsec、GRE、CNI、Cloudflare Tunnel 和 Cloudflare Mesh。使用 Cloudflare WAN 或 Mesh 时，需要在私网侧为 Cloudflare 的源地址段配置返回路由：IPv4 为 100.64.0.0/12，IPv6 为 2606:4700:cf1:5000::/64。

公告特别提到，beta 期间最常见的配置失败是请求超时且源站收不到任何东西——原因通常是缺少这条返回路由。这说明回程路由不是可选的运维细节，而是信任链的一环：私有网络必须主动允许来自这些地址段的回程流量，双向通路成立，这条链路才算划好。

另一条配置面的事实值得注意：对 RFC 1918 私网 IPv4、RFC 6598 CGNAT 段（100.64.0.0/10）和 RFC 4193 唯一本地 IPv6（fc00::/7），私网路由会自动启用，且无法关闭，通过 API 尝试关闭会返回错误。这意味着只要某条代理记录的 content 落在这些段内，它就会被当作私网目的地处理。对多环境共用一个 zone 的团队，这是一条需要在变更评审里显式确认的隐含假设。

边缘边界：WAF、限流、Bot 管理与规则

公告说明，TLS 终止、WAF、规则和缓存继续在 Cloudflare 网络上运行，现有 WAF、缓存、Bot 管理配置对该 hostname 直接生效，无需额外改动。同时，公告明确源站保持私网 IP、TLS 在边缘终止。

推论（非公告原文）：源站收到的是来自边缘一侧的连接，源站自身不再面对原始客户端。因此 WAF 和限流属于策略过滤层，不是身份认证层。它们能降低无效流量与已知攻击模式的到达率，但不能替代源站对“这个请求代表谁”的判断。把授权逻辑寄托在“只有边缘能连进来”上，一旦边缘规则出现绕过或配置漂移，源站就没有第二道判断。

应用边界：源站仍须自行认证与授权

这是三条边界里唯一不能外包给 CDN 的一层。公告没有说明源站可以用什么机制校验“请求确实来自 Cloudflare”（例如是否存在签名头或双向 TLS），这一点待核实，需要查开发者文档确认后再落地。在确认之前，合理的默认做法是：源站保留自身的认证、会话校验和按资源的授权判断，不因链路私有化而放宽。

三、缓存把数据边界整体前移了#

缓存是这套架构里最容易被低估的一项。公告把 Caching 与 Transform/rewrite rules 列为对私网源站同样可用的能力。理解它需要抓住两点：

• 缓存命中时请求不到源站。WAF 规则变更和缓存失效是两条独立的生效路径，改完 WAF 就以为内容已更新，是常见误判。
• 私网数据现在会存放在公网边缘。这是数据驻留边界的变化，不只是性能优化。哪些响应允许进入共享缓存、缓存键包含哪些维度（Host、Cookie、Vary 等）、过期与清除策略，需要按数据敏感度重新过一遍，而不是沿用公网源站时期的配置。

公告没有给出缓存键的具体行为细节，涉及多租户或按用户区分的接口时，这一项应在正式切换前单独验证。

四、一个可执行的划分顺序#

1. 先定应用层。列出该 hostname 上每个端点的认证方式与授权模型，确认链路私有化后不放宽任何一条。
2. 再定网络层。确认私有连接类型；若用 WAN 或 Mesh，先把返回路由配好并用一条低风险路径验证双向连通，再谈策略。
3. 然后定边缘层。梳理现有 WAF、限流、Bot 管理规则对该 hostname 的实际作用，明确哪些是过滤、哪些是阻断，并记录规则变更的生效方式。
4. 最后定缓存层。按数据敏感度决定可缓存范围与缓存键，明确失效路径与责任人。

公告给出的 API 形态是把私网路由作为 DNS 记录上的一个属性（private_routing）。下面是公告中的请求示例，未实际执行，仅用于说明字段位置；域名与地址为演示占位：

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

公告解释，代理平台会查询 Origin API 获取目的地元数据，看到 private_routing 为真时不再尝试经公网直连该私网地址，而是交给私有网络层，经客户已有的 IPsec、GRE、Tunnel、CNI 或 Mesh 转发。

五、边界条件与待核实项#

公告明确列出的限制：Argo Smart Routing 与 Dedicated CDN Egress IPs 不支持；源站健康检查需要配合 Load Balancing。启用前还需要账户具备 Private Origins 权益、已建立 Cloudflare One 连接，并开启 Unified Routing（使用 Cloudflare Tunnel 接入时不需要）。权益申请与 Unified Routing 升级均需通过账户团队办理，具体可用性与计费待核实。

公告提到下一步是私有到私有流量，目标在 2027 年初进入封闭 beta。这是计划而非承诺，时间点应以届时的官方说明为准。

综合来看，这套能力解决的是“私网应用如何获得与公网应用同等的边缘防护”，它并没有、也不应该顺带解决“请求方是否有权访问”。把这两件事分开，信任边界才算划清楚。