On July 27, 2026, the Cloudflare Research team released pvcli — a console client for private network protocols. Externally, it resembles "curl for OHTTP": the same command style, but instead of a regular request, the tool assembles a three-way encrypted exchange, in which the receiving server cannot see your IP, and the intermediary node cannot see the content of the request. The code is under Apache 2.0, with plans for support of MASQUE and Privacy Pass.
For the proxy industry, this is not "just another release on GitHub." It is the first convenient way to get hands-on experience with a protocol stack that has been quietly adopted by Apple, Google, Mozilla, and Meta for several years — and which is regularly presented as a "proxy replacement." Let's break down what it actually is and honestly answer the main question: does this stack address the needs for which people purchase residential and mobile proxies? Spoiler: no, and the reason is architectural, not "we haven't matured yet."
What was revealed: pvcli in detail
pvcli is written in Rust and can be installed with a single command using cargo install --git. According to the README, it is an HTTP/2 and HTTP/3 client supporting GET and POST, TLS 1.3, and HPKE encryption (RFC 9180). The main mode is Oblivious HTTP: the client specifies the first hop (relay) and gateway, and the tool performs all the cryptography and packaging into binary HTTP on its own.
- Regular request:
pvcli https://example.com/cdn-cgi/trace, with the flag--http3— over QUIC. - OHTTP mode:
pvcli --ohttp --first-hop https://relay --proxy https://gateway -X POST https://target. - Classic proxying:
pvcli -x https://proxy.example.com https://target.example.com— meaning HTTP CONNECT is still present.
The authors honestly warn: the software is experimental and has not undergone an audit, post-quantum HPKE is not yet supported, and some specifications have not even become RFCs. This is a debugging tool, not a ready-to-use product for production. And that is precisely why it is interesting: previously, testing someone else's OHTTP integration could only be done with custom code in Swift or Rust.
Oblivious HTTP: separate and do not dominate
OHTTP was standardized as RFC 9458 on January 12, 2024. The idea is simple to the point of elegance: to separate the knowledge of "who you are" and "what you are requesting" between two independent participants.
- The client encrypts the request with an ephemeral key on the public key of the gateway — a new key pair is generated for each request.
- The relay (oblivious relay) sees your IP address but receives ciphertext: it physically cannot read where and what you are asking about.
- The gateway decrypts the request and forwards it to the origin, but sees the IP of the relay, not yours.
The key guarantee is unlinkability: the origin cannot link two of your requests together. The key limitation is trust: if the relay and gateway collude or are operated by the same entity, all privacy collapses. The NCC Group noted practical challenges in audits — key rotation, rate limiting, and allowances for network delays.
The protocol is already operational in production, and the list is impressive:
- Apple — Private Cloud Compute for requests to Apple Intelligence and Enhanced Visual Search in "Photos"; OHTTP support in Swift appeared in August 2024.
- Google — Privacy Sandbox, k-anonymity, and URL verification in Safe Browsing without revealing the IP; Fastly acts as the relay.
- Mozilla — collecting performance metrics for Firefox without user identification.
- Meta — Private Processing for Meta AI in WhatsApp (2025), also through the Fastly relay.
- Flo — "anonymous mode" of the cycle tracker based on Cloudflare Privacy Gateway since 2022.
Gateways, in addition to Cloudflare and Fastly, are also being developed by the Internet Security Research Group in the Divvi Up service. This means the infrastructure is real, not just theoretical.
MASQUE: now this looks like a proxy
The second part of the stack that Cloudflare promises to add to pvcli is MASQUE. This is a family of protocols from the IETF working group that integrates proxying within HTTP:
- RFC 9298 (August 2022), CONNECT-UDP — UDP proxying within HTTP; the client sends an extended CONNECT with
:protocol: connect-udp, and the proxy translates QUIC DATAGRAM frames into UDP packets. - RFC 9484 (October 2023), CONNECT-IP — a full-fledged IP level: raw IP packets are wrapped in HTTP Datagrams, and an HTTP/3 server turns into a VPN gateway capable of handling TCP, UDP, and ICMP simultaneously.
Both specifications require a fallback to HTTP/2 where QUIC and UDP are blocked at the network level — which regularly happens in corporate and provider networks. Essentially, MASQUE is what modern "private relays" at the operating system level are built upon, where traffic passes through two independent hops: the first knows you but does not know the recipient, while the second does the opposite.
Privacy Pass: an anonymous pass instead of a captcha
The third component is Privacy Pass, standardized by three documents: RFC 9576 (architecture), RFC 9577 (HTTP authentication scheme), and RFC 9578 (token issuance protocols, privately and publicly verifiable). The logic is in two steps: issuance — you prove once that you are a human or a trusted client and receive a batch of blindly signed tokens; redemption — you present the token to the site, and it lets you through without a captcha, having no way to link the token to the moment of issuance.
This is precisely the mechanism behind the idea of "giving good bots legitimate access" — which also underlies signed agents and Web Bot Auth. The trend is the same: to separate network identity (IP) from access rights (token, signature).
Will this replace proxies? An analysis without illusions
Every time news from this stack comes out, the thesis "why use proxies now that OHTTP exists" arises. The problem is that private protocols and proxies solve different tasks, and substituting one for the other breaks down on four points.
1. OHTTP only works where the site has deployed it
This is not an overlay over the internet, but rather opt-in from the recipient's side: the gateway is set up and configured by the origin (or its contractor). You cannot "access via OHTTP" on any marketplace or social network — there simply is no gateway there. All the listed implementations are companies hiding the IPs of their own users from their own backends. For data collection from a third-party site, the mechanism is fundamentally inapplicable.
2. The exit point is a data center, and everyone knows it
Even if a gateway exists, the request exits from the address of Cloudflare, Fastly, or ISRG. These are known ASN hosting providers with public ranges. Anti-bot systems rank IPs by network type, and the address of a cloud relay receives the same scoring as any other data center address. You have achieved privacy from the origin, but "looking like a regular home user" is not achieved. This is precisely what residential proxies with real provider addresses and mobile pools from operator CGNAT networks are responsible for.
3. No geography, rotation, or sticky sessions
Proxy infrastructure provides what private protocols lack by design: the choice of country, region, and operator, managed IP rotation, sticky sessions for the desired number of minutes, and different pools for different accounts. OHTTP does not allow you to choose "to exit from Germany, from a specific ISP's network" — there is simply no concept of an exit point at your disposal. For checking local issuance, regional pricing, or working with geo-restricted content, this is an insurmountable difference.
4. The trust model is different
OHTTP protects against linking requests to a specific origin provided that the relay and gateway are independent. Proxies protect against the site seeing your real address and network profile. The first is about the privacy of telemetry and user requests, while the second is about access and load distribution. The tasks only partially overlap, and "moving" from one to the other is impossible.
What of this is actually useful in practice
- If you are a product developer sending telemetry or requests to your API — OHTTP through Privacy Gateway or Divvi Up genuinely reduces the volume of personal data collected and simplifies discussions with lawyers. pvcli now allows you to debug this without writing a client from scratch.
- If you are collecting public data — the stack changes nothing: the exit point and its reputation remain your responsibility. For mass parsing, the working combination remains — data center proxies with rotation on loyal platforms and residential proxies where serious anti-bot measures are in place.
- If you are working with multiple accounts — private protocols do not solve the isolation issue: sessions on platforms are linked not only by IP but also by browser fingerprint and behavior. The difference between the IP layer and the identity layer is discussed in the material on the differences between proxies and VPNs.
- If you are automating access "legally" — this is where you should pay close attention. Privacy Pass and signed agents are moving towards a model where bots are granted access based on the presented token, rather than "looking like a human." This is the most promising part of the news.
Conclusion
The release of pvcli is a good indicator of maturity: private protocols have moved out of the research preprint stage and acquired debugging tools. OHTTP, MASQUE, and Privacy Pass are indeed reshaping how the internet handles client addresses, and in a couple of years, "the site sees your IP" will cease to be an axiom for user traffic.
However, for those collecting data, managing multiple accounts, or checking regional issuance, nothing changes. Private protocols hide you from whom you came by invitation. Proxies are needed where invitations are not issued — and there, the type of network, address reputation, and pool quality still matter. It is wise to keep an eye on Privacy Pass as a future legal channel for bots while maintaining a proper proxy infrastructure for real needs.