Cloudflare推出OHTTP网关封闭测试并拒绝同域流量

Cloudflare已启动OHTTP Gateway封闭测试，为源服务器提供托管式Oblivious HTTP请求解密服务。该产品最明显的限制是：来自Cloudflare Workers，或经过其代理主机转发的请求不会被网关解密。原因在于同一家公司同时掌握中继和解密环节，会破坏OHTTP的隐私模型。

OHTTP已被标准化为RFC 9458。客户端通过HPKE将HTTP请求加密至网关公钥，再把密文交给中继服务器；中继能看到客户端IP，却无法读取内容，网关则负责解密并将明文请求交给应用，只能看到中继地址。该机制要求中继与网关由互不相关的运营方控制，因此Cloudflare明确拒绝同域中继、网关配置。

部署方需要自行准备中继服务器。Cloudflare认为中继可运行在任意基础设施上，实现并不复杂，真正困难的是向用户证明不会检查包含客户端标识符的日志。现有Privacy Gateway也将更名为Cloudflare OHTTP Relay，以区分中继与网关产品。网关绑定客户区域及固定地址https://your-zone.com/.well-known/ohttp-gateway，Cloudflare负责管理HPKE密钥，并通过GET请求提供公钥；客户端获取密钥时可使用不同于请求地址的IP。

服务支持标准OHTTP和分块OHTTP，出于性能考虑更建议后者。Cloudflare Access会在解密前执行，因此中继可通过双向TLS、静态服务凭据或自定义外部逻辑完成身份验证。不过，保护范围仅限网络层，若密封请求中包含电子邮件、用户名或会话令牌，网关运营方仍能看到这些身份信息。

相关讨论集中在实际运营成本，而非加密机制本身。OHTTP适合无状态请求，可避免网关关联同一客户端的多次访问；相比SOCKS5，它能隔离TLS指纹风险，并允许客户端与中继、中继与网关保持长连接，对DNS over HTTPS等场景有延迟优势。但网关密钥泄露后，历史记录流量可能因缺乏前向保密而被解密。评论者还关注WAF、基于IP封禁、滥用追踪、客户端和代理软件支持，以及小规模自建中继会削弱匿名性等问题。

OHTTP常被比作带固定网关的两跳Tor，但它不是通用浏览隐私工具，而是供应用在遥测、推断和查询场景中隐藏请求者身份。已有案例包括Flo Health匿名模式、苹果私有云计算、LiveCallerID，以及Cloudflare与苹果合作的Reference Image项目。Cloudflare计划于今年秋季正式发布该网关，作为客户区域的付费增值服务，具体价格尚未公布，目前可通过候补表单申请测试。