Cloudflare 于 2026 年 10 月 2 日宣布推出 Cloudflare OHTTP 网关，这是一项托管服务，负责为 Oblivious HTTP (OHTTP) 流量执行加密解封装。
OHTTP 是一项 IETF 标准协议，旨在让应用服务器接收 HTTP 请求时无法获取客户端标识符，如 IP 地址或 TLS 指纹。请求通过两个独立的跳转节点传输：一个盲目转发加密流量的中继，和一个负责解密并返回加密响应的网关。这种信任分离确保没有任何单一方能同时看到客户端元数据和请求内容。
在典型的客户端-服务器交换中，应用服务器会获知客户端的 IP 地址、TLS 加密套件和其他指纹数据。Cloudflare 博客解释称，OHTTP 中继会在转发请求前剥离这些标识符，因此应用服务器只能看到中继的位置和通用的 TLS 指纹。公司给出了一个具体示例：服务器收到的不再是来自加利福尼亚州坎贝尔、具有唯一加密套件的客户端请求，而是来自德克萨斯州奥斯汀、具有不同加密套件的中继请求，从而切断了请求与用户身份之间的关联。
网关采用混合公钥加密 (HPKE) 封装请求，使得只有客户端和应用服务器能够读取。中继看到的是密文，网关看到的是解密后的请求内容，应用服务器看到的是普通 HTTP。这构建了一个双盲隐私模型：没有任何一方能同时看到同一笔交易的两个部分。
Cloudflare 将该网关定位为已将应用服务器部署在 Cloudflare CDN 或 Workers 后端的开发者的解决方案。此前，使用 Cloudflare OHTTP 中继（前身为 Privacy Gateway）的客户必须自行搭建网关以维持所需的信任分离。现在他们可以改用第三方中继，配合 Cloudflare 的托管网关。Apple 的 Private Cloud Compute 和 LiveCallerID SDK 被引用为现有用例。
网关提供自动扩缩容、密钥管理和滥用防护。客户通过启用插件并让客户端向 https://your-zone.com/.well-known/ohttp-gateway 发送格式正确的 OHTTP 请求来进行配置。为维护隐私模型，服务拒绝解密来自 Cloudflare Workers 或 Cloudflare 代理主机的请求，确保 Cloudflare 永远不会同时看到客户端标识符和解密后的请求内容。
Cloudflare 建议使用分块 OHTTP 进行增量处理，以提升性能。公司还构建了滥用防范机制：向 example.com 发送请求的客户端只能以该区域的子域名为目标，而不能以 wikipedia.com 等任意域名为目标。
对于希望继续使用 OHTTP 的开发者，Cloudflare 表示网关已可用于生产环境，但客户仍需自备中继并实现 OHTTP 客户端。公司提供了示例客户端库和示例中继代码以帮助快速上手。