IETF RFC 9458 · 互联网隐私保护新基建

🕶️ Cloudflare OHTTP Gateway：彻底斩断 IP 关联的 “双盲”隐私网关

普通 HTTP 请求像把明信片塞进透明信封，服务端一眼看光你的 IP、指纹和地理位置。OHTTP 打造中继与网关双权分立，谁也别想完整拼凑你的真实身份！

🎯 核心主线：为什么普通的 HTTPS 加密防不住“用户追踪”？

大家总以为用了 https:// 就安全了。但对应用服务器（如健康 App、AI 推理端点、反欺诈服务）来说，你的网络请求每次都会赤裸裸地暴露：来源 IP 地址、TLS 客户端指纹、ASN 运营商与城市位置。哪怕你注册时匿了名，服务器通过固定 IP 与指纹一聚合，依然能轻松把你的每一次敏感查询关联到同一个人！

❌ 传统直连 / 普通代理

单点全透视风险：要么服务器全知道，要么代理商全掌握！

  • 💣 直连服务器：直接掌握你的 Client IP + 完整请求明文
  • 💣 普通代理 / VPN：代理商既看到你的 IP，解密或抓包后也能看清你要去哪
  • 💣 信任归于单点：任何一方被攻破或出卖日志，用户无处遁形
VS
✅ OHTTP 双盲分立架构

IETF RFC 9458 标准：中继（Relay）与网关（Gateway）互相独立盲盒运作！

  • 🛡️ 中继（Relay）：只看得到客户端 IP，但请求内容被 HPKE 加密成乱码，根本看不懂！
  • 🛡️ 网关（Gateway）：负责解密请求发给业务服务器，但来源 IP 永远是中继的，根本不知道是谁发来的！
  • 🛡️ 双权分立：没有任一方能同时看到【身份】与【内容】！

💡 5 岁也能懂的比喻：无记名投票箱与黑衣信使

传统的快递送信：你自己把信送到店主手里，店主不但看到了信的内容，还看到了你本人长相和工牌（IP 泄露）。
OHTTP 双盲投递： 1. 你先把信写好放进一把只有店主才能打开的密码铁盒（HPKE 加密）；
2. 你把铁盒交给一个中立的跑腿小哥（Relay 中继）。跑腿小哥认识你（看到 IP），但根本撬不开铁盒；
3. 跑腿小哥把铁盒送到店里的智能拆箱台（Gateway 网关）。店主用私钥打开铁盒读信，但眼前只有铁盒，根本没见过你本人！

🧩 OHTTP 双盲流量流转拓扑（Double-Blind Architecture）

客户端利用网关的公钥完成端到端混合公钥加密（HPKE），中继盲转，网关边缘解密，业务端零改动：

📱 终端用户客户端 Client (IP: 192.0.2.33) 获取网关 HPKE 公钥 /.well-known/ohttp-keys 外层包装加密胶囊 Encrypted Request 密文转发 🔀 OHTTP 中继 (Relay) 第三方独立运营 (如 Apple/合作伙伴) 👀 仅看到：用户真实 IP 🙈 密文一团黑，无法解密 剥除用户 IP，换上中继 IP 盲转给目标网关 中继 IP 🚪 OHTTP Gateway Cloudflare 全球边缘节点 🙈 只能看到中继 IP 🔓 用 HPKE 私钥拆开明文 内置 Access 防滥用鉴权 支持 Chunked 渐进流式 🖥️ 业务后端 App Origin 普通 HTTP 完全无需 感知加密解密
⚔️ 产品矩阵厘清：Cloudflare OHTTP Relay 与 OHTTP Gateway 有何区别？

Cloudflare 以前推出过 Privacy Gateway（现在正式更名为 Cloudflare OHTTP Relay），这次推出的则是 OHTTP Gateway。这两者该怎么选？

产品与角色 主要职责与看得到的数据 谁来运营另一端（分权约束） 最佳适用场景
Cloudflare OHTTP Relay
(原 Privacy Gateway)		 盲转发中继：只看得到用户 IP，看不到请求明文。剥除用户真实特征后推给外部网关。 客户必须在外部自建或使用第三方 OHTTP Gateway。 应用后端在 AWS / 自建机房，不想用 Cloudflare CDN，只想借 Cloudflare 全球网络隐藏客户端 IP。
Cloudflare OHTTP Gateway
(本次最新发布)		 解密终结网关：只看得到中继 IP，看不到用户 IP。用 HPKE 解密后发给业务后端。 中继必须由非 Cloudflare 的第三方（如 Apple 或合作伙伴）运营。 后端本身就在 Cloudflare（CDN / Workers），接入第三方隐私生态（如 Apple LiveCallerID、私有云 AI 推理），希望零运维获得托管解密网关。

⚠️ 关键安全护栏：防串通（Non-Collusion）物理隔离

OHTTP 的隐私核心是“两权分立”。如果中继是 Cloudflare，网关又是 Cloudflare，那 Cloudflare 就能把两边的日志拼起来，隐私模型直接瓦解！因此 Cloudflare 施加了硬性规则：OHTTP Gateway 会直接拒绝解密来自 Cloudflare Workers 或 Cloudflare 代理节点的请求，从底层代码级杜绝自产自销，严格保证绝对的双盲！

🎮 交互试验台：切换视角体验 OHTTP 的“双盲盲盒”

点击下方按钮，切换到不同节点的视角，亲眼看看各自能掌握哪些数据：

// 点击上方按钮查看各节点所能捕获的信息矩阵...
🔑

全自动 HPKE 密钥轮转

网关全面托管混合公钥加密（HPKE）密钥对，客户端直接通过标准 /.well-known/ohttp-gateway 接口拉取最新公钥，无需人工配置密钥同步与过期轮换。

🛡️

前置 Cloudflare Access 零信任

因为网关看不到最终用户，只能信任中继。Cloudflare 让 Access 策略在密文解密前先行运行，支持 mTLS 双向证书与凭证白名单，防止恶意爬虫滥用你的网关。

⚡

分块流式处理 (Chunked OHTTP)

完全支持 IETF 最新的 Chunked OHTTP 草案，允许大请求和流式响应按分块渐进式加解密，大幅降低海量数据传输的端到端首包延迟。