Cloudflare’s OHTTP Gateway Refuses to Decrypt Requests That Arrive Through Cloudflare

Cloudflare的OHTTP网关拒绝解密通过Cloudflare传入的请求 - InfoQ

InfoQ主页新闻：Cloudflare的OHTTP网关拒绝解密通过Cloudflare传入的请求

Cloud

从令牌到功能：为AI辅助工程构建成本归属（网络研讨会 10月29日）

Cloudflare的OHTTP网关拒绝解密通过Cloudflare传入的请求

2026年10月13日 6分钟阅读

作者：

• Steef-Jan Wiggers

#### 关注我们

YouTube

232K关注者

LinkedIn

26K关注者

Instagram

新

RSS

19K读者

X

57.1k关注者

Facebook

21K点赞

Bluesky

收听本文 -

0:00

音频准备就绪

您的浏览器不支持音频元素。

正常

1.25x

1.5x

喜欢

新下拉阅读列表

• 阅读列表

Cloudflare已开放Cloudflare OHTTP网关的封闭测试版，这是一个受管理的端点，代表源站解密Oblivious HTTP请求。最受关注的设计决策是一个拒绝而非功能：网关将不会解密来自Cloudflare Workers或通过Cloudflare代理的主机的请求。

Oblivious HTTP（RFC 9458标准）将请求拆分为两方。客户端使用HPKE将内部HTTP请求加密到网关的公钥，并将密封的有效负载发送到中继节点。中继节点可以看到客户端的IP地址，但无法读取请求。网关解密后将明文HTTP转发给应用，因此它能看到内容，但只能看到中继节点的地址。

这种设计只有在不同运营商运行两个跳转时才有效。如果在网关前放置Worker，或通过Cloudflare代理中继节点，会使识别客户端的跳转和解密跳转通过同一家公司，因此Cloudflare构建了一个拒绝在此配置下运行的产品。作者Lara Schull和Akshat Mahajan指出，该模型“要求中继节点和应用服务器由不共谋的独立方运营”。

对于评估该方案的团队，实际成本在于中继节点。Cloudflare不会为网关提供中继节点，并表示该组件不是难点，因为中继节点“可以在任何基础设施提供商上运行，且实现简单”。真正的难点在于“能够向用户可验证地承诺不会检查包含客户端标识符的日志”。Cloudflare也将其现有的隐私网关更名为Cloudflare OHTTP中继节点，以区分双方。

网关本身绑定到一个区域，并监听固定路径https://your-zone.com/.well-known/ohttp-gateway，这阻止客户将网关指向其他域名。Cloudflare管理HPKE密钥，并通过相同路径响应GET请求提供公钥，客户端可以通过与请求使用的不同IP地址获取密钥。标准和分块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的匿名模式和Apple的Private Cloud Compute作为生产部署案例，其中Apple的LiveCallerID是服务方接受第三方OHTTP请求的案例。Cloudflare与Apple合作的参考图像项目（InfoQ今年早些时候曾报道过），使用相同的传输方式请求时间戳而无需暴露请求方身份。

Cloudflare表示网关将于今年秋季推出，自托管版本的封闭测试版现在已开始。该服务将作为客户区域的付费附加功能出售，但公告中未公布价格。有兴趣的团队可通过等待名单表单进行注册。

关于作者

作者信息

#### Steef-Jan Wiggers

显示更多

显示更少

#### 本文属于云技术主题

##### 相关主题：

• 开发
• 架构与设计
• DevOps
• 云技术
• 相关编辑内容
• 相关赞助商
• 相关赞助商 2026年10月29日，美国东部时间下午1点 从代币到功能：为AI辅助工程构建成本归属架构 主讲人：Martin Reynolds - Harness首席技术官，Barani Mohandoss - Trimble云治理、FinOps与E工具总监

InfoQ新闻通讯

每周五汇总InfoQ最新内容，每星期二发送。加入超过25万名高级开发者的社区。查看示例

我们保护您的隐私。