Oblivious HTTP：怎样让中继不知道你请求的具体内容？
TL;DR
Oblivious HTTP 将客户端 IP 与请求内容分交给中继和网关处理，减少单一角色同时掌握两类信息的机会。本文讲解端到端路径、串通与元数据风险，以及它并非完整匿名网络的原因。
Oblivious HTTP 将客户端 IP 与请求内容分交给中继和网关处理，减少单一角色同时掌握两类信息的机会。本文讲解端到端路径、串通与元数据风险，以及它并非完整匿名网络的原因。
使用在线服务时，服务端往往能从请求内容知道你在查什么，也能从连接地址知道请求来自哪里。若把这两类信息交给不同角色处理，就有机会减少单一服务方掌握的用户信息。Oblivious HTTP（OHTTP，隐匿式 HTTP）正是这样一种请求转发模式：客户端把加密请求交给中继，再由网关解密并转发到目标服务。
客户端先把 HTTP 请求封装并加密，使只有目标网关能够解开内容。它把密文发给 relay（中继）；中继看到客户端的网络地址和数据包大小等传输元信息，却看不到加密后的具体请求。中继再把密文转给 gateway（网关）；网关能看到请求内容并向服务端发起请求，但在正常部署中并不直接看到客户端的原始 IP 地址。
隐私收益来自角色分离：中继知道“谁连来了”，却不知道“具体问了什么”；网关知道“具体请求了什么”，却不直接知道“是谁发起的”。如果两者由不同运营者管理、彼此不串通，单方能关联的信息就会减少。OHTTP 适合需要隐藏客户端来源的少量 HTTP 请求，例如某些配置获取、匿名测量或隐私敏感的服务查询。
然而，它不是完整匿名网络。中继和网关仍可能看到时间、请求大小、流量模式等元数据；目标服务也会看到网关发来的请求，可能通过账户登录、Cookie 或请求内容识别用户。若中继与网关串通，或都由同一方控制，信息分割的意义会减弱。客户端还要信任网关正确处理请求，并考虑重放防护、限流和滥用控制。
OHTTP 的设计更像“盲转信封”：中继只知道寄件人地址，网关负责拆信并送达，但希望寄件人不直接暴露给收件方。要让这种隐私成立，不能让信封尺寸或送达时间过于独特；实际部署可能需要批处理、填充、缓存或其他策略，降低元数据关联风险。
所以，OHTTP 不是让整个浏览过程都变匿名，也不是 VPN 的替代品。它把某个请求的 IP 信息与内容信息拆分给两个服务角色，减少单点观察能力。评估它时，应询问谁运营中继和网关、请求是否带有个人标识、元数据保留多久，以及两方是否可能共享日志。
