Cloudflare OHTTP Gateway开启封闭测试：托管解密网关，仍需独立第三方中继
2026年10月2日，Cloudflare宣布自助式OHTTP Gateway开启封闭测试，并邀请开发者登记候补名单。产品计划作为zone的付费附加项提供；同一公告还把此前的Privacy Gateway更名为Cloudflare OHTTP Relay，以区分两种角色。此次是测试与候补开放，不能视为所有账户都已获得正式可用服务。
配图为AI生成的概念插图，表现独立中继与解密网关之间的信任分隔，不是真实网络拓扑，也不代表对任何数据内容的绝对匿名保证。
为什么需要两个独立环节
OHTTP在客户端和应用之间引入relay与gateway。按RFC 9458，客户端先编码并加密请求，中继转发密文，网关负责解封装并交给目标服务，再将响应加密返回。中继面对客户端连接，能看到网络层来源，却不应看到请求明文；网关能够处理内容，却只看到中继的连接信息。
隐私基础来自分离信任。若同一个运营方同时掌握客户端来源和解密后的请求，两跳结构就失去了预期作用。Cloudflare给出的新组合是第三方中继加Cloudflare Gateway；现有Cloudflare Relay方案则需要客户自备独立网关。这也解释了为何已放在Cloudflare CDN或Workers后的应用，更适合评估新网关这一侧。
托管部分包含哪些工作
按公告，新网关计划接管密钥管理，提供公钥配置，支持标准OHTTP和分块OHTTP请求，并在解密后向应用发送子请求。普通非OHTTP流量可继续使用原有HTTP路径。托管网关降低了自行处理密码封装与扩容的工作量，但客户端仍需要实现OHTTP协议并选择中继。
另一个值得注意的保护是来源限制：网关将拒绝解密来自Cloudflare Workers或Cloudflare代理主机的请求，防止客户误把中继和网关都放在Cloudflare之内。这是架构约束，不能靠把中继简单包装成一个边缘函数来替代。部署规划应先画出谁能看到IP、谁能看到正文，再决定组件所在位置。
网络层隐私不会清洗请求正文
RFC明确提醒，请求中的Cookie、身份信息或认证凭据仍可能把多次请求关联起来。Cloudflare也在接入说明中强调，OHTTP不会修改内层请求正文。如果应用把邮箱、用户名或稳定账户标识随内容发出，目标服务仍能据此识别用户；加密传输到网关并不会自动消除这种关联。
因此，产品设计需要区分“隐藏源IP”和“业务内容无法识别人”这两个目标。例如匿名统计请求若仍附带长期不变的账户编号，服务端依然可以建立行为轨迹。实际审查应覆盖正文、内层请求头、返回的标识以及后续请求如何复用这些信息，而不能只检查网络路径上是否出现中继。
测试阶段先验证协议和故障行为
对准备加入测试的团队，较有价值的验证包括客户端是否取得经过认证的公钥配置、中继是否正确去除来源信息，以及密钥更新、超时和网关拒绝请求时应用如何反馈。RFC对密钥配置完整性与每次请求使用新的加密上下文有明确要求，这些协议条件不会因采用托管服务而失去意义。
这次发布扩展了可选择的基础设施组合，尤其适合希望保留Cloudflare应用托管，同时减少自行运营解密网关负担的开发者。最终隐私承诺仍应限定在经过验证的威胁模型、独立运营关系和应用数据设计范围内。
官方资料
资料核对：2026年10月3日（北京时间）。产品状态、价格与支持范围以官方后续更新为准。
