Cloudflare 私网源站 GA：公网流量进入私网源站，信任链要布置在哪四段

Cloudflare 在 2026 年 10 月 30 日宣布 services for private origins 正式可用（GA）：把一条代理的 A 或 AAAA 记录指向私网 IP，公网请求就会经客户已有的 Cloudflare One 连接抵达源站，而源站本身保持私有。按官方博客的描述，WAF、缓存、Bot 管理和 Workers 在这些源站上的工作方式与公网源站一致（来源：Cloudflare Blog，2026-10-30）。

换句话说，这套能力换掉的不是“入口在哪”，而是“入口凭什么被信任”。源站不再靠公网 IP 和防火墙端口证明自己可被访问，改由 DNS 记录上的代理标志、Cloudflare 网络内的策略执行、Cloudflare One 私网连接的回程路由三者共同构成一条可核对的路径。任何一段没配好，请求就停在半路，而源站侧往往看不出原因。

它实际替代了哪几种做法#

博客把此前的前置条件列得很直白：要让内部 API、AI agent 后端、MCP 服务器或运维工具接受来自合作方、客户或 agent 的公网请求，通常得暴露公网 IP、在防火墙上开端口，或者在源站旁跑 cloudflared。这三种做法都会让这些“本不是为公网而生”的服务，失去与公网应用同等的 WAF、Bot 管理、限流、缓存、改写和 Workers 能力。

新版路径是：源站保留私网 IP，无需入站防火墙例外。用 Cloudflare WAN 接入时，源站上不需要安装 connector 软件；用 Cloudflare Mesh 接入时，connector 运行在你的私网内，一个 connector 可以服务多个源站。这些差异会影响你如何划分故障域，后面单独说。

信任链的四段，逐段核对#

第一段：DNS 记录与 private_routing 标志

入口是标准 DNS 记录上的一个附加属性。博客说明，对于 RFC 1918 私有 IPv4、RFC 6598 CGNAT 地址（100.64.0.0/10）和 RFC 4193 唯一本地 IPv6 地址（fc00::/7），私网路由会自动开启，且无法关闭——通过 API 尝试关闭会返回错误。如果源站用的是“只能经私网访问的公网 IP”，则需要手动开启该设置。

这一段值得留意的是不可逆性：地址落在上述范围内时，你无法把这条记录改回“直连公网”的语义。若同一区域里既有真公网源站、也有私网源站，最好在命名和记录管理上先分开。

第二段：Cloudflare 网络内的应用服务

博客称请求流的其余部分不变：TLS 终止、WAF、规则和缓存在 Cloudflare 网络上继续执行。这意味着策略层的位置没有变化，变化的是“回源”这一步的去向。不过博客只说了 TLS 在 Cloudflare 网络终止，没有说明 Cloudflare 到私网源站这一段是否默认加密、是否支持源站证书校验或双向 TLS。这部分属于信任链的关键细节，应以开发者文档为准，本文材料不足以给出结论。

第三段：Cloudflare One 连接

代理平台并不是直接去连私网 IP。按博客描述，它会查询 Cloudflare 的 Origin API，返回结果里带 private_routing: true 标记；看到这个标记后，代理把请求交给私网网络层，由后者跨客户已有的私网连接转发——IPsec、GRE、Cloudflare Tunnel、CNI 或 Cloudflare Mesh 均可。

所以第三段的信任建立在“你已经运营的连接”上，而不是新建一条。接入方式的选择会直接决定排障顺序：Tunnel 不需要 Unified Routing，其他方式需要；WAN 不需要源站侧软件，Mesh 需要。

第四段：回程路由与源站侧

这是最容易被忽略、也最常出问题的一段。博客明确要求：用 Cloudflare WAN 或 Cloudflare Mesh 接入时，需要为 Cloudflare 的源地址段配置返回路由——IPv4 为 100.64.0.0/12，IPv6 为 2606:4700:cf1:5000::/64。

博客给出的测试阶段经验：如果请求超时且源站什么都没收到，先查回程路由。缺少指向 Cloudflare 源地址段的路由，是他们见到的最常见配置失败。

这一点在排障上很有价值：症状出现在“请求没到源站”，而根因在“回包没有回去的路径”。只盯源站日志会一直看不到线索。

前置条件清单#

API 形态：只是多了一个属性#

对用 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
}

博客同时给出了 Origin API 侧的响应形态，用于说明代理平台如何判断去向（同样是示例，未执行）：

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

关键信号就是 private_routing。它把“这条记录指向哪里”和“这条记录该怎么到达”拆成了两件事，也让审计变得简单：查一条记录是否走私网，看这个字段即可。但要注意，博客没有说明该字段在 Terraform 等工具中的对应参数名与版本要求，这部分待核实。

边界：哪些能力仍然缺席#

• Argo Smart Routing 不支持。依赖智能路由做跨地域加速的团队，需要重新评估这条链路上的时延预期。
• Dedicated CDN Egress IPs 不支持。以下游白名单依赖固定出口 IP 的场景，不能直接沿用。
• 源站健康检查需要 Load Balancing。不能用健康检查做源站探活的自动化。
• 私网到私网流量还不在此次范围内。博客称该方向仍在开发，目标 2027 年初进入封闭测试，需要向客户团队申请。

博客提到“完整限制清单见开发者文档”，但材料中未给出该文档的具体地址，本文不代为补全。

什么时候先别急着切#

如果源站的可用性判断依赖固定的 CDN 出口 IP 做下游白名单，或者关键路径上依赖 Argo Smart Routing，这套方案当前的限制会直接削掉你已有的能力，切换前需要先确认替代方案。反过来，若痛点是“内部服务不该有公网入口，但又必须接受外部请求”，且已有 Cloudflare One 连接与统一路由，那么这次 GA 大致相当于把已有的 WAF、缓存与 Bot 管理配置延伸到这些主机名上——博客的说法是现有配置无需改动即可生效。

另有一条口径需要自己核实：博客摘要称该能力已向所有具备 Cloudflare One 连接的客户开放，而正文的“Get started”仍要求账户具备 Private Origins entitlement 并向客户团队申请。两者是否指同一件事、权益是否已默认下发，材料里没有说明。动手之前，先确认账户状态比先改 DNS 更省时间。

下一步：私网到私网#

按博客的规划，今天这版覆盖的是“公网流量到私网源站”。下一阶段是私网到私网：私网上的用户、服务和 AI agent 经由 Cloudflare 的应用服务访问其他私网中的应用，比如员工打开 wiki.company.internal 时同样受 WAF、限流和 Bot 管理约束，跨云、跨数据中心的服务间流量也可以套用这些控制，即使两端都不碰公网。工程在进行中，目标 2027 年初封闭测试。