一句话：OHTTP（Oblivious HTTP，隐匿 HTTP）是一种隐私协议，让"请求从哪来"和"请求了什么"分别落在两个不同的服务商手里，任何单独一方都拼不出完整画像。它已由 IETF 标准化为 RFC。
原理：客户端用目标服务的公钥，把整个 HTTP 请求加密成一个密文包（用的是 HPKE 混合公钥加密）。密文包先发给中继（relay）：中继能看到你的 IP，但看不懂里面是什么；它只负责原样转发给网关（gateway）。网关用私钥解开，读到了请求内容，但它看到的是中继的 IP，不知道真实来源。响应再沿原路加密回来。
生活化一点：你把信锁进一个只有收件人能打开的盒子，交给快递站。快递站知道"盒子来自哪个小区"，但打不开；收件人读得到信，却不知道是谁寄的。两边各拿一半，谁都拿不到"寄件人 + 内容"这一对。
和相邻概念的区别：
- HTTPS 只防路上被偷看，服务器依然同时知道你的 IP 和你的请求。
- VPN 把来源藏到出口后面，代价是 VPN 服务商同时看到两样。
- Tor 靠多层中继做通用匿名，慢；OHTTP 只有一跳、延迟低，专门服务无状态的 HTTP 请求。
| 方案 | 谁看到来源 | 谁看到内容 |
|---|---|---|
| HTTPS | 服务器 | 服务器 |
| VPN | VPN 服务商 | VPN 服务商 |
| OHTTP | 中继 | 网关 |
在 AI 调用里的适用边界：适合"一问一答、不带身份"的请求，比如把用户问题转给第三方模型 API，或智能体调用搜索、工具接口，不希望"哪台机器问了什么"被关联起来。Cloudflare 这类厂商把中继和网关做成托管服务后，自己搭两套设施的门槛低了很多（具体能力以官方页面为准）。
不适合：需要登录态、Cookie、API Key 的接口——身份本来就写在请求里，网关一解开就看见了，OHTTP 白忙一场；计费和限流也得在网关侧另想办法。它也不防时序分析，请求大小和时间仍可能被两边对上号；中继与网关一旦串通，或干脆是同一家运营，隐私直接归零。它是降低关联性，不是让你隐身。
对普通人：多分清一件事——加密和匿名不是一回事。HTTPS 让内容别人听不见，OHTTP 让"谁在问"和"问什么"分开保管。用不用得上，取决于你想防的是谁。