私网源站接入公网流量：Cloudflare private origins 的信任边界与六组验收项

如果你的内部 API、MCP 服务或运维工具本来就不该暴露在公网，但又必须接受合作伙伴或外部代理的请求，这次变更值得看：Cloudflare 在 2026 年 10 月 30 日宣布 services for private origins 正式可用。做法是把一条 proxied A/AAAA 记录指向私网 IP，Cloudflare 通过你已有的 Cloudflare One 连接回源，源站不需要公网 IP，也不需要开入站防火墙端口（Cloudflare Blog）。

需要先说清楚的边界：“源站保持私有”描述的是边缘到源站这一段，不是整条链路。客户端仍然从公网访问你的主机名，TLS 终止、WAF、规则与缓存仍然在 Cloudflare 网络上执行。真正的变化是：过去你必须把源站 IP 交出去，现在交付给公网的是 DNS 记录与一条私网连接。

信任边界从“源站 IP”移到“DNS 记录 + 连接”#

按官方描述拆开请求路径，可以分成四段，每段的信任假设不同：

• 客户端到 Cloudflare 边缘：公网可达，与代理任何公网源站没有区别。WAF、托管规则、Bot management、速率限制在这一层生效。
• 边缘内部：TLS 终止、规则匹配、缓存命中判断都在这里。缓存命中的请求不会到达源站，这意味着你在源站侧看到的流量天然少于边缘统计。
• 边缘到源站：这是新增的一段。代理平台不直接连私网 IP，而是先查 Cloudflare 的 Origin API，拿到带 private_routing: true 的响应后，把请求交给私有网络层，再由 IPsec、GRE、Cloudflare Tunnel、CNI 或 Cloudflare Mesh 送达（同上来源）。
• 源站：看到的请求来源与协议行为取决于你的连接方式，需要在你自己的网络策略里单独确认。

由此可以推出一个常见的误解：把源站藏进私网，并不自动等于“只有授权方访问”。公网主机名依旧是入口，访问控制仍要靠 WAF 规则、Access 策略或源站自身的鉴权来建立。私网化解决的是源站地址暴露与入站端口开放，不解决谁能访问。

API 上只多一个属性#

对用 API 做部署自动化的团队，这个能力的接入成本很低——private routing 就是标准 DNS 记录上的一个附加字段。下面是按官方博文给出的示例，未在本环境执行，仅用于说明字段位置：

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 得到的响应形如（同样来自博文示例，未执行）：

{
  "zone_name": "example.com",
  "ipv4_addresses": ["10.0.0.50"],
  "private_routing": true
}

其中 10.0.0.50 与 app.example.com 都应视为占位值，替换成你自己的地址与域名。private_routing 是关键信号：边缘看到它，就不走公网直连，改交私有网络层。

自动开启的地址段与无法关闭的行为

官方说明，以下范围的私网记录会自动启用该设置，且无法关闭，通过 API 尝试关闭会返回错误：

• RFC 1918 私网 IPv4
• RFC 6598 CGNAT 地址 100.64.0.0/10
• RFC 4193 唯一本地 IPv6 地址 fc00::/7

如果你的源站用的是公网 IP、但只能经由私网抵达，则需要手动打开这个开关。这条差异在自动化脚本里容易被忽略：同一套模板，对 RFC 1918 地址是隐式生效，对公网 IP 则必须显式传参，漏了就变成直连公网。

上线前的六组验收项#

下面按依赖顺序排列，前一项不成立时后面的验证没有意义：

第 4 项值得单独强调。博文明确提到，封闭测试期间最常见的配置失败就是缺少返回路由，症状是请求超时、源站什么都收不到。排查顺序因此应该是先看回程，而不是先改 WAF 规则或缓存设置。

一个需要你自己核实地址规划的风险

此处给出的是推断，不是官方结论：自动启用范围里的 CGNAT 段是 100.64.0.0/10，而 WAN/Mesh 场景要求指向 Cloudflare 的返回路由是 100.64.0.0/12，两者存在重叠。如果你的源站恰好被规划在 100.64.0.0/12 之内，回程路由与源站地址可能互相干扰。这类冲突的性质取决于你实际的路由表与连接类型，建议在地址规划阶段就避开该段，或向官方支持确认，不要仅凭本文推断做决定。

已知限制与不确定项#

• Argo Smart Routing 与 Dedicated CDN Egress IPs 不支持。依赖固定出口 IP 做源站白名单的方案，需要重新设计。
• 源站健康检查需要 Load Balancing。没有该产品时，不要指望平台替你判断源站存活。
• 完整限制清单以开发者文档为准。博文只说“见文档”，具体条目本文无法代述，待核实。
• private-to-private 流量尚未发布。官方称正在开发，目标是 2027 年初进入封闭测试；参与方式需联系客户团队。这属于计划，不是可用能力。

与“在源站旁边跑 cloudflared”的区别

博文提到，此前要让 Cloudflare 挡在私网服务前面，通常要暴露公网 IP、开防火墙端口，或在源站旁运行 cloudflared。用现在的路径，Cloudflare WAN 场景下源站不需要任何连接器软件；Cloudflare Mesh 场景下连接器运行在私网内，一个连接器可服务多个源站。差别在于运维边界：前者在每台源站上多一个进程要管，后者把连接点收敛到网络层，但代价是你必须把返回路由配对。

收尾#

这个能力把“源站不能碰公网”和“需要接受公网请求”这两个约束拆开了，但它没有替你做访问控制，也没有消除公网入口。落地时最值得投入的三件事是：确认 entitlement 与连接类型、把返回路由当成第一排查项、以及在地址规划阶段核对 CGNAT 段是否与 Cloudflare 源段冲突。至于完整限制清单与后续 private-to-private 的时间表，以官方开发者文档与客户团队答复为准。