公开流量打到私有源站：WAF、机器人与缓存该放在信任边界哪一侧
私有源站改变的是回源路径，不是防护位置：WAF、机器人管理、限流、缓存与 Workers 仍应放在 Cloudflare 边缘一侧，源站保持私有 IP、不开入站端口。文章说明这种划分的依据、缓存需要单独设规则的原因、DNS 与 private_routing 的配置顺序，以及返回路由缺失这一最常见故障点。
- “私有源站”指的是回源路径私有，不是指没有公网入口；DNS 记录照常公开解析。
- WAF、机器人管理、限流、缓存放在边缘一侧，源站一侧只保留“不接受公网入站”这一条。
- 缓存命中意味着请求不进私网，因此缓存键与 Cache-Control 必须先于上线确定。
- 私有网段路由自动开启且不可关闭；返回路由缺失是最常见的超时原因，应优先排查。
先给结论#
放在边缘一侧，也就是信任边界之外。Cloudflare 在 2026 年 10 月 30 日把面向私有源站的应用服务开放为普遍可用（GA），其核心变化是回源路径：代理 DNS 记录可以指向私有 IP，Cloudflare 通过你已有的 Cloudflare One 连接抵达源站，源站不必暴露公网 IP、不必开入站防火墙端口（Cloudflare Blog）。WAF、机器人管理、限流、缓存与 Workers 的位置没有变，仍在 Cloudflare 网络上执行。
换句话说，“私有”描述的是请求怎么到达源站，不是请求在哪里被检查。把这两件事混为一谈，是这类改造里最容易出错的地方。
三种“私有”要拆开看#
讨论信任边界前，先区分三个常被合并的概念：
- 私有地址：源站使用 RFC 1918、RFC 6598（100.64.0.0/10）或 RFC 4193（fc00::/7）地址。这些网段无法从公网直接路由到达。
- 私有可达：只有你控制的网络路径能抵达源站，路径可能是 IPsec、GRE、CNI、Cloudflare Tunnel 或 Cloudflare Mesh。
- 私有保护：源站不接受未经过滤的公网入站流量。
新能力解决的是前两项。第三项取决于你把检查点放在哪：如果 WAF 与机器人管理在边缘执行，源站只接收已经过检查的请求，第三项才成立；如果为了“私有”而在私网里另建一套检查，等于把边界挪到了源站门口，公网流量已经穿过了你的网络边界。
边界两侧各放什么#
| 位置 | 承担 | 不承担 |
|---|---|---|
| Cloudflare 边缘（信任边界外侧） | TLS 终止、WAF 与托管规则、机器人管理、限流、缓存、重写与转换规则、Workers | 业务鉴权、数据归属判断 |
| 你的私有网络（边界内侧） | 源站、私有 IP、连接器或网关、回程路由 | 面向公网的流量清洗 |
这个划分的依据是：请求在到达源站之前就已经在边缘完成了检查与缓存判断。据官方博客，旧做法要么暴露公网 IP、要么开防火墙端口、要么在源站旁运行 cloudflared，结果是这些内部 API、AI agent 后端、MCP 服务器与运维工具拿不到公网应用那套 WAF、机器人管理、限流与缓存。新做法把保护层留在原处，只把“最后一跳”换成私有路径。
值得注意的是源站侧的要求也不同：使用 Cloudflare WAN 时，源站上不需要安装连接器软件；使用 Cloudflare Mesh 时，连接器运行在你的私有网络内，一个连接器可以服务多个源站。
缓存为什么必须单独讨论#
WAF 和机器人管理是“检查”，缓存是“代替源站回答”。缓存命中时，请求根本不会进入私有网络，这是性能收益，也是风险来源：
- 缓存是否发生由响应头与缓存规则决定，与源站是否私有无关。指向私有 IP 的记录不会自动让响应变得不可缓存。
- 对带鉴权、按用户区分内容的接口，必须显式设置
Cache-Control: no-store（或等效策略），或让缓存键包含区分维度。否则边缘缓存会绕过后端判断。 - 对真正公开、可共享的响应（静态资源、公共配置、图片），缓存放在边缘是正确的：它减少了穿越私有网络与连接器的流量，也降低了源站负载。
实践上可以按主机名或路径分段：公开可缓存的路由启用缓存，涉及身份与状态的路由明确关闭。这一步应当在切换 DNS 之前完成，而不是上线后再补。
配置顺序#
以下步骤依据官方博客整理，具体界面与字段以开发者文档为准。
- 开通权益：账户需要 Private Origins 权益，需联系账户团队开启。
- 建立连接：通过 IPsec、GRE、CNI、Cloudflare Tunnel 或 Cloudflare Mesh 建立 Cloudflare One 连接。
- 检查路由前提：账户需启用 Unified Routing；使用 Cloudflare Tunnel 接入时不需要。
- 配置回程路由（WAN 或 Mesh 接入时）：为 Cloudflare 源地址段
100.64.0.0/12（IPv4）与2606:4700:cf1:5000::/64（IPv6）配置返回路由。 - 创建代理记录：指向私有 IP 的 A 或 AAAA 记录，确认“使用私有网络路由”已开启。
- 复用现有策略：已有 WAF、缓存、机器人管理配置对该主机名直接生效，无需另建。
私有网段的路由开关行为需要注意：对 RFC 1918、RFC 6598 与 RFC 4193 地址，该设置自动开启且无法关闭，通过 API 尝试关闭会返回错误。只有“公网 IP 但仅能经私有网络到达”的情况才需要手动开启。
API 侧的表现（示例未执行）
下面两段 JSON 来自官方博客的字段说明，这里作为结构示例展示，未实际调用验证，域名与地址均为演示值：
POST /zones/{zone_id}/dns_records
{
"type": "A",
"name": "app.example.com",
"content": "10.0.0.50",
"ttl": 300,
"proxied": true,
"private_routing": true
}代理平台在决定把流量发往何处时，会查询源站信息接口，返回中携带私有路由标记：
{
"zone_name": "example.com",
"ipv4_addresses": ["10.0.0.50"],
"private_routing": true
}对自动化部署来说，这只是标准 DNS 记录上的一个附加属性，不需要新的资源类型；差异在于代理层看到该标记后，不再尝试经公网直连私有地址，而是把连接交给私有网络层。
已知限制与排错顺序#
官方明确列出仍然存在的限制：Argo Smart Routing 与 Dedicated CDN Egress IPs 不受支持；源站健康检查需要配合 Load Balancing 使用。完整清单以其开发者文档为准。
排错上有一条经验值得先记住：如果请求超时且源站没有收到任何流量，先查返回路由。博客提到，缺少 Cloudflare 源地址段的路由是测试期最常见的配置失败。把这条放在排查链的第一位，比逐个检查 WAF 规则更省时间。
还需要核实与尚未覆盖的部分#
以下几点在本次材料中没有给出，不宜当作已知结论：
- 价格与配额：该能力的计费方式、缓存与 Workers 的额度边界，材料未说明，待核实。
- 可用区域与合规限制：是否在所有区域提供、是否有行业限制，待核实。
- 私有到私有流量：目前发布的是“公网流量到私有源站”。私有网络之间经 Cloudflare 应用服务的互通仍在开发中，官方称目标是在 2027 年初开启封闭测试，尚未可用。
此外，接入方式的选择会影响源站侧改动量：WAN 与 Mesh 需要在网络上配置回程路由，Tunnel 不需要 Unified Routing，但这些差异不影响“保护层放在边缘”这一结论。
回到标题的问题#
私有源站把“可达性”收紧，把“保护”留在原处。WAF、机器人管理与缓存放在信任边界外侧，源站只是不再接受公网入站——两者是互补而非替代。真正需要单独设计的是缓存：它是唯一一个可能让请求完全不进入私网的环节，也因此最需要在上线前明确哪些响应可以共享、哪些必须逐次回源。
对对外提供 API 的服务方而言，这个模型的价值在于：内部接口不必为了“能被外部调用”而先变成公网资产，检查与限流仍在统一的一层完成。至于权益如何开通、额度如何计算，仍应与服务方账户团队确认后再定方案。
常见问题（FAQ）
私有源站是否等于没有公网入口？
缓存放在边缘会不会把私有内容缓存出去？
请求超时但源站没收到任何东西，先查什么？
参考来源
以上为本文写作时的参考资料，引用观点以原文为准。
