Cloudflare 推出 OHTTP 网关：隐私保护的新基础设施

什么是 OHTTP

Oblivious HTTP（简称 OHTTP）是一种旨在将用户身份与请求内容解耦的网络协议。传统的 HTTP 请求中，接收请求的服务器既能看到请求的内容，也能看到发起请求的客户端 IP 地址——这意味着服务器可以将「谁」和「做了什么」关联起来，构建用户画像。OHTTP 的核心思路是在中间插入一个「中继（relay）」和一个「网关（gateway）」，让任何单一实体都无法同时掌握这两类信息。

具体来说，客户端先对请求内容进行加密，再通过中继转发到网关。中继能看到客户端 IP，但看不到加密的请求内容；网关能解密并处理请求内容，但只能看到中继的 IP，无法知道原始客户端是谁。只要中继和网关由不同的、互不串通的组织运营，用户的身份与请求内容就被有效隔离。

Cloudflare 此次宣布推出 OHTTP 网关服务，正是把这套机制中的「网关」角色产品化，降低了各类应用集成隐私保护能力的门槛。

OHTTP 的加密机制基于 HPKE（Hybrid Public Key Encryption），客户端使用网关的公钥对请求进行非对称加密封装，确保中继在转发过程中无法读取请求体。整个协议由 IETF 在 RFC 9458 中正式标准化，其设计目标之一是最小化元数据泄露——即便是中继也只能看到「某个 IP 向某个网关发出了一次请求」这一事实，而无法获得任何请求内容的信息。这种「盲转发」的特性使得 OHTTP 与传统 VPN 或 HTTPS 代理有本质区别：VPN 服务商可以同时看到用户身份和流量内容，而 OHTTP 在架构上从协议层面阻止了单点知情。

为什么这件事值得关注

OHTTP 并非全新概念，它由 IETF 标准化，苹果的 iCloud Private Relay、Private Relay 相关功能以及一些遥测场景早已有所应用。但长期以来，部署 OHTTP 需要开发者自行搭建和维护网关，门槛较高。Cloudflare 将其作为托管服务提供，意味着更多开发者可以直接调用这套基础设施，而不必从零构建。

从行业背景看，隐私合规的压力越来越大，App 遥测、崩溃上报、使用统计等场景都面临「既想收集数据又不想侵犯用户隐私」的矛盾。OHTTP 恰好提供了一条中间路径：应用依然能获得聚合层面的统计信息，却无法将具体数据点回溯到某个具体用户。这对于需要收集敏感遥测的厂商尤其有吸引力。

在 Hacker News 上，这篇公告获得了 183 个点赞和近 90 条评论，讨论热度不低，反映出开发者社区对隐私基础设施持续的关注。

中继与网关的信任模型

OHTTP 隐私保证的关键在于「职责分离」——中继和网关必须由不同主体运营，且两者不能合谋。这也是讨论中被反复提及的要点：如果同一家公司既运营中继又运营网关，那么它理论上可以把两边的信息拼起来，隐私承诺就形同虚设。

因此，Cloudflare 提供网关服务时，一个合理的部署模式是由其他独立方运营中继。这种架构类似苹果 Private Relay 的双跳设计，苹果负责一跳、第三方 CDN 负责另一跳，从而形成制衡。对于采用 Cloudflare 网关的开发者而言，选择一个与 Cloudflare 无利益关联的中继提供方，是保证隐私模型成立的前提。

需要清醒认识的是，OHTTP 提供的是「不合谋前提下」的隐私保护，而非密码学意义上绝对的匿名。它的安全性建立在运营者之间的信任分散之上，这是一种工程与治理结合的隐私方案。

这种「不合谋假设（non-collusion assumption）」在密码学与隐私工程中有着悠久的讨论历史。它本质上是一种威胁模型的边界条件：当两方运营者存在商业竞争关系、分属不同司法管辖区、或受到不同监管约束时，合谋的可能性相对较低。苹果 iCloud Private Relay 选择与 Akamai、Cloudflare 等 CDN 合作运营第二跳，正是试图通过商业逻辑和地域分散来强化这一保证。然而值得注意的是，「不合谋」并不等于「不能被法律强制要求配合」——在特定司法环境下，政府可能同时向两方发出数据披露令，从而绕过这一隐私机制。因此选择跨司法管辖区的中继与网关组合，是更严肃的隐私需求下需要考量的因素。

适用场景与局限

OHTTP 最典型的用途包括：应用遥测与分析上报、密码泄露检测查询（如检查某密码是否出现在已知泄露库中）、以及任何「希望隐藏请求来源但保留请求功能」的场景。它特别适合那些请求无需返回大量个性化内容、以单向上报为主的情形。

局限同样明显。OHTTP 引入了额外的加密和中继跳转，会带来一定的延迟开销，不适合对实时性要求极高的交互式场景。同时，由于请求内容对网关可见，OHTTP 保护的是「身份与内容的关联」，而不是内容本身对网关保密——如果请求内容天然包含可识别信息（比如登录态、唯一标识），那么 OHTTP 的隐私效果也会打折扣。

换句话说，OHTTP 是隐私工具箱中的一件，而非万能钥匙。开发者需要结合具体数据流动来判断它是否真正切中自己的隐私需求。

密码泄露检测是 OHTTP 最具代表性的落地场景之一，其背后通常结合了 k-匿名（k-Anonymity） 或 私有集合交集（Private Set Intersection） 等技术。以 Have I Been Pwned 类服务为例，客户端只发送密码哈希的前几位前缀，服务端返回所有匹配前缀的哈希列表，客户端本地完成比对——这样服务端无法得知用户查询的具体密码。叠加 OHTTP 后，服务端进一步无法将查询行为与客户端 IP 关联，使得「谁在查询敏感密码」这一元数据也得到保护。这类「协议组合使用」的模式，是隐私工程实践中值得关注的设计范式。

小结

Cloudflare 推出 OHTTP 网关，标志着隐私增强技术正从标准草案和少数大厂的自用方案，走向更普及的托管基础设施。对开发者来说，这意味着构建「尊重用户隐私」的应用的成本在下降；对整个行业来说，它推动隐私保护从「可选项」逐渐变为「可随手获得的默认能力」。

真正的考验在落地细节：中继与网关的独立性能否得到保证、延迟开销是否可接受、以及开发者是否真正理解其信任模型的边界。隐私基础设施的价值，最终取决于它被如何正确地组合使用。