如今，在线隐私的重担过多地落在用户身上。为避开第三方跟踪器或定向广告，用户被建议使用 VPN、禁用 cookie、装广告拦截器。一些应用开发者掌握的用户信息超出本意：一次客户端与服务器交互会留下 IP 地址、TLS 指纹等痕迹。隐匿 HTTP（Oblivious HTTP，OHTTP）是互联网工程任务组（IETF）标准，让应用后端接收请求时看不到用户 IP 地址。今年秋季，Cloudflare 推出 Cloudflare OHTTP 网关（Cloudflare OHTTP Gateway），客户可将其作为付费附加项启用。

如今，终端用户承担了过多的在线隐私负担。为避免第三方跟踪或定向广告，用户被指导使用 VPN、禁用 cookie 或安装广告拦截器。而一些应用开发者最终知道了比预期更多的用户隐私：典型的客户端-服务器交互会留下用户数据轨迹，如客户端 IP 或 TLS 指纹。这种可见性是个负担。

因此 Cloudflare 构建基础设施，帮助开发者将隐私植入应用。OHTTP 是一项 IETF 标准（RFC 9458），旨在让应用后端接收 HTTP 请求时看不到用户 IP。

今年秋天，我们将推出 Cloudflare OHTTP Gateway。客户能将其作为付费附加项在区域（zone）上启用，点几下就开始接收 OHTTP 流量。通过我们的表单注册候补名单。

扩展我们的 OHTTP 产品套件

在 OHTTP 中，请求经过两个独立运作的跳点：中继（relay）和网关（gateway）。中继盲转加密请求，向应用服务器隐藏客户端标识；网关执行解封请求和封装响应的加密工作，使服务器能像处理普通 HTTP 那样处理 OHTTP。中继与网关间的信任分离至关重要：确保没有单方同时看到客户端标识和请求内容。

2022 年，我们推出了 OHTTP 中继产品 Privacy Gateway，让客户为用户提供更隐私的体验。例如 Flo Health 在应用的匿名模式中使用 OHTTP，Apple 的 Private Cloud Compute 用 OHTTP 将 AI 推理请求与用户身份解联。但那些已将服务器保护在 Cloudflare 之后的客户，无法再使用 Cloudflare 运营的中继——他们需要的是 OHTTP 网关。

运营中继的经验让我们看到，大规模构建并运维安全、高性能的 OHTTP 网关有多难。今天我们推出自服务 Cloudflare OHTTP Gateway 的封闭测试，并将“Privacy Gateway”重命名为“Cloudflare OHTTP Relay”以更好区分两产品。

现在，需要信任分离 OHTTP 架构的客户有两种选项：

1. 使用 Cloudflare OHTTP Relay（原 Cloudflare Privacy Gateway）并自己运行网关。若应用服务器托管在 Cloudflare 之外且你能自跑网关，这是最佳。
2. 使用 Cloudflare 新 OHTTP Gateway 加第三方中继。若应用服务器已在 Cloudflare 之后（如我们的 CDN 或 Workers），正接受第三方 OHTTP 请求（如 Apple LiveCallerID），或想要托管网关以最小化延迟和运维开销，这是最佳。

我们致力于提高整个互联网的隐私门槛，相信像 OHTTP 这样的协议在足够易用时能有所帮助。扩展 OHTTP 产品套件、让可信隐私基础设施触达更广大互联网一直是我们的目标。

我们为何构建 Cloudflare OHTTP Gateway

自推出 OHTTP Relay 产品以来，我们观察到几点。

首先，开发者对易获取、可用的隐私基础设施胃口渐长。隐私导向应用的开发者想默认将网络隐私植入应用，但做起来仍比应有的难。

其次，我们了解到客户构建运维 OHTTP 网关可能很难。任何代理架构都会因请求需多跳绕网引入延迟。再加上解密请求和加密响应的成本，自建 OHTTP 设置的延迟打击可能很显著。我们很适合解此问题：支撑 1.1.1.1 和 iCloud Private Relay 等快速可靠隐私基础设施的模块，让我们成为 OHTTP 网关的好归属。借助 Cloudflare 的 anycast 方法，OHTTP Gateway 将运行在 Cloudflare 全球边缘网的每台服务器上，最小化中继到网关的跳延迟。若用我们 CDN，用户请求可由 Gateway 解密并由你的应用服务器在同一 Cloudflare 机器上解析，节省网关到源站延迟。

