Cloudflare 的 OHTTP 网关有个「自伤」设定：来自自家网络的请求，它拒绝解密

隐私方案最常见的失败方式，是要求所有环节都由同一家公司提供，然后声称自己是中立的。Cloudflare 这次的做法相反：它给新上线的 OHTTP 网关加了一条限制——如果请求来自 Cloudflare Workers，或者经由 Cloudflare 代理转发，网关将拒绝解密。

这条限制看起来是在拒绝自己的客户，实际上是在保护方案成立的前提。

一分钟速览

• Cloudflare 启动 Oblivious HTTP 网关封闭测试，提供托管解密端点；
• OHTTP 已标准化为 RFC 9458，用 HPKE 加密请求内容，把 IP 与内容拆到两个环节；
• 中继服务器能看到客户端 IP，但读不到内容；网关能解密，但只看到中继的地址；
• 当请求来自 Cloudflare 自家网络时，网关拒绝解密，否则识别者与解密者会是同一家公司；
• Cloudflare 不提供中继，需用户自建或由第三方运营；现有隐私网关已更名为 OHTTP 中继。

把身份和内容拆到两个人手里

Oblivious HTTP 的思路可以用一句老话概括：不要把钥匙和地址交给同一个人。客户端用网关公钥把内部请求加密，先发给中继；中继知道你是谁，但拆不开包；网关拆得开包，但只知道请求来自中继。

这套结构只有在两个跳点由不同运营方控制时才有效。如果中继和网关同属一家公司，两条信息在数据库里一join，匿名性就没了。Cloudflare 拒绝解密自家流量，本质上是在拒绝一种「看起来很安全」的配置。

真正的成本不在网关

部署这道加密其实不难，难的是有人愿意当中继，并且愿意承诺不看日志。Cloudflare 明确表示不提供中继服务，理由是组件本身简单、任何基础设施商都能跑；真正的挑战是「向用户做出可验证的承诺，即不会检查包含客户端标识符的日志」。

这也是所有隐私基础设施的共同软肋：密码学可以证明数据没被篡改，却证明不了运营方没有偷偷记录。这也解释了为什么 Hacker News 上的讨论很快从协议本身转向了运营与商业模型。

保护只到网络层

Cloudflare 在说明里写得很清楚：OHTTP 只在网络层提供隐私保护，不触及请求正文的内容。如果客户端把会话令牌、邮箱地址塞进加密的请求体里，网关运营方照样能拿到本该被隐藏的身份。

换句话说，这套机制解决的是「谁在访问」，不是「访问了什么」。应用自身的日志策略、第三方脚本、CDN 侧的指纹识别，仍然可以重建用户画像。讨论区里最尖锐的问题正是这个：如果启用了 OHTTP，而 WAF 依然依赖 TLS 指纹做拦截，那么客户端元数据实际上还是被平台读取了，只是没有传给源站。

趋势：隐私工程开始进入「可验证」阶段

接下来值得关注的是三件事。第一，客户端支持。如果没有现成的浏览器、代理或 SDK 支持 OHTTP，开发者接入成本会非常高。第二，中继的商业模式。自建中继给少数人用，反而会让中继运营方知道这批人都在访问什么，匿名集合太小就失去意义。第三，审计与证明。远程证明、日志透明度、第三方审计，会逐渐从加分项变成准入项。

对需要处理敏感查询的团队来说，OHTTP 值得评估，但要先想清楚威胁模型：你要防的是网络运营商、源站，还是一个想知道谁在查什么的平台。这三者的答案不同，架构也不同。