Cloudflare OHTTP 网关封闭测试：隐私代理的新边界
OHTTP 是什么
Oblivious HTTP（OHTTP）已作为 RFC 9458 标准化，其核心思路是将一次 HTTP 请求拆成两段独立传输：客户端用 HPKE 将内部请求加密为网关公钥，把密封后的载荷发给中继服务器；中继只能看到客户端 IP，读不到请求内容；网关负责解密，再将明文请求转发给应用服务器。这样，应用能看到内容但只能看到中继地址，中继能看到客户端 IP 但读不到内容——前提是这两跳由不同运营商运营。
Cloudflare OHTTP 网关：做什么、不做什么
Cloudflare 在封闭测试中推出了 OHTTP Gateway，一个托管的解密端点。网关绑定到用户区域，监听固定路径 https://your-zone.com/.well-known/ohttp-gateway，通过 GET 请求提供 HPKE 公钥。客户端可以用与请求 IP 不同的 IP 获取密钥，标准 OHTTP 和分块 OHTTP 均支持，但出于性能考虑建议使用分块模式。
值得注意的是，Cloudflare 将原有的 Privacy Gateway 更名为 Cloudflare OHTTP Relay，以此区分中继和网关两个角色。Cloudflare 明确不提供中继服务，理由是它"可以在任何基础设施提供商那里运行，而且实现简单"。真正的难点在于能否向用户做出可验证的承诺——不会检查包含客户端标识符的日志。
最关键的限制：拒绝 Cloudflare 代理的请求
最受关注的设计决策并非功能，而是一条硬性限制：如果请求来自 Cloudflare Workers 或通过 Cloudflare 代理的主机，OHTTP 网关将拒绝解密。
原因很直接：OHTTP 模型要求中继和应用服务器由互不相关的独立运营方运营。如果在网关前部署 Worker，或让中继流量也走 Cloudflare 代理，那么识别客户端的跳点和解密跳点都将流过同一家公司的服务，隐私保护形同虚设。因此 Cloudflare 选择直接拒绝这种违规配置，而非默默放行。
安全边界：只保护网络层
Cloudflare 在公告中明确说明，OHTTP "在网络层提供隐私保护，而且不会触及请求内部的正文内容"。这意味着：
- 保护范围：客户端 IP 地址与请求内容的关联被切断
- 不保护的内容：请求正文中的可识别信息（如邮箱、用户名、会话令牌）
如果在密封请求中放入会话令牌或邮箱地址，网关运营商仍能获取该协议本应隐藏的身份信息。Cloudflare Access 在解密之前运行，中继服务器本身可通过双向 TLS、静态服务凭据或自定义外部逻辑进行身份验证。
社区讨论：SOCKS5 对比与落地挑战
Hacker News 上的讨论呈现两极分化。评论者 gsnedders 将 OHTTP 与 SOCKS5 代理做了详细对比：
- OHTTP 的适用场景较窄：无状态请求，不希望网关关联同一客户端的多个请求
- SOCKS5 的代价：每个请求需建立新 TCP 连接，无法使用 TLS 会话恢复或 0-RTT，且 SOCKS5 未加密，目标地址以明文传输
- OHTTP 的优势：将 TLS 指纹识别攻击面与网关隔离，允许客户端-中继和中继-网关之间建立长连接，对 DNS over HTTPS 等工作负载是显著的延迟优化
评论者 johnhess 概括了威胁模型："你与谁通信并不敏感，'某人曾与他们讨论过 X'这一事实也不敏感，但同时知晓这两点则会构成风险。"
评论者 maayank 将其类比为"带有预设网关的两跳 Tor 电路"，区别在于 OHTTP 需要客户端有意识地通过该协议与已知网关通信，并非通用的浏览隐私方案。
对开发者的实用建议
适合谁用：希望获取遥测数据、进行推断或提供查询功能，但又无法将每次请求与特定用户关联的应用供应商。Cloudflare 援引了 Flo Health 的"匿名模式"和苹果"私有云计算"作为生产部署案例。
需要注意的问题：
- 客户端支持：目前是否有现成的代理、隧道或 VPN 软件支持 OHTTP 传输协议，是开发者采用的关键问题
- 自托管中继的价值：仅为少数人运行的中继服务器会背离设计初衷，因为服务方将知晓所有请求均来自这个小群体
- WAF 交互：启用 OHTTP 后，依赖 TLS 指纹识别的 WAF 是否还能正常工作，以及客户端元数据是否会被 Cloudflare 读取但不传递给应用服务器
- IP 封禁机制：基于 IP 地址的封禁如何在隐私保护下维持
- 成本考量：该服务将作为付费增值组件销售，但公告未公布具体价格。评论者 freedomben 指出，如果目标是普遍改善隐私，付费隐私插件"将是一种糟糕的激励机制"
总结
Cloudflare OHTTP 网关将于今年秋季正式推出，目前自助服务版本已开启封闭测试。加密机制本身没有成为争论焦点——没有人质疑拆分机制是否如描述那样运作。真正的问题在于：客户端生态是否成熟、自托管中继的实际价值、以及一旦客户端元数据消失后 Cloudflare 平台功能面临的连锁影响。
对于评估该方案的团队，核心考量是：你的应用场景是否是无状态请求？你是否能接受网关密钥泄露意味着中继可解密已记录流量（无前向保密）？以及你是否有能力向用户做出可验证的隐私承诺？