私有源站接上公网流量后：WAF、缓存与 Workers 的职责边界怎么划

私有源站接上公网流量之后，最容易被混淆的一件事是：谁还在做安全判断，谁只是把包送到。Cloudflare 在 2026 年 10 月 30 日宣布 private origins 正式可用，给出的分工是——把一条代理 DNS 记录指向私有 IP，Cloudflare 通过客户已有的 Cloudflare One 连接抵达源站，而 WAF、缓存、Bot 管理与 Workers 的表现与公网源站一致（Cloudflare Blog，2026-10-30）。换句话说，源站退出公网，但边缘那一层没有退出。

请求会经过哪几段#

按来源博客的描述，请求仍然先落到 Cloudflare 网络，TLS 终止、WAF、规则与缓存继续在这里执行；代理平台在决定往哪送时，会查询 Origin API，返回结果里的 private_routing 是信号位——看到它为真，代理不再尝试从公网直连那个私有地址，而是把连接交给私有网络层，由后者跨客户既有的 IPsec、GRE、CNI、Cloudflare Tunnel 或 Cloudflare Mesh 送达源站。

于是链路可以拆成三段，职责各不相同：

• 边缘代理：终止 TLS、跑 WAF 与托管规则、执行转换与重写规则、决定缓存命中与否、承载 Workers、做 Bot 管理与限流。
• 私有网络层：只回答"这个请求怎么走到那个 IP"。它不解析业务语义，也不替代源站做授权。
• 源站：仍然持有最终裁决权——身份、权限、数据边界、业务状态机都在这里。

三者的职责切分#

需要强调的是最后一行。来源博客列举的典型场景是内部 API、AI 代理后端、MCP 服务器与运维工具——这些服务"并非为面向互联网而构建"，但仍然需要接受来自合作伙伴、客户或代理的公网请求。这句话恰好说明：私有性是网络拓扑属性，不是请求方身份属性。把 WAF 放在前面能挡掉一批流量，但它不等于应用层授权。

既有配置会原样套用，这既是便利也是风险#

来源博客写明，既有的 WAF、缓存与 Bot 管理配置"无需进一步改动"即对该主机名生效。对迁移来说这是省事的部分；反过来说，一套原本为公网静态站点调好的缓存规则，套到一个返回个性化数据的内部 API 主机名上，行为需要重新复核。缓存是否命中取决于缓存键与响应头，与源站地址是否私有无关——这条判断应在上线前用响应头实测确认，而不是假定。本次材料没有给出缓存键的具体构成规则，此处不作展开。

配置：一条 DNS 记录加一个标志位#

对用 API 做自动化部署的团队，私有路由只是标准 DNS 记录上的一个附加属性。下列请求体照录来源博客，未执行，仅用于说明字段结构；实际调用需替换 zone_id 与地址：

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

对 RFC 1918 私有 IPv4、RFC 6598 CGNAT 段（100.64.0.0/10）与 RFC 4193 唯一本地 IPv6（fc00::/7），私有路由会自动启用，且无法关闭——素材明确说明通过 API 尝试关闭会返回错误。如果源站使用的是一个只能经私有网络抵达的公网 IP，则需要手动打开该设置。

前置条件按来源博客整理如下：

1. 账户具备 Private Origins 权益，需向客户团队申请开通。
2. 已通过 IPsec、GRE、CNI、Cloudflare Tunnel 或 Cloudflare Mesh 建立 Cloudflare One 连接。
3. 账户已启用 Unified Routing；使用 Cloudflare Tunnel 接入的除外。
4. 若经 Cloudflare WAN 或 Cloudflare Mesh 接入，为 Cloudflare 源地址段配置返回路由：IPv4 为 100.64.0.0/12，IPv6 为 2606:4700:cf1:5000::/64。
5. 创建指向私有 IP 的代理 A 或 AAAA 记录，并确认"Use private network routing"已开启。

第 4 步里有一个容易看错的细节：返回路由用的 100.64.0.0/12，与自动启用私有路由的 CGNAT 段 100.64.0.0/10 并不是同一个前缀，前者更窄。两者用途不同，不能互相替代。

已知限制与第一个排障点#

来源博客列出了当前不支持的能力：Argo Smart Routing 与 Dedicated CDN Egress IPs 不在支持范围；源站健康检查需要 Load Balancing 才能使用。完整限制列表需查阅开发者文档，本次材料未给出该页面的具体地址，因此不对其余条目做补充。这两条对架构有实际影响：依赖 Argo 做回源加速的预期需要重新评估；而习惯用固定出口 IP 在源站做白名单的团队，要另找识别手段。

排障方面，素材给了一条来自内测的经验：如果请求超时且源站什么都没收到，先查返回路由——缺少 Cloudflare 源地址段的返回路由，是内测期间最常见的配置失败。

源站 IP 保持私有，无需开放入站防火墙端口；用 Cloudflare WAN 接入时源站不需要安装连接器软件；用 Cloudflare Mesh 接入时，连接器运行在私有网络内，可服务多个源站。

落地时的核对顺序#

• 先确认权益与连接类型，再决定是否需要 Unified Routing 与返回路由。
• 把既有 WAF、缓存、Bot 管理规则逐条过一遍，重点看缓存规则对动态响应的影响。
• 明确 Workers 承担什么、不承担什么；顺序与能力边界以开发者文档为准，本文未核实。
• 不要把"私有 IP"当作鉴权替代品，源站的身份与权限校验保持原样。
• 对 Argo 与固定出口 IP 有依赖的设计，在迁移前重新评估。

来源博客还提到下一步方向：从公网到私有源站之后，正在做私有到私有的流量，即私有网络中的用户、服务与 AI 代理经由 Cloudflare 应用服务访问另一个私有网络中的应用，目标在 2027 年初进入封闭内测。这部分属于路线图陈述，可用性与时间点以官方后续公告为准。