Cloudflare 已开始对 Cloudflare OHTTP Gateway 服务进行封闭测试。这是一项可在客户域名上启用的付费附加服务，用于通过托管架构接收 Oblivious HTTP（OHTTP）流量。该服务面向希望向其应用服务器隐藏 IP 地址和客户端识别信息的开发者，尤其适用于这些服务器托管在 Cloudflare 网络之后或运行于 Workers 上的情况。
与此同时，公司将此前的 Privacy Gateway 产品更名为 Cloudflare OHTTP Relay。这一变化反映了 OHTTP 模型中的两种不同产品：relay 转发加密请求并隐藏客户端身份，而 gateway 负责解封请求的加密封装，并在将响应交付给应用服务器之前重新封装响应。
OHTTP 模型如何工作？
在传统连接中，应用服务器可以看到客户端的 IP 地址、TLS 特征和位置信息，这可能使其能够将多个请求关联到同一用户。在 OHTTP 中，请求会经过一个独立的 relay，由 relay 移除客户端身份标识后再进行转发。请求内容仍使用混合公钥加密（Hybrid Public Key Encryption，HPKE）进行加密，因此 relay 无法看到明文。
随后，gateway 处理加密部分，并以常规 HTTP 格式将请求交给应用服务器。这样便形成了信任分离：relay 可以看到连接身份，却看不到请求内容；而 gateway 和应用服务器可以看到请求内容，却看不到客户端的直接身份。该模型要求承担 relay 和 gateway 角色的两方不能相互串通。
新 gateway 增加了什么？
OHTTP Gateway 作为 Cloudflare 域名内的一项功能运行，并可通过特定端点启用，例如 /.well-known/ohttp-gateway。该服务支持标准 OHTTP 和 Chunked OHTTP，同时建议使用分块类型以逐步处理请求。此外，Cloudflare 负责管理 HPKE 公钥并将其提供给客户，而不是让客户承担密钥生命周期管理责任。
该服务利用 Cloudflare 的全球网络，使 gateway 能够在网络边缘运行，并减少 relay 与 gateway 之间的延迟。如果应用服务器使用该公司的 CDN，请求处理和访问服务器可以在同一基础设施上完成。gateway 只处理 OHTTP 请求，而普通请求仍会在不经过 OHTTP 处理的情况下到达服务器。
信任与使用控制
Cloudflare Access 可以在解密请求之前强制执行身份验证策略，包括双向 TLS（mutual TLS）、静态服务凭据和自定义外部逻辑。gateway 还会拒绝来自 Cloudflare Workers 或经由 Cloudflare 转发的主机的请求，以避免同一方同时运行 relay 和 gateway，从而削弱 OHTTP 所依赖的信任分离。
Cloudflare 建议在应用服务器位于 Cloudflare 之后，或请求来自第三方 relay 和客户端时使用 OHTTP Gateway，例如 Apple LiveCallerID 的某些使用场景。至于更名后的 Cloudflare OHTTP Relay，则适合希望使用 Cloudflare relay、同时在 Cloudflare 之外自行运行 gateway 的用户。
实际会发生什么变化？
新服务降低了构建 OHTTP gateway 的运营负担，但并未取消基本的架构要求。客户仍需实现 OHTTP，用户也仍需使用独立的 relay；Cloudflare 强调，关于不检查日志以及不将客户身份与已解密请求关联，relay 必须是可以信任的实体。OHTTP 同样不会保护请求正文中包含的元数据，因此开发者有责任避免在请求内容中发送电子邮件地址、用户名或其他标识符。
该服务目前处于封闭测试和候补名单阶段，公告尚未确定正式发布的时间或价格详情。因此，这一步代表着网络隐私工具的重要扩展，但开发团队仍需就 relay、请求内容以及各方之间的信任模型作出独立决策。