网络通信长期遵循一套不言自明的规则:服务端想为你提供服务,就必然拿到你的网络身份凭证。用户的公网 IP 地址、TLS 指纹和地域标识,伴随着每一次 HTTP 请求直奔应用服务器后台。这种架构不仅让端侧用户不得不依赖各类防追踪插件,也让处理敏感医疗、通讯录或 AI 推理的企业在数据合规层面如芒在背。

Cloudflare 于 2026 年 10 月 2 日正式开放 Cloudflare OHTTP Gateway 的封闭测试,将其作为 Zone 的付费附加组件,同时把 2022 年上线的 Privacy Gateway 更名为 Cloudflare OHTTP Relay。这项基于 IETF RFC 9458 标准的产品,表面上看是边缘云服务商又补齐了一块网络基础设施拼图,实则制造了一个反常的技术事实:Cloudflare 虽同时拥有了中继与网关两项核心组件,却在网关底层硬编码了防作恶机制,主动拒绝对来自自身生态的流量进行解密。

拆解双跳架构:谁拿数据,谁看身份

要理解这个反直觉的设计,必须先看清传统 HTTP 与 OHTTP 的结构差异。普通请求像是一张明信片,发件人地址和正文暴露在同一个信封上;而 OHTTP 则设计了一个双跳盲盒体系,将传输路径彻底拆分为中继(Relay)与网关(Gateway)两个互不通谋的节点。

中继节点剥离发件人身份,网关凭私钥解密内层载荷(示意图)
中继节点剥离发件人身份,网关凭私钥解密内层载荷(示意图)
OHTTP RFC 9458:双跳信任分离与信息断链机制 客户端 持真实客户端 IP HPKE 密文封装 发起双重隔离请求 中继节点 (Relay) • 能看:客户端真实 IP • 盲区:密文内容完全不可见 剥离指纹,以中继身份转交 网关与源站 (Gateway) • 能看:解密后的明文数据 • 盲区:绝不知晓客户端 IP 处理明文,响应原路折返 核心约束:Relay 与 Gateway 必须分属不同运营实体,一旦单方掌控两端,双盲模型即告破产。

在 OHTTP 交互中,客户端首先通过混淆公钥加密(HPKE,RFC 9180)将请求主体封包,再通过中继发出。中继只负责拆开外层传输包,剥离发件人的原始 IP、地理经纬度及 TLS 指纹,但它没有密钥,根本读不懂被加密的内层载荷。等到中继把请求转交给网关时,网关虽拥有私钥并完成解密,所见的来源 IP 却只剩中继机器的地址。

这种双盲机制早已在苹果生态中运转。苹果的 Private Cloud Compute 依赖它切断 AI 推理请求与手机机主的设备关联,iOS 上的 LiveCallerID 识别来电也是借助 OHTTP 阻断号码查询记录回流。健康医疗软件 Flo Health 同样以该架构支撑其匿名模式,避免敏感身体数据被平台端锚定到真实用户。

隐私工程的技术底线在于物理隔离:能看清发件人的节点不得看信件,能读懂信件的节点绝不能认出寄信人。

边缘机房同构:从跨网漫游到同机吞吐

此前限制各类应用采用 OHTTP 的核心障碍不在算法,而在工程运维与网络损耗。普通开发者自建 OHTTP 网关,需要自行维护公钥轮换、处理非对称加密算力瓶颈,还要承担多次网络跳转(RTT)造成的延迟剧增。

网关与业务源站在同一台边缘服务器内完成内存流转(剖面示意)
网关与业务源站在同一台边缘服务器内完成内存流转(剖面示意)

传统方案中,请求先从中继跨公网绕行至自建网关,再由网关转发至实际业务服务器。两跳网络代理叠加非对称加解密计算,极易带来百毫秒级的时间开销。Cloudflare 此次切入网关层,正是利用了其全球分布的 Anycast 边缘网络。

对于原本就托管在 Cloudflare CDN 或 Workers 上的客户,OHTTP Gateway 与业务源站可以直接运行在同一物理边缘节点(same metals)上。这意味着外层中继送达请求后,解密动作与后续路由在同机房甚至同主机内存级别流转,抹平了传统网关二次转发的跨机房延迟。

与此同时,网关以 /.well-known/ohttp-gateway 规范挂载在域名下,既原生支持分块传输(Chunked OHTTP)以提升流式吞吐,又将公钥分发收拢为自动化运维。借助前置的 Cloudflare Access 模块,网关可以在解密内容之前先利用双向 TLS 或服务凭据验证中继身份,防范未知节点对业务端发起嗅探。

自建网关 vs Cloudflare 边缘一体化部署架构对照 模式 A:传统开发者自建网关 • 节点布局:跨数据中心多次公网折返 • 运维要求:自研 HPKE 密钥轮换服务 • 防护机制:需额外搭建外部鉴权层 • 架构痛点:网关至源站 RTT 开销偏大 网络延迟高 / 运维负担重 模式 B:Cloudflare 托管网关附加项 • 节点布局:CDN与源站在同节点解密 • 运维要求:/.well-known 自动化托管密钥 • 防护机制:前置集成 Cloudflare Access • 性能优势:同机(same metals)直接处理 边缘就近解封装 / 一键开通

信任悖论:代码级封杀自家产品

商业云计算的本能永远是卖全家桶,用粘性极高的闭环把企业牢牢锁在自身生态内。然而在 OHTTP Gateway 的工程实现里,Cloudflare 却主动打断了这一逻辑。

边缘网关在物理结构上硬编码互锁,强制引入第三方中继
边缘网关在物理结构上硬编码互锁,强制引入第三方中继

系统在代码层面硬编码了防作恶拦截规则:Cloudflare OHTTP Gateway 会直接拒绝解密任何来自 Cloudflare Workers 或经由 Cloudflare 代理主机转交的请求。

  • 风险.若一家厂商同时提供 Relay 与 Gateway,且客户在同一网络内配齐两端,厂商只需比对内部流量时序即可还原用户与数据,使中继匿名彻底失效。

为了维护 RFC 9458 规定的独立信任分离,Cloudflare 明确了两种非此即彼的交付路径:

  1. 如果你的应用源站脱离 Cloudflare 托管可以使用其 OHTTP Relay(原 Privacy Gateway),但解密网关必须由企业自建或采买第三方;
  2. 如果你的应用部署在 Cloudflare 平台内(使用 CDN 或 Workers)可以开启新的 OHTTP Gateway,但前置中继必须采购第三方(如 Fastly 或中立代理运营商)。

这种架构倒逼企业架构师放弃单一采购策略,必须维系多供应商网络。

从产业现实看,这项能力目前仍处于封闭测试阶段,采用定向申请制,具体计费细节未定。但随着苹果等平台级系统全面推行 OHTTP 协议规范,数据处理者在网络传输层剥离用户身份正从选择题变为合规必答题。对于手握敏感交互场景的企业而言,自建密码学网关的门槛已被边缘基础设施抹平,但如何搭建多方制衡的中继通道,已成为下一阶段架构选型的新课题。