2026年7月27日，Cloudflare Research团队发布了pvcli——一个用于私有网络协议的控制台客户端。从外观上看，它是“OHTTP的curl”：相同的命令风格，但与普通请求不同，该工具收集三方加密交换，其中接收服务器无法看到您的IP，而中间节点无法看到请求的内容。代码遵循Apache 2.0协议，未来计划支持MASQUE和Privacy Pass。
对于代理行业来说，这并不是“又一个GitHub上的发布”。这是一个方便的方式，可以亲自体验已经被Apple、Google、Mozilla和Meta悄然实施了几年的协议栈，并且常常被宣传为“代理的替代品”。我们来分析一下，实际上它是什么，并诚实地回答一个主要问题：这个协议栈是否解决了人们购买住宅和移动代理的需求。剧透：没有，原因在于架构，而不是“还没成熟”。
具体开放了什么：pvcli的细节
pvcli是用Rust编写的，通过cargo install --git一条命令安装。根据README，它是一个支持GET和POST的HTTP/2和HTTP/3客户端，支持TLS 1.3和HPKE加密（RFC 9180）。主要模式是Oblivious HTTP：客户端指定第一个跳点（中继）和网关，工具自动执行所有加密和打包为二进制HTTP。
- 普通请求：
pvcli https://example.com/cdn-cgi/trace，带有标志--http3——在QUIC之上。 - OHTTP模式：
pvcli --ohttp --first-hop https://relay --proxy https://gateway -X POST https://target。 - 经典代理：
pvcli -x https://proxy.example.com https://target.example.com——也就是说，HTTP CONNECT依然存在。
作者诚实地警告：该软件是实验性的，尚未经过审计，后量子HPKE目前不支持，部分规范甚至还没有成为RFC。这是一个调试工具，而不是用于生产的成品。正因如此，它才引人注目：以前检查他人的OHTTP集成只能通过自己用Swift或Rust编写的代码。
Oblivious HTTP：分而治之
OHTTP于2024年1月12日作为RFC 9458标准化。这个想法简单而优雅：将“你是谁”和“你在请求什么”的知识分散到两个独立的参与者之间。
- 客户端使用网关的公钥加密请求，使用的是短暂密钥——每个请求生成一对新的密钥。
- 中继（oblivious relay）可以看到您的IP地址，但收到的是密文：它在物理上无法读取您询问的内容和目的地。
- 网关解密请求并将其转发到源，但看到的是中继的IP，而不是您的。
关键保证是unlinkability：源无法将您的两个请求关联起来。关键限制是信任：如果中继和网关串通或由同一运营商控制，所有隐私都将崩溃。NCC Group在审计中也指出了实际的困难——密钥轮换、速率限制和网络延迟的容忍度。
在生产环境中，该协议已经在运行，名单相当可观：
- Apple——用于Apple Intelligence和“照片”中的增强视觉搜索的Private Cloud Compute；OHTTP在Swift中的支持于2024年8月推出。
- Google——Privacy Sandbox、k-匿名性和在Safe Browsing中验证URL而不暴露IP；Fastly充当中继。
- Mozilla——在不识别用户的情况下收集Firefox的性能指标。
- Meta——WhatsApp中Meta AI的Private Processing（2025），同样通过Fastly中继。
- Flo——基于Cloudflare Privacy Gateway的周期追踪器的“匿名模式”，自2022年以来。
除了Cloudflare和Fastly，Internet Security Research Group还在Divvi Up服务中部署了网关。也就是说，基础设施是真实的，而不是纸上谈兵。
MASQUE：这已经像代理了
Cloudflare承诺在pvcli中添加的协议栈的第二部分是MASQUE。这是IETF工作组的一组协议，将代理功能集成到HTTP内部：
- RFC 9298（2022年8月），CONNECT-UDP——在HTTP内部进行UDP代理；客户端发送扩展的CONNECT，带有
:protocol: connect-udp，而代理将QUIC DATAGRAM帧转换为UDP包。 - RFC 9484（2023年10月），CONNECT-IP——已经是完整的IP层：原始IP包被封装在HTTP数据报中，HTTP/3服务器变成了一个能够同时处理TCP、UDP和ICMP的VPN网关。
这两个规范要求在QUIC和UDP在网络层被切断的地方回退到HTTP/2——这在企业和提供商网络中经常发生。从本质上讲，MASQUE是现代“私有中继”在操作系统级别构建的基础，其中流量经过两个独立的跳点：第一个知道您，但不知道接收者，第二个则相反。
Privacy Pass：匿名通行证代替验证码
第三个组成部分是Privacy Pass，通过三份文件标准化：RFC 9576（架构）、RFC 9577（HTTP认证方案）和RFC 9578（令牌发行协议，私密和公开可验证）。逻辑分为两个步骤：发行——您一次性证明自己是人类或受信任的客户，并获得一批盲签名的令牌；兑换——您将令牌提交给网站，网站在没有验证码的情况下放行您，无法将令牌与发行时刻关联。
这正是“给好的机器人合法进入”的理念背后的机制——它也是签名代理和Web Bot Auth的基础。趋势是相同的：将网络身份（IP）与访问权限（令牌、签名）分开。
这会取代代理吗？无幻想的分析
每当这个协议栈发布新闻时，都会出现“如果有OHTTP，为什么还需要代理”的论调。问题在于，私有协议和代理解决的是不同的问题，用一个替代另一个会在四个方面崩溃。
1. OHTTP仅在网站自行部署时有效
这不是覆盖互联网的层，而是接收方的选择加入：网关自行启动和配置源（或其承包商）。无法通过OHTTP访问任意市场或社交网络——那里根本没有网关。所有列出的实施都是公司在保护其自有用户的IP不被其自有后端看到。对于从第三方网站收集数据，该机制原则上不适用。
2. 出口点是数据中心，所有人都知道
即使有网关，外部请求也会从Cloudflare、Fastly或ISRG的地址发出。这些是具有公共范围的知名ASN托管提供商。反机器人系统根据网络类型对IP进行评级，云中继的地址获得与任何其他数据中心地址相同的评分。您从源处获得了隐私，但“看起来像普通家庭用户”——没有。正是为此，住宅代理和运营商CGNAT网络的移动池发挥作用。
3. 没有地理位置、轮换和粘性会话
代理基础设施提供了私有协议在设计上没有的东西：选择国家、地区和运营商，管理IP的轮换，粘性会话持续所需的分钟数，不同的池用于不同的账户。OHTTP不允许您选择“从德国、特定ISP网络中退出”——根本没有您可以控制的出口点。对于检查本地结果、区域价格或处理地理限制内容，这是不可弥补的差异。
4. 信任模型不同
OHTTP在中继和网关独立的情况下保护请求不与特定源关联。代理保护您不被网站看到真实地址和网络配置。前者是关于用户的遥测和请求隐私，后者是关于访问和负载分配。任务仅部分重叠，且“迁移”从一种到另一种是不可能的。
哪些内容在实践中真正有用
- 如果您是发送遥测或请求到自己API的产品开发者——通过Privacy Gateway或Divvi Up，OHTTP确实减少了收集的个人数据量，并简化了与律师的沟通。pvcli现在允许您在不从头编写客户端的情况下进行调试。
- 如果您收集公共数据——该协议栈没有改变：出口点及其声誉仍然是您的任务。对于大规模解析，仍然有效的组合是数据中心代理与在忠诚平台上轮换的住宅代理。
- 如果您处理多个账户——私有协议无法解决隔离问题：平台上的会话不仅通过IP关联，还通过浏览器指纹和行为关联。IP层与身份层之间的差异在代理和VPN的区别材料中进行了分析。
- 如果您在“白名单”中自动化访问——在这里需要仔细关注。Privacy Pass和签名代理朝着一种模型发展，在这种模型中，机器人通过提供的令牌获得进入，而不是通过“看起来像人类”。这是新闻中最有前景的部分。
结论
pvcli的发布是成熟度的良好指标：私有协议已经从研究预印本阶段走出，并获得了调试工具。OHTTP、MASQUE和Privacy Pass确实重塑了互联网如何处理客户地址，几年后“网站看到您的IP”将不再是用户流量的公理。
但是，对于那些收集数据、管理多个账户或检查区域结果的人来说，情况并没有改变。私有协议让您远离您受邀访问的对象。代理在没有邀请的地方是必需的——而在那里，网络类型、地址声誉和池的质量仍然是决定性因素。明智的做法是关注Privacy Pass作为未来机器人的合法通道，同时保持正常的代理基础设施以应对现实。