Cloudflare推出OHTTP网关 应用服务器看不到用户IP

Cloudflare宣布推出OHTTP网关（OHTTP Gateway）封闭测试版。这是一款面向开发者的付费附加功能，启用后，应用后端在接收用户请求时将看不到对方的真实IP地址和TLS指纹。产品基于IETF的Oblivious HTTP（OHTTP）标准，官方今年秋季正式上线，目前已开放候补名单注册。

OHTTP的核心是一套「双盲」架构：用户请求先经过一个中继（relay），中继能看到客户端IP等身份信息但看不到加密内容；随后请求抵达网关（gateway），由它完成解密和回程加密，再把普通HTTP请求交给应用服务器。三方各知其一段，没有任何一方能同时看到「谁在请求」和「请求了什么」，应用服务器因此无法把多次请求关联回同一个用户。

这并非Cloudflare第一次涉足该领域。2022年它就上线了中继侧产品Privacy Gateway（现已更名为OHTTP Relay），Flo Health的匿名模式、苹果Private Cloud Compute的AI推理请求都在使用其OHTTP中继。但问题在于：如果应用服务器本身就托管在Cloudflare的CDN或Workers上，再用Cloudflare自家的中继就违反了「中继与网关必须由互不串通的两方运营」这一隐私前提。网关侧产品正好补上了这块拼图。

工程细节上，Cloudflare把网关做成了绑定在自家域名区域（zone）上的服务，客户端向 /.well-known/ohttp-gateway 端点发送标准或分块（chunked）OHTTP请求即可，后者支持流式处理、性能更好。依托anycast网络，网关部署在全球边缘的每一台服务器上，若应用也在Cloudflare上，解密与回源可发生在同一批机器上以压缩时延。HPKE密钥由平台全自动生成与轮换，客户无需手工管理。

防滥用设计也考虑在内：网关会拒绝解密来自Cloudflare Workers或Cloudflare代理主机的请求，避免客户误将中继和网关都架在同一平台上、不知不觉破坏隐私模型；同时可借助Cloudflare Access（支持mTLS、静态服务凭据等策略）在解密前验证中继身份。官方建议自建中继可跑在任何基础设施上，客户端实现可参考ohttp.info与其示例库。