私网回源 GA 之后：私有源站如何同时接入 WAF、缓存与边缘计算

先给结论：这次 GA 改变的是「源站还能不能藏起来」这个问题。按 Cloudflare 的公告摘要，公网流量现在可以打到私有源站，同时在边缘叠上 WAF、bot 管理、缓存和 Workers，并且对所有具备 Cloudflare One 连接性的客户开放。也就是说，私有源站不必为了获得边缘防护而暴露公网入口。

但「能接」和「接得对」是两件事。WAF、缓存、边缘计算三者的生效位置都在边缘，它们对同一条请求的判断依据却各不相同，冲突往往出在源站看不见的部分。下面按链路、单项前提、上线顺序和边界展开。

链路先摆清楚#

按公告描述，请求路径大致是：客户端 → Cloudflare 边缘（WAF、bot 管理、缓存、Workers 在这里执行）→ 私有连接 → 源站。源站侧不发布公网入口，只接受来自私有连接的网络流量。

需要说明：上述顺序是根据公告摘要与通用代理架构做的推断，公告摘要只列出了四项能力与前提条件，没有给出具体的组件名称、配置项和流量路径细节。真实拓扑请以官方文档为准。

# 示意：源站入站约束思路（未执行，仅表达方向，不是可直接使用的配置）
# 只接受来自私有连接侧的流量，其余拒绝
allow 10.0.0.0/8;   # 占位网段，非真实配置
deny  all;

这段不是可运行的配置，只是提醒一件事：源站藏起来之后，仍然要自己保证「除了私有连接，谁也进不来」。否则边缘那一层就成了可绕过的装饰。

WAF：位置变了，判断依据也得跟着变#

WAF 在边缘执行，源站不参与检测，这是私有回源最直接的好处——攻击流量在到达源站之前就被处理掉了。但由此带来两个必须处理的问题。

真实客户端信息要传递下去

源站看到的连接来源是代理或连接器，不是终端用户。如果源站日志、业务限流、风控规则继续按 TCP 源地址判断，结果就是所有用户被当成同一个来源：限流会误伤全体，风控会失效，日志也失去排查价值。常见做法是读取边缘传递的转发头，在源站统一解析成真实客户端地址。

具体用哪个头、是否有多级代理、如何防止伪造，取决于边缘产品的实现，公告摘要未涉及，待核实。原则是：只信任来自私有连接的转发头，对公网直连的请求一律不认。

拦截策略需要一段观察期

WAF 规则在边缘生效意味着误拦截的后果更直接：请求根本到不了源站，源站日志里连痕迹都没有。建议先以观察模式跑一段时间，比对「规则认为可疑」和「业务上确实异常」这两个集合的差异，再逐条转成拦截。这一步没有捷径，只能靠自己的流量。

缓存：先回答「这份响应能不能共享」#

缓存是三者中最容易出事故的一项，因为它改变的不是安全检查，而是「谁拿到谁的内容」。

实际操作里有三件事要定下来：

• 缓存键包含哪些维度。至少覆盖主机名与路径；如果同一路径会因语言、租户、设备类型返回不同内容，这些维度必须进键，否则就是互相覆盖。
• 哪些请求可以命中缓存。带 Authorization 或会话 Cookie 的请求默认应绕过共享缓存，除非你明确知道该响应与身份无关。
• 回源时带什么头。边缘回源和用户直连源站不是一回事，源站若按 Host 或来源头做路由，需要确认回源请求里这些值是否符合预期。

公告摘要提到缓存能力随私有源站一起可用，但没有说明默认缓存行为、是否对私有源站有额外限制，这部分待核实。保守做法是默认不缓存，按路径逐段放开。

边缘计算：放在请求路径上，就要算清代价#

Workers 这类边缘脚本在回源之前执行，天然适合做几类轻量工作：鉴权前置（无效请求不必回源）、路径与头部改写、缓存键规范化、灰度分流、响应头修正。

不适合做的事同样明确：

• 不要把长期密钥写进边缘脚本。边缘代码的分发范围比源站大，密钥应放在可轮换的密钥管理里，脚本只引用。
• 不要把边缘当作唯一的安全边界。源站仍需校验输入与权限，边缘是减少攻击面，不是替代源站判断。
• 不要在请求路径上堆重逻辑。边缘每多一次子请求，链路就多一段超时预算；边缘超时会直接表现为用户侧失败，而源站对此一无所知。

脚本的子请求数量上限、CPU 时间上限、以及私有回源场景下这些限制是否不同，公告摘要未提及，待核实。设计时应假设限制存在，把逻辑拆到能降级的粒度。

建议的上线顺序#

1. 先打通私有连接，并把源站入站收紧。确认只有连接器流量能到源站，其余全部拒绝。这一步做完之前，不要开任何边缘功能。
2. 只放最小改写，先观测。用边缘脚本透传请求，记录真实客户端地址、状态码分布、回源耗时。此时没有任何拦截和缓存，目的是拿到基线。
3. WAF 观察模式。收集规则命中情况，逐条评估后再转拦截。bot 管理同理。
4. 缓存从静态资源开始。按路径前缀放开，观察命中率与回源量变化，再考虑扩到公开只读接口。
5. 每一步都留回滚开关。边缘配置的回滚通常比源站发布快，但这不代表可以省掉验证。

这个顺序是建议，不是实测流程；本文没有在真实环境执行过上述步骤，也没有性能数据。第 2 步的基线与第 4 步的命中率变化，需要在你们自己的流量上测。

边界与待核实项#

公告摘要能确认的事实只有这些：私有源站服务 GA；公网流量可以到达私有源站；WAF、bot 管理、缓存、Workers 在这条链路上可用；前提是 Cloudflare One 连接性。以下内容摘要里没有，需要查官方文档或实测确认：

• 各能力对应的套餐层级与用量计费方式；
• 私有源站场景下的缓存默认行为与可配置范围；
• 边缘脚本的子请求、执行时间与内存上限；
• 私有连接本身的带宽、并发与可用性指标；
• 源站健康检查的探测路径与失败判定；
• 源站证书校验方式与自定义证书的支持情况。

把这些列出来的意义不是唱衰，而是提醒：GA 说明功能可用，不说明它在你这条链路上没有额外约束。私有回源把「源站暴露」这个问题解决了，同时把「源站看不见用户」这个问题交给了你。真实客户端信息、缓存共享边界、边缘脚本的职责范围，这三件事想清楚了，WAF、缓存和边缘计算才能同时成立，而不是互相拆台。

来源：Cloudflare services for private origins is now generally available（本文仅依据该文标题与摘要写作，未读全文）。