Cloudflare 启动 Cloudflare OHTTP Gateway 的封闭测试。这是一个托管端点，可以代表源服务器对 Oblivious HTTP 请求进行解密。最受关注的设计决策并非某项功能，而是一项限制：如果请求来自 Cloudflare Workers 或通过 Cloudflare 代理的主机，那么该网关不会对其进行解密。
Oblivious HTTP（已作为 RFC 9458 标准化）将请求拆分成了两个部分。客户端使用 HPKE 将内部 HTTP 请求加密为网关公钥，并将密封后的有效载荷发送给中继服务器。中继服务器可以看到客户端的 IP 地址，但无法读取请求的内容。网关对其进行解密，并将明文 HTTP 请求转发给应用程序。因此，应用程序可以看到请求的内容，但全程只能看到中继服务器的地址，而无法获取客户端真实 IP。
该方案只有在这两个传输跳点由不同的运营商运营时才有效。如果在网关前部署一个 Worker，或者通过 Cloudflare 代理中继流量，那么用于识别客户端的跳点和解密跳点都将流过同一家公司的服务。因此，Cloudflare 专门推出的这款产品明确拒绝在这种违规配置下运行。作者 Lara Schull 和 Akshat Mahajan 指出，该模型“要求中继服务器和应用服务器由互不相关的独立运营方运营”。
对于评估该方案的团队而言，实际成本在于中继服务器。Cloudflare 并未为网关提供中继服务器，并且说该组件并非难点，因为中继服务器“可以在任何基础设施提供商那里运行，而且实现简单”。真正的难点在于能否“向用户做出可验证的承诺，即不会检查包含客户端标识符的日志”。Cloudflare 还将现有的 Privacy Gateway 更名为 Cloudflare OHTTP Relay，以区分这两种方案。
网关本身绑定了到一个区域，并监听一个固定的路径：https://your-zone.com/.well-known/ohttp-gateway，这会阻止客户将他们的网关指向其他域名。Cloudflare 管理 HPKE 密钥，并在响应 GET 请求时通过该路径提供公钥，客户端可以通过与请求 IP 地址不同的 IP 获取密钥。标准 OHTTP 和分块 OHTTP 都可以使用，出于性能考虑，建议使用分块 OHTTP。Cloudflare Access 在解密之前运行，因此，中继服务器本身可以通过双向 TLS、静态服务凭据或自定义外部逻辑进行身份验证。
保护仅限于网络层，Cloudflare 也是这么说的。该博文指出，OHTTP “在网络层提供隐私保护，而且不会触及请求内部的正文内容”，并补充道：“是否在请求正文中发送可识别身份的信息（例如用户的电子邮件地址或用户名），取决于你自己。”如果在密封的请求中放入会话令牌或电子邮件地址，那么网关运营商便会获取该协议本应隐藏的身份信息。
Hacker News 上的讨论呈现了两极分化：一部分读者在探讨该协议的适用场景，另一部分读者则在指出其代价。评论者 johnhess 阐述了其适用场景：
这可以区分谁能看到什么内容。Cloudflare 或任何 OHTTP 网关都能看到谁与谁通信，但无法看到内容本身。该服务能看到内容，却无法识别你的身份或 IP 地址。你可以设想出许多威胁模型：你与谁通信并不敏感，“某人曾与他们讨论过 X ”这一事实也不敏感，但同时知晓这两点则会构成风险。
评论者 gsnedders 给出了最详细的对比分析，将 OHTTP 与显而易见的自建替代方案——SOCKS5 代理——进行了对比：
OHTTP 的设计使用场景相对狭窄：无状态请求。在这种情况下，你不希望网关能够将同一客户端发出的多个请求关联起来（也就是说，这不仅仅是为了隐藏 IP 地址）。
他写道，如果与 SOCKS5 结合使用，则意味着每个请求都需要建立新的 TCP 连接，不能进行 TLS 会话恢复或 0-RTT，而且 ClientHello 要设置得相当保守——因为 SOCKS5 未加密，是以明文形式传输目标地址。OHTTP 将 TLS 指纹识别攻击面与网关隔离，并允许在客户端与中继以及中继与网关之间建立长连接。他说，这对 DNS over HTTPS 等工作负载而言是一项显著的延迟优化。他还指出了该设计所做出的妥协：
在 OHTTP 中，网关密钥的泄露本质上意味着中继服务器可以解密使用了该密钥的已记录流量（因为不存在前向保密），而客户端 <-> 中继服务器以及中继服务器 <-> 网关之间的密钥泄露影响则要小得多。
这些有针对性的问题都聚焦在实际的落地运营层面。评论者 arshxyz 询问了公告中未提及的一个产品交互问题：
如果启用了 OHTTP，Cloudflare 的 WAF（该功能依赖于 TLS 指纹识别）是否会停止工作？如果不会，这是否意味着客户端元数据会被 Cloudflare 读取和处理，但不会传递给应用服务器？
评论者 Joker_vD 询问基于 IP 地址的封禁机制如何得以维持，而评论者 blantonl 则描述了运营商最终将面临的处境：“我尊重客户的隐私。但我同时也需要知道是谁在滥用我的平台。”评论者 thayne 则提出了数据聚合的问题。他指出，当某个实体占据互联网的大部分份额时，它最终会掌握特定 IP 访问过哪些网站以及哪些 IP 访问过特定用户的记录。但他同时也承认：“这总比他们掌握源 IP 和内容要好。”
如果这些反应具有代表性，那么就可以说明，加密机制本身没有成为各团队争论的焦点。在这个讨论贴中，没有人质疑这种拆分机制是否会如描述的那样运作。大家关注的问题在于：是否存在支持该协议的客户端、自托管中继服务器的价值何在，以及一旦客户端元数据消失，Cloudflare 方面会出现哪些问题。评论者 ranger_danger 问道，是否有现有的代理、隧道或 VPN 软件支持 OHTTP 传输协议，对于未发布自有应用的开发者而言，这是影响他们采用的关键问题。关于自托管，评论者 palata 指出，仅为少数人运行的中继服务器会背离其设计初衷，因为服务方将知晓所有经由该中继服务器的请求均来自这个小群体。评论者 scosman 结合自身经验描述了需求端的情况。他表示，自己曾经希望在原本离线的转录软件中使用该功能进行更新检查，结果是他最终只能直接调用 GitHub 发布接口。评论者 freedomben 则对该服务是否应该收费表达了质疑。他指出，如果目标是普遍性地改善隐私，那么付费隐私插件“将是一种糟糕的激励机制”。
在这个讨论贴中，有一个与之最接近的类比是 Tor。评论者 maayank 将其概括为：“OHTTP 就像一个带有预设网关的两跳 Tor 电路。”两者的区别在于适用范围。OHTTP 需要客户端有意识地通过该协议与已知网关进行通信，因此它并非通用的浏览隐私解决方案。它适合希望获取遥测数据、进行推断或提供查询功能，但又无法将每次请求与特定用户关联的应用供应商。Cloudflare 援引了将 Flo Health “匿名模式”和苹果“私有云计算”作为生产环境部署的案例，把苹果的 LiveCallerID 作为服务接受第三方 OHTTP 请求。Cloudflare 与苹果合作的“参考镜像”（Reference Image）项目——InfoQ 今年早些时候曾经报道过——也使用了相同的传输协议来请求时间戳，同时不透露请求者的身份。
Cloudflare 表示，该网关将于今年秋季正式推出，目前其自助服务版本已经开启封闭测试。该服务将作为客户区域的付费增值组件进行销售，但公告中未公布具体价格。感兴趣的团队可以通过候补表单进行注册。
原文链接：https://www.infoq.com/news/2026/10/cloudflare-ohttp-gateway/
