Cloudflare 私有源站服务 GA：公网入口与私有后端的边界设计

私有源站要接受公网请求，不等于把源站 IP 暴露到公网。Cloudflare 在 2026 年 10 月 30 日的发布说明中宣布，Cloudflare services for private origins 已一般可用（GA）：把代理 DNS 记录指向私有 IP，Cloudflare 通过客户已有的 Cloudflare One 连接回源，源站保持私有，WAF、缓存、Bot 管理和 Workers 仍按公共源站的方式工作。Cloudflare 的发布说明

对开发者来说，这意味着公网入口与私有后端之间多了一条由 DNS 路由声明驱动的私网回源路径。边界设计要分别回答：入口如何声明，连接与返回路由如何通，边缘策略覆盖什么，源站自己还负责什么。

这次 GA 覆盖什么，不覆盖什么#

据同一发布说明，GA 面向具备 Cloudflare One 连接的客户。支持 WAF（Web Application Firewall，Web 应用防火墙）和托管规则、Bot 管理、速率限制、缓存、转换/重写规则、Workers。源站保留私有 IP，不需要入站防火墙例外；Cloudflare WAN 不需要在源站安装连接器，Cloudflare Mesh 的连接器运行在私有网络内，可服务多个源站。

限制要先写进设计：Argo Smart Routing 和 Dedicated CDN Egress IPs 不支持，源站健康检查需要 Load Balancing。发布说明把完整限制清单指向开发文档，本次材料没有给出该清单，部署前应自行核对。发布说明还称，private-to-private 流量仍在开发，目标是在 2027 年初开启 closed beta；当前 GA 覆盖的是公网到私有源站，不能把未来能力当成现在可用。

边界一：DNS 记录是入口声明，不是访问控制#

做法是创建 proxied A 或 AAAA 记录指向私有 IP。对 RFC 1918 私有 IPv4、RFC 6598 CGNAT 地址（100.64.0.0/10）、RFC 4193 唯一本地 IPv6 地址（fc00::/7），private network routing 会自动开启，且不能关闭；通过 API 尝试禁用会报错。若源站使用只能经私有网络到达的公网 IP，才需要手动开启。

这说明 private_routing 首先是路由属性：代理平台看到它，就把请求交给私有网络层，而不是从公网直接连私网 IP。它不应被当作访问控制。谁能访问、能做什么，仍要由 WAF、速率限制、应用鉴权和网络策略分别决定。建议把 DNS 记录纳入 IaC 和代码评审，对手动开启公网 IP 的场景设置审批，避免把内部地址误发布成公网入口。

边界二：连接方式与返回路由#

回源连接可以是 IPsec、GRE、CNI、Cloudflare Tunnel 或 Cloudflare Mesh。两个前置条件容易混淆：走 Cloudflare Tunnel 不需要 Unified Routing；走 Cloudflare WAN 或 Cloudflare Mesh 时，需要为 Cloudflare 的源范围配置返回路由，IPv4 是 100.64.0.0/12，IPv6 是 2606:4700:cf1:5000::/64。注意 100.64.0.0/10 是自动识别的 CGNAT 地址范围，100.64.0.0/12 是返回路由要放行的 Cloudflare 源范围，两者不是同一个前缀。

发布说明称，beta 期间最常见的设置失败是请求超时且源站什么都没收到，原因通常是缺少 Cloudflare 源范围的返回路由。排查时先看返回路由，再看 DNS 记录是否 proxied、private_routing 是否开启，最后才看源站应用日志。这个顺序能减少把网络问题误判成应用问题。

边界三：边缘策略要按私有 API 重新检查#

WAF、Bot 管理、速率限制、缓存、Workers 对私有源站生效，这是 GA 的核心价值；但“能生效”不等于“默认适合”。建议至少检查：WAF 自定义规则是否覆盖新的 hostname；速率限制的键是否区分租户或用户；缓存是否会把带身份信息的响应变成公共对象；Workers 是否处理了敏感头或密钥。缓存和 Workers 的具体行为应以官方文档和实际配置为准，本文不把未执行的测试当作结论。

另一个常见误区是把边缘防护当成应用鉴权的替代。源站仍需自己的身份校验、最小权限和审计日志。边缘层能拦住一部分恶意流量，但不能替源站判断某个令牌是否有权访问某个资源。这是设计建议，不是发布说明的承诺。

一个配置示例（未执行）#

下面 JSON 来自发布说明的示例形状，本次未执行，仅说明字段。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
}

proxied 表示走 Cloudflare 代理，private_routing 表示回源走私有网络路径。发布说明描述了代理平台查询 Origin API 的过程：响应带 private_routing 标记，代理据此把连接交给私有网络层，再经客户已有的 IPsec、GRE、Tunnel、CNI 或 Mesh 连接到达源站。示例中的 10.0.0.50 属于 RFC 1918 范围，按发布说明会自动开启私有路由；生产环境应确认它符合你的私网规划。

上线检查清单#

把下面几项分开验证，比只检查“域名能不能打开”更接近真实边界：

1. 账户是否有 Private Origins entitlement；发布说明要求联系 account team 开启。
2. 是否已有 Cloudflare One 连接：IPsec、GRE、CNI、Cloudflare Tunnel 或 Cloudflare Mesh。
3. Unified Routing 是否启用；若走 Cloudflare Tunnel，则不需要它。
4. 若走 WAN 或 Mesh，返回路由是否覆盖 Cloudflare 的 IPv4 与 IPv6 源范围。
5. DNS 记录是否 proxied，private_routing 是否开启；私网地址范围是否自动开启。
6. WAF、速率限制、缓存和 Bot 策略是否覆盖该 hostname，缓存键是否适合私有 API。
7. 源站应用鉴权、日志和告警是否独立于边缘；是否避开 Argo、Dedicated CDN Egress IPs 等不支持项。

如果请求超时且源站没有日志，按“返回路由→DNS 记录→边缘策略→源站应用”的顺序排查。发布说明把返回路由列为 beta 期间最常见的失败点，这个顺序有实际依据。

私有源站对外服务的边界，不是一条 DNS 记录，而是入口声明、私网连接、边缘策略和源站身份的组合。GA 让公网请求可以经过 Cloudflare 的应用服务到达私有后端，但限制、返回路由和源站责任仍要逐项确认。对准备把内部 API、AI agent 后端、MCP 服务器或运维工具开放给合作伙伴的团队，先把这四层写成可检查的配置，再谈上线。