Cloudflare OHTTP 网关封闭测试拒绝解密经其网络传入请求，强化隐私协议隔离设计

一句话结论

Cloudflare OHTTP 网关拒绝解密经由其自身网络传入的请求，通过架构限制确保中继与网关运营方隔离，强化隐私保护有效性。

关键要点

• Cloudflare OHTTP Gateway 处于封闭测试阶段，作为托管端点代表源服务器解密 Oblivious HTTP（OHTTP）请求。
• 若请求来自 Cloudflare Workers 或通过 Cloudflare 代理的主机，网关拒绝解密，防止中继与网关同属一家公司导致隐私失效。
• 网关绑定特定区域，监听固定路径 https://your-zone.com/.well-known/ohttp-gateway，仅允许标准 OHTTP 与分块 OHTTP（后者性能更优）。
• OHTTP 仅保护网络层隐私，请求正文内容（如会话令牌、用户邮箱）仍可能暴露，需用户自行避免明文身份数据。
• Cloudflare 计划于 2026 年秋季正式推出该网关，自助服务版本已开启封闭测试，作为付费增值组件销售。

背景与事实

Cloudflare 启动 OHTTP Gateway 封闭测试，旨在提供托管端点解密 Oblivious HTTP 请求。根据 RFC 9458 标准，OHTTP 将请求拆分：客户端使用 HPKE 加密内部 HTTP 请求至网关公钥，通过中继服务器转发；中继服务器无法读取内容，网关解密后转发至应用。该方案要求中继服务器与应用服务器由互不相关方运营，否则客户端 IP 与请求内容将暴露于同一服务商。

作者 Lara Schull 与 Akshat Mahajan 强调，Cloudflare 拒绝解密经由其自身网络（如 Workers 或代理主机）传入的请求，避免中继与网关同属 Cloudflare 导致隐私失效。Cloudflare 未提供中继服务器，称其“可在任何基础设施提供商运行且实现简单”，难点在于“向用户承诺不检查包含客户端标识符的日志”。现有 Privacy Gateway 已更名为 Cloudflare OHTTP Relay 以区分方案。

网关技术规格：绑定区域监听固定路径，管理 HPKE 密钥并通过 GET 请求提供公钥；支持标准与分块 OHTTP（推荐分块）；Cloudflare Access 在解密前运行，中继服务器可通过双向 TLS、静态凭据或自定义逻辑认证。Cloudflare 明确 OHTTP 仅保护网络层，请求正文内容不在此范围内。

影响分析

对中文开发者与从业者而言，Cloudflare OHTTP 网关的架构限制直接决定了隐私保护的有效边界。团队若在中继前部署 Cloudflare Workers 或通过 Cloudflare 代理流量，将触发网关拒绝解密，导致隐私保护失效。这意味着采用 OHTTP 的方案必须确保中继服务器与网关由不同实体运营，实际部署时需评估现有架构是否满足此隔离要求。对于自建中继服务器的团队，Cloudflare 将“日志不检查”作为核心难点，但中文开发者需额外考虑国内网络环境下的合规性与运营主体分离问题，避免隐私承诺因架构耦合而落空。

适用边界

此结论仅适用于 OHTTP 方案中“中继服务器与网关由独立运营方”的前提条件。若请求经 Cloudflare Workers 或其代理主机传入，网关拒绝解密导致隐私保护失效；若团队使用非独立中继服务器（如自托管于 Cloudflare 区域），同样不适用隐私承诺。OHTTP 不适用于有状态请求（OHTTP 设计针对无状态场景），且请求正文中的身份数据（会话令牌、邮箱等）仍可能暴露，需手动脱敏。此外，OHTTP 非通用浏览隐私方案，仅适用于已知网关的特定遥测、推断或查询服务。

孤本观察

Cloudflare 通过架构级拒绝违规配置而非技术手段绕过，表明其将隐私承诺视为产品核心而非附加功能，此设计虽限制灵活部署，但为行业提供了可验证的隔离标准。

来源：InfoQ 中文 AI