产品背景与演进

传统客户端与服务器直接通信时，服务器能获取用户 IP、TLS 指纹等标识，导致行为可被关联。Cloudflare 认为隐私保护应内建于基础设施。其于 2022 年推出 OHTTP Relay（原 Privacy Gateway），但仅解决中继盲转，若业务已托管在 Cloudflare 后则无法同时使用同厂商中继（信任模型冲突）。今年秋季，Cloudflare 启动 OHTTP Gateway 封闭测试，并更名为 Cloudflare OHTTP Relay 与 Gateway 以区分角色。

OHTTP 标准与双盲模型

Oblivious HTTP（OHTTP）是 IETF 标准，通过中继（Relay）与网关（Gateway）两跳实现隐私：

  • 中继盲目转发加密请求，剥离客户端 IP、TLS 指纹等元数据，使后端仅见中继信息。
  • 网关负责使用混合公钥加密（HPKE）解封请求、封装响应，使应用服务器像处理普通 HTTP 一样工作。
  • 信任分离确保无任何单一方同时看到客户端标识与请求内容，形成“双盲”边界。

例如 Flo Health 匿名模式、Apple 私有云计算均依赖此机制解耦用户身份与请求。

Cloudflare 网关的架构优势

自建 OHTTP 网关面临加解密开销与额外网络跳数带来的延迟。Cloudflare 依托其任播（Anycast）边缘网络，将网关部署于全球每台服务器，最小化中继到网关的链路耗时。若用户已使用 Cloudflare CDN，网关解密后可直接在同机转发至源站，省去网关到源站回程延迟。该设计将 OHTTP 的操作负担从客户转移至厂商。

适用部署模式

客户可按架构选择：

  1. 使用 Cloudflare OHTTP Relay 并自建网关：适合源站不在 Cloudflare 且具备自治能力的场景。
  2. 使用 Cloudflare OHTTP Gateway 配合第三方中继：适合源站已在 Cloudflare、或需托管网关降低延迟与运维成本。

对读者的意义与技术解读

对于运维与网络工程师，OHTTP 改变了 HTTP 流量的可见性模型。在排查跨境链路或 CDN 加速效果时，传统工具（如本站 HTTP 测速）测量的 TTFB、TLS 握手耗时将因新增中继/网关跳数而发生变化。理解 OHTTP 架构有助于：

  • 正确区分延迟来源：网关解密计算与边缘网络位置可能影响首包时间，需结合 traceroute 与 HTTP 探针定位瓶颈。
  • 评估隐私与性能权衡：开启 OHTTP 后，源站日志不再含真实 IP，监控告警需依赖网关透传的元数据或匿名标识。
  • 利用 Cloudflare 同机解密特性优化 SLA：若业务已在其 CDN 上，可预期较低且稳定的附加延迟。

建议在使用本站 HTTP(S) 测速前，明确目标站点是否启用 OHTTP 类代理，以免将中继延迟误判为源站性能。