Cloudflare lança pvcli: OHTTP, MASQUE e Privacy Pass serão substituídos por proxies em 2026?

```html

No dia 27 de julho de 2026, a equipe de Pesquisa da Cloudflare lançou publicamente o pvcli — um cliente de console para protocolos de rede privados. Visualmente, é como um "curl para OHTTP": o mesmo estilo de comandos, mas em vez de uma solicitação comum, a ferramenta coleta uma troca criptografada de três vias, onde o servidor receptor não vê seu IP, e o nó intermediário não vê o conteúdo da solicitação. O código está sob a licença Apache 2.0, e há planos para suporte ao MASQUE e ao Privacy Pass.

Para a indústria de proxies, isso não é "mais um lançamento no GitHub". É a primeira maneira conveniente de experimentar o conjunto de protocolos que Apple, Google, Mozilla e Meta vêm implementando silenciosamente há alguns anos — e que frequentemente é apresentado como "uma substituição para proxies". Vamos analisar o que realmente está acontecendo e responder honestamente à pergunta principal: esse conjunto resolve as questões para as quais as pessoas compram proxies residenciais e móveis? Spoiler: não, e a razão é arquitetônica, não "ainda não chegamos lá".

O que exatamente foi lançado: pvcli em detalhes

O pvcli é escrito em Rust e pode ser instalado com um único comando usando cargo install --git. Segundo o README, é um cliente HTTP/2 e HTTP/3 com suporte a GET e POST, TLS 1.3 e criptografia HPKE (RFC 9180). O modo principal é o Oblivious HTTP: o cliente especifica o primeiro salto (relay) e o gateway, enquanto a ferramenta realiza toda a criptografia e empacotamento em HTTP binário.

• Solicitação comum: pvcli https://example.com/cdn-cgi/trace, com a flag --http3 — sobre QUIC.
• Modo OHTTP: pvcli --ohttp --first-hop https://relay --proxy https://gateway -X POST https://target.
• Proxy clássico: pvcli -x https://proxy.example.com https://target.example.com — ou seja, o HTTP CONNECT não desapareceu.

Os autores alertam honestamente: o software é experimental e não passou por auditoria, o HPKE pós-quântico ainda não é suportado, e parte das especificações ainda não se tornaram RFC. É uma ferramenta de depuração, não um produto pronto para produção. E é exatamente por isso que é interessante: antes, verificar a integração OHTTP de terceiros só era possível com código próprio em Swift ou Rust.

Oblivious HTTP: separar e não dominar

O OHTTP foi padronizado como RFC 9458 em 12 de janeiro de 2024. A ideia é simples até a elegância: separar o conhecimento de "quem você é" e "o que você está pedindo" entre dois participantes independentes.

1. O cliente criptografa a solicitação com uma chave efêmera na chave pública do gateway — uma nova chave é gerada para cada solicitação.
2. Relay (relay oblivioso) vê seu endereço IP, mas recebe o texto cifrado: ele fisicamente não pode ler para onde e sobre o que você está perguntando.
3. Gateway descriptografa a solicitação e a envia para a origem, mas vê o IP do relay, não o seu.

A garantia chave é a unlinkability: a origem não pode vincular duas de suas solicitações entre si. A limitação chave é a confiança: se o relay e o gateway conspirarem ou estiverem sob um único operador, toda a privacidade se desmorona. O NCC Group observou em auditorias as dificuldades práticas — rotação de chaves, limitação de taxa e permissões para atrasos de rede.

O protocolo já está em produção, e a lista é impressionante:

• Apple — Private Cloud Compute para solicitações de Apple Intelligence e Enhanced Visual Search em "Fotos"; o suporte ao OHTTP em Swift surgiu em agosto de 2024.
• Google — Privacy Sandbox, k-anonimato e verificação de URL no Safe Browsing sem revelar o IP; o Fastly atua como relay.
• Mozilla — coleta de métricas de desempenho do Firefox sem identificação do usuário.
• Meta — Private Processing para Meta AI no WhatsApp (2025), também através do relay Fastly.
• Flo — "modo anônimo" do rastreador de ciclo baseado no Cloudflare Privacy Gateway desde 2022.

Os gateways, além da Cloudflare e Fastly, são fornecidos pelo Internet Security Research Group no serviço Divvi Up. Ou seja, a infraestrutura é real, não apenas no papel.

MASQUE: isso já parece um proxy

A segunda parte do conjunto, que a Cloudflare promete adicionar ao pvcli, é o MASQUE. Esta é uma família de protocolos do grupo de trabalho IETF que traz o proxy para dentro do HTTP:

• RFC 9298 (agosto de 2022), CONNECT-UDP — proxy UDP dentro do HTTP; o cliente envia um CONNECT estendido com :protocol: connect-udp, e o proxy converte os quadros QUIC DATAGRAM em pacotes UDP.
• RFC 9484 (outubro de 2023), CONNECT-IP — já um nível IP completo: pacotes IP brutos são encapsulados em HTTP Datagrams, e o servidor HTTP/3 se transforma em um gateway VPN, capaz de lidar simultaneamente com TCP, UDP e ICMP.

Ambas as especificações exigem um fallback para HTTP/2 onde QUIC e UDP são bloqueados no nível da rede, o que acontece regularmente em redes corporativas e de provedores. Essencialmente, o MASQUE é a base sobre a qual são construídos os modernos "relays privados" de nível de sistema operacional, onde o tráfego passa por dois saltos independentes: o primeiro sabe quem você é, mas não sabe o destinatário, o segundo, ao contrário.

Privacy Pass: um passe anônimo em vez de captcha

O terceiro componente é o Privacy Pass, padronizado em três documentos: RFC 9576 (arquitetura), RFC 9577 (esquema de autenticação HTTP) e RFC 9578 (protocolos de emissão de tokens, verificáveis de forma privada e pública). A lógica é em duas etapas: emissão — você prova uma vez que é humano ou um cliente confiável e recebe um pacote de tokens assinados de forma cega; resgate — você apresenta o token ao site, e ele o permite passar sem captcha, sem ter a capacidade de vincular o token ao momento da emissão.

Esse é exatamente o mecanismo que sustenta a ideia de "dar acesso legítimo a bons bots" — que também está na base de agentes assinados e Web Bot Auth. A tendência é a mesma: separar a identidade na rede (IP) e os direitos de acesso (token, assinatura).

Isso substituirá os proxies? Análise sem ilusões

Toda vez que uma notícia desse conjunto é divulgada, surge a tese "por que agora precisamos de proxies, se temos OHTTP". O problema é que os protocolos privados e os proxies resolvem tarefas diferentes, e a substituição de um pelo outro falha em quatro pontos.

1. OHTTP funciona apenas onde o site o implementou

Isso não é uma sobreposição sobre a internet, mas um opt-in por parte do destinatário: o gateway é levantado e configurado pela própria origem (ou seu contratante). Não é possível "entrar através do OHTTP" em um marketplace ou rede social aleatória — simplesmente não há gateway lá. Todas as implementações mencionadas são empresas que escondem o IP de seus próprios usuários de seus próprios backends. Para coletar dados de um site de terceiros, o mecanismo não é aplicável em princípio.

2. O ponto de saída é um data center, e todos sabem disso

Mesmo que o gateway exista, a solicitação sai com o endereço da Cloudflare, Fastly ou ISRG. Esses são ASN conhecidos de provedores de hospedagem com faixas públicas. Sistemas anti-bot classificam IPs por tipo de rede, e o endereço de um relay em nuvem recebe exatamente a mesma pontuação que qualquer outro endereço de data center. Você obteve privacidade da origem, mas "parecer como um usuário doméstico comum" — não. É exatamente por isso que existem proxies residenciais com endereços reais de provedores e pools móveis de redes CGNAT operadoras.

3. Sem geografia, rotação e sessões persistentes

A infraestrutura de proxies oferece o que os protocolos privados não têm por design: escolha de país, região e operador, rotação gerenciada de IPs, sessões persistentes por um número necessário de minutos, diferentes pools para diferentes contas. O OHTTP não permite que você escolha "sair da Alemanha, da rede de um ISP específico" — não há conceito de ponto de saída à sua disposição. Para verificar a entrega local, preços por região ou trabalhar com conteúdo geograficamente restrito, essa é uma diferença insuperável.

4. O modelo de confiança é diferente

O OHTTP protege contra a vinculação de solicitações a uma origem específica, desde que o relay e o gateway sejam independentes. O proxy protege contra o fato de que o site verá seu verdadeiro endereço e perfil de rede. O primeiro trata da privacidade da telemetria e das solicitações do usuário, o segundo trata do acesso e da distribuição de carga. As tarefas se sobrepõem apenas parcialmente, e a "mudança" de um para o outro não é possível.

O que disso realmente será útil na prática

• Se você é um desenvolvedor de produto que envia telemetria ou solicitações para sua API — OHTTP através do Privacy Gateway ou Divvi Up realmente reduz a quantidade de dados pessoais coletados e simplifica a conversa com os advogados. O pvcli agora permite depurar isso sem escrever um cliente do zero.
• Se você coleta dados públicos — o conjunto não muda nada: o ponto de saída e sua reputação continuam sendo sua responsabilidade. Para scraping em massa, a combinação ainda é funcional — proxies de data center com rotação em plataformas leais e residenciais onde há um sério anti-bot.
• Se você trabalha com várias contas — os protocolos privados não resolvem a questão da isolação: as sessões nas plataformas estão vinculadas não apenas pelo IP, mas também pela impressão do navegador e comportamento. A diferença entre a camada de IP e a camada de identidade é discutida no material sobre as diferenças entre proxies e VPNs.
• Se você automatiza o acesso "de forma legítima" — aqui é onde vale a pena prestar atenção. O Privacy Pass e os agentes assinados estão indo para um modelo onde o bot recebe acesso com base no token apresentado, e não por "parecer humano". Esta é a parte mais promissora da notícia.

Conclusão

A abertura do pvcli é um bom indicador de maturidade: os protocolos privados saíram da fase de pré-impressão de pesquisa e ganharam ferramentas de depuração. O OHTTP, MASQUE e Privacy Pass realmente estão reformulando a forma como a internet lida com o endereço do cliente, e em alguns anos "o site vê seu IP" deixará de ser uma máxima para o tráfego de usuários.

Mas para aqueles que coletam dados, gerenciam várias contas ou verificam a entrega por regiões, nada muda. Os protocolos privados escondem você daquele a quem você foi convidado. Proxies são necessários onde os convites não são emitidos — e lá, ainda são decisivos o tipo de rede, a reputação do endereço e a qualidade do pool. É sensato acompanhar o Privacy Pass como um futuro canal legal para bots e, ao mesmo tempo, manter uma infraestrutura de proxy adequada para o presente.