最后，回想 OHTTP 隐私模型要求中继和应用服务器由独立、非共谋方运营。我们想为客户提供尽可能好的隐私基础设施选项范围。以前，在 Cloudflare 后保护应用服务器的开发者不能用我们 OHTTP Relay，因为 Cloudflare 会同时看到客户端元数据和解密请求内容，破坏 OHTTP 隐私模型。现在，开发者可选择 Cloudflare OHTTP Relay 还是 Gateway 更契合其架构。

OHTTP 入门

典型的客户端与应用服务器交互会泄露客户端信息。客户端与服务器通话时，服务器学到客户端 IP，因为发送数据的每个数据包都标了源 IP——类似信封上的“寄件人”。服务器还能根据支持的 TLS 版本或密码套件等属性“指纹”客户端。这些信号让服务器能将多个请求链回同一用户。

但若我想构建一个真不大了解用户的 app 呢？例如：Flo Health 想构建匿名模式，让用户访问个人健康数据而不被关联到可能的用户标识。

OHTTP 引入一个名为“中继”的代理，在客户端和服务器间转发请求响应，以对服务器混淆客户端身份。中继看到 IP 和 TLS 指纹等客户端标识，但在转发前剥离它们。这防止服务器将多请求链回同一用户，意味着请求内容无法与用户 IP 关联。

普通客户端-服务器交换可能暴露客户端如下信息：

• ipAddress: 192.0.2.33（客户端 IP 地址）
• ASN: 7922
• tlsCipher: AEAD-CHACHA20-POLY1305-SHA256（可能唯一）
• tlsVersion: TLSv1.3
• Country: US
• Region: California（客户端位置）
• City: Campbell

先经 OHTTP 中继的请求，向接收请求的服务器只暴露中继信息：

• ipAddress: 128.62.37.13（中继 IP 及指纹）
• ASN: 18
• tlsCipher: AEAD-AES-128-GCM-SHA256
• tlsVersion: TLSv1.3
• Country: US
• Region: Texas（中继位置）
• City: Austin

这意味着每个请求中，服务器学不到终端用户的位置和 TLS 指纹。此外，若许多不同用户都经中继发请求，服务器无法区分谁发的哪个，限制其将应用活动追踪回单一终端用户的能力。这形成强隐私边界。

OHTTP 与基础转发代理的真正区别在于客户端与服务器间的数据加密。请求和响应使用混合公钥加密（HPKE）封装，仅客户端和服务器能看到明文，中继只看到密文乱码。一个“网关”坐于中继和服务器之间处理所有这些加密——解封请求、封装响应——而应用服务器只处理普通 HTTP。

这创造出“双盲”隐私模型：中继只看客户端标识；网关和服务器只看请求内容；无一方兼看两者。

我们如何构建 OHTTP Gateway

在构建 OHTTP 网关即服务时，我们的目标是将安全、高性能的隐私基础设施带给更广大互联网。性能和轻松入门至关重要。因此，我们将 Gateway 构建为部署在全球网络上的灵活服务。只需点几下，你就能在区域启用 Gateway，开始向 https://your-zone.com/.well-known/ohttp-gateway 发送 OHTTP。我们会自动扩缩服务，你无需操心容量。

我们还记下了其他用户需求，源自看到 OHTTP Relay 客户自运维网关时遇到的痛点。

第一：我们想为你的应用服务器尽量抽离 OHTTP 的复杂性。我们希望开发者能开始接收 OHTTP，同时若选择也可继续接收常规 HTTP 流量。因此，我们将 Gateway 设计为区域的一项特性，客户端向区域上的 /.well-known/ohttp-gateway 端点发送格式合规的 OHTTP 请求。我们支持标准与分块 OHTTP——并推荐分块 OHTTP 以获得更好性能，因为它让我们能增量（“分块”）处理请求。

我们的 Gateway 服务将拦截每个请求、解密它、向你的应用服务器发出子请求，并向客户端返回加密响应。所有非 OHTTP 请求将直达你的服务器，不调用 Gateway。

将 Gateway 绑定到区域也让我们保护其免受滥用。向你的区域 example.com 发请求的客户端可能发往 foo.example.com 或 bar.example.com，但不能发 wikipedia.com。无需你操心，这就防止未授权客户端用你区域作跳板打其他域名。

第二：无缝密钥管理关键。网关需维护公开 HPKE 密钥配置以使客户端能加密请求，但安全管理密钥是挑战。因此我们设计 Gateway 为客户全权管理所有密钥，并作为对 /.well-known/ohttp-gateway 的 GET 请求的响应提供公钥。为更强隐私，客户端可用不同于请求网关的 IP 下载密钥。

第三：网关需能认证中继。因为 Gateway（按设计）对发送某请求的客户端知之甚少，它信任中继来认证客户端并负责转发流量。但如何确保只有可信中继能向你的网关发流量？

我们设计的 Gateway 让 Cloudflare 的零信任网络访问产品 Cloudflare Access 在请求被解密前运行，使你能用任何标准 Access 策略认证入站流量并保护 Gateway 免受滥用。选项包括双向 TLS、静态服务凭证和自定义外部逻辑。

最后：错误难免，我们预想到客户可能意外将中继和网关都跑在 Cloudflare 上而破坏 OHTTP 隐私模型。因此，为保持 OHTTP 的信任分离并确保 Cloudflare 永不同时看到客户端身份和解密的内部请求，我们的 Gateway 将拒绝解密来自 Cloudflare Workers 或 Cloudflare 上代理主机的请求。

何时 OHTTP Gateway 比 OHTTP Relay 更合适？

若你想用 Cloudflare 的 OHTTP 产品套件，但疑惑为何选 Gateway 而非 Relay，这里有几条考量。

首先，你想将应用服务器放在 Cloudflare 上吗——比如在我们的 CDN 后或基于 Workers 构建？如果是，OHTTP Gateway 更契合以确保遵循 OHTTP 隐私模型。

其次，你的用例是什么？如果你想接收来自第三方客户端和中继的 OHTTP 请求——例如使用 Apple 的 LiveCallerID SDK——那么 OHTTP Gateway 可能是更好解法。

入门

如果你有功能请求或想注册候补名单以便产品发布时获通知，请通过表单注册。

然后，你需要实现 OHTTP 客户端。参见 ohttp.info 或我们的示例客户端库获取入门示例。构建客户端时要注意一点：OHTTP 提供网络层隐私，不碰内部请求体。因此，为保留用户隐私，你需注意不在请求体中发送身份信息（例如用户邮箱或用户名）。

接下来，你需要自带中继。中继可跑在任何基础设施提供商上，且很简单：这里有示例代码。挑战和你可能想要专用 OHTTP 中继提供商的理由在于，可向用户可验证地承诺你不检查带客户端标识的日志。否则，你就能将中继处的客户端与服务器处的解密请求关联起来。

最后，一旦你的 OHTTP 部署上线，看看我们的 pvcli 客户端，协助测试和调试。

我们兴奋于将易用的隐私基础设施带给各地开发者。如果你想试用新 OHTTP Gateway 并提升在线隐私标准，请联系我们。

多数人对Cloudflare推出的OHTTP隐私中继方案持怀疑态度，认为将用户数据交由这家大公司中转反而集中了隐私风险；少数人则指出隐藏IP本身并非治本，或对普通用户的可用性存疑。

认为Cloudflare介入反而加剧隐私风险

• 用户数据从原站日志转入Cloudflare中心化网络，其本身就有行为捕获争议，中间网关设计与匿名SOCKS5无异，并未消除中间人。认可度：较多人
• > 若想保护用户隐私，应避免使用Cloudflare这类追踪网络，没有比确保自身日志匿名更好的方案（@ZiiS）

认为普通用户难以使用且无法真正防追踪

• 目标人群缺乏配置能力，而恶意黑客会滥用导致渠道被污名化；当前网页依赖脚本且指纹手段繁多，追踪根本无法杜绝。认可度：较多人
• > 需要它的人没精力设置，恶意者却会滥用，最终让整个来源被视作暗巷般的危险地带（@dzink）

担忧与现有安全机制冲突

• 依赖TLS指纹的防火墙可能失效，且隐藏源IP后难以按IP封禁滥用者，运维管控面临挑战。认可度：少数人
• > 若启用OHTTP，Cloudflare的WAF是否因无法读TLS指纹而失效，还是它读了却不传给应用服务器？（@arshxyz）

认为隐藏IP是治标不治本

• 共享IP若是隐私隐患，应从根本上解决该问题而非掩盖地址。认可度：少数人

指出对嵌入第三方跟踪的网站无效

• 若目标网页自身嵌入了Google跟踪代码，该方案并不能阻止原站层面的追踪。认可度：少数人

有价值的补充

• 该架构给人强烈的洋葱路由（TOR）既视感（@indeyets）
• 已有自服务中继实现可供参考，例如 oblivious.network（@wferrell）
• 社区情绪调侃：有用户讽刺“干得漂亮，CIA！”以表达对其隐私卫士动机的不信任（@nc0）