Il 27 luglio 2026, il team di Cloudflare Research ha reso disponibile pvcli — un client da console per protocolli di rete privati. Esternamente è "curl per OHTTP": lo stesso stile di comandi, ma invece di una normale richiesta, lo strumento raccoglie uno scambio crittografato a tre vie, in cui il server ricevente non vede il tuo IP e il nodo intermedio non vede il contenuto della richiesta. Il codice è sotto Apache 2.0, e nei piani c'è il supporto per MASQUE e Privacy Pass.
Per l'industria dei proxy, non si tratta di "un altro rilascio su GitHub". È il primo modo conveniente per esplorare il stack di protocolli che Apple, Google, Mozilla e Meta stanno implementando silenziosamente da alcuni anni — e che viene regolarmente presentato come "sostituto dei proxy". Analizziamo cosa c'è realmente e rispondiamo onestamente alla domanda principale: questo stack risolve i problemi per cui le persone acquistano proxy residenziali e mobili? Spoiler: no, e la ragione è architettonica, non "non ci siamo ancora arrivati".
Cosa è stato aperto: pvcli nei dettagli
pvcli è scritto in Rust e si installa con un solo comando tramite cargo install --git. Secondo il README, è un client HTTP/2 e HTTP/3 con supporto per GET e POST, TLS 1.3 e crittografia HPKE (RFC 9180). La modalità principale è Oblivious HTTP: il client specifica il primo hop (relay) e il gateway, mentre lo strumento gestisce autonomamente tutta la crittografia e l'imballaggio in HTTP binario.
- Richiesta normale:
pvcli https://example.com/cdn-cgi/trace, con il flag--http3— sopra QUIC. - Modalità OHTTP:
pvcli --ohttp --first-hop https://relay --proxy https://gateway -X POST https://target. - Proxy classico:
pvcli -x https://proxy.example.com https://target.example.com— quindi HTTP CONNECT non è scomparso.
Gli autori avvertono onestamente: il software è sperimentale e non ha passato un audit, la crittografia post-quantistica HPKE non è ancora supportata, e alcune specifiche non sono nemmeno diventate RFC. È uno strumento di debug, non un prodotto pronto per la produzione. Ed è proprio per questo che è interessante: in passato, verificare l'integrazione OHTTP di qualcun altro era possibile solo con codice proprio in Swift o Rust.
Oblivious HTTP: separa e non dominare
OHTTP è stato standardizzato come RFC 9458 il 12 gennaio 2024. L'idea è semplice fino all'eleganza: separare la conoscenza di "chi sei" e "cosa stai chiedendo" tra due partecipanti indipendenti.
- Il client crittografa la richiesta con una chiave effimera sulla chiave pubblica del gateway — per ogni richiesta viene generata una nuova coppia di chiavi.
- Relay (relay oblio) vede il tuo indirizzo IP, ma riceve un testo crittografato: non può fisicamente leggere dove e di cosa stai chiedendo.
- Gateway decrittografa la richiesta e la inoltra all'origin, ma vede l'IP del relay, non il tuo.
La garanzia chiave è unlinkability: l'origin non può collegare due delle tue richieste tra loro. La limitazione principale è la fiducia: se il relay e il gateway si accordano o sono sotto lo stesso operatore, tutta la privacy svanisce. NCC Group ha notato negli audit anche le difficoltà pratiche — rotazione delle chiavi, limitazione del tasso e tolleranze per i ritardi di rete.
In produzione, il protocollo è già operativo e l'elenco è impressionante:
- Apple — Private Cloud Compute per le richieste di Apple Intelligence e Enhanced Visual Search in "Foto"; il supporto per OHTTP in Swift è stato introdotto nell'agosto 2024.
- Google — Privacy Sandbox, k-anonimato e verifica degli URL in Safe Browsing senza rivelare l'IP; Fastly funge da relay.
- Mozilla — raccolta di metriche sulle prestazioni di Firefox senza identificazione dell'utente.
- Meta — Private Processing per Meta AI in WhatsApp (2025), sempre tramite relay Fastly.
- Flo — "modalità anonima" del tracker del ciclo basata su Cloudflare Privacy Gateway dal 2022.
I gateway, oltre a Cloudflare e Fastly, sono gestiti dal Internet Security Research Group nel servizio Divvi Up. Quindi l'infrastruttura è reale, non solo cartacea.
MASQUE: questo assomiglia già a un proxy
La seconda parte dello stack, che Cloudflare promette di aggiungere a pvcli, è MASQUE. Questo è un insieme di protocolli del gruppo di lavoro IETF che porta il proxying all'interno di HTTP:
- RFC 9298 (agosto 2022), CONNECT-UDP — proxying UDP all'interno di HTTP; il client invia un CONNECT esteso con
:protocol: connect-udp, e il proxy trasforma i frame QUIC DATAGRAM in pacchetti UDP. - RFC 9484 (ottobre 2023), CONNECT-IP — già un livello IP completo: pacchetti IP grezzi vengono incapsulati in HTTP Datagrams, e un server HTTP/3 diventa un gateway VPN, capace di gestire simultaneamente TCP, UDP e ICMP.
Entrambe le specifiche richiedono un fallback su HTTP/2 dove QUIC e UDP sono bloccati a livello di rete, il che accade regolarmente nelle reti aziendali e dei provider. Fondamentalmente, MASQUE è ciò su cui si basano i moderni "relay privati" a livello di sistema operativo, dove il traffico passa attraverso due hop indipendenti: il primo ti conosce, ma non conosce il destinatario, il secondo viceversa.
Privacy Pass: un pass anonimo invece di un captcha
Il terzo mattoncino è Privacy Pass, standardizzato da tre documenti: RFC 9576 (architettura), RFC 9577 (schema di autenticazione HTTP) e RFC 9578 (protocolli di emissione di token, verificabili privatamente e pubblicamente). La logica è in due fasi: emissione — dimostri una volta di essere un umano o un cliente fidato e ricevi un pacchetto di token firmati in modo cieco; riscatto — presenti il token al sito, e lui ti lascia passare senza captcha, senza possibilità di collegare il token al momento dell'emissione.
Questo è esattamente il meccanismo che sta dietro all'idea di "dare accesso legittimo ai buoni bot" — che è alla base di agenti firmati e Web Bot Auth. La tendenza è la stessa: separare l'identità di rete (IP) dai diritti di accesso (token, firma).
Sostituirà questo i proxy? Analisi senza illusioni
Ogni volta che esce una notizia su questo stack, riemerge il tema "perché ora i proxy, se c'è OHTTP". Il problema è che i protocolli privati e i proxy risolvono problemi diversi, e la sostituzione di uno con l'altro si rompe su quattro punti.
1. OHTTP funziona solo dove il sito lo ha implementato
Non è un overlay su Internet, ma opt-in da parte del destinatario: il gateway viene sollevato e configurato dall'origin stesso (o dal suo appaltatore). Non puoi "entrare tramite OHTTP" in un marketplace o in un social network a caso — semplicemente non c'è un gateway. Tutte le implementazioni elencate sono aziende che nascondono l'IP dei propri utenti dai propri backend. Per raccogliere dati da un sito esterno, il meccanismo non è applicabile in linea di principio.
2. Il punto di uscita è un data center, e tutti lo sanno
Anche se il gateway esiste, la richiesta esce con l'indirizzo di Cloudflare, Fastly o ISRG. Questi sono ASN noti dei provider di hosting con intervalli pubblici. I sistemi anti-bot classificano gli IP in base al tipo di rete, e l'indirizzo del relay cloud ottiene esattamente lo stesso punteggio di qualsiasi altro indirizzo di data center. Hai ottenuto privacy dall'origin, ma non "sembrare un normale utente domestico". È proprio per questo che ci sono proxy residenziali con indirizzi reali dei provider e pool mobili delle reti CGNAT degli operatori.
3. Nessuna geografia, rotazione e sessioni sticky
L'infrastruttura proxy offre ciò che i protocolli privati non hanno per design: scelta del paese, regione e operatore, rotazione IP gestita, sessioni sticky per il numero necessario di minuti, diversi pool per diversi account. OHTTP non ti consente di scegliere "uscire dalla Germania, dalla rete di un ISP specifico" — non c'è nemmeno il concetto di punto di uscita a tua disposizione. Per controllare l'emissione locale, i prezzi per regione o lavorare con contenuti geo-limitati, questa è una differenza ineliminabile.
4. Il modello di fiducia è diverso
OHTTP protegge dal collegamento delle richieste a un origin specifico a condizione che il relay e il gateway siano indipendenti. I proxy proteggono dal fatto che il sito veda il tuo vero indirizzo e profilo di rete. Il primo riguarda la privacy della telemetria e delle richieste dell'utente, il secondo riguarda l'accesso e la distribuzione del carico. Le problematiche si sovrappongono solo parzialmente, e il "trasferimento" da uno all'altro non è possibile.
Cosa di tutto ciò sarà realmente utile nella pratica
- Se sei uno sviluppatore di un prodotto che invia telemetria o richieste al proprio API — OHTTP tramite Privacy Gateway o Divvi Up riduce realmente il volume dei dati personali raccolti e semplifica il dialogo con gli avvocati. pvcli ora consente di debugare questo senza scrivere un client da zero.
- Se raccogli dati pubblici — lo stack non cambia nulla: il punto di uscita e la sua reputazione rimangono un tuo compito. Per il parsing di massa, la combinazione funziona ancora — proxy di data center con rotazione su piattaforme leali e residenziali dove è attivato un serio anti-bot.
- Se lavori con più account — i protocolli privati non risolvono la questione dell'isolamento: le sessioni sulle piattaforme sono collegate non solo dall'IP, ma anche dall'impronta del browser e dal comportamento. La differenza tra il livello IP e il livello di identità è stata analizzata nel materiale sulle differenze tra proxy e VPN.
- Se automatizzi l'accesso "in bianco" — qui vale la pena prestare attenzione. Privacy Pass e agenti firmati si dirigono verso un modello in cui al bot viene dato accesso tramite il token presentato, non per "sembrare umano". Questa è la parte più promettente della notizia.
Conclusione
La scoperta di pvcli è un buon indicatore di maturità: i protocolli privati sono usciti dalla fase di ricerca e hanno acquisito strumenti di debug. OHTTP, MASQUE e Privacy Pass stanno davvero rimodellando il modo in cui Internet gestisce l'indirizzo del cliente, e tra un paio d'anni "il sito vede il tuo IP" smetterà di essere un assioma per il traffico degli utenti.
Ma per chi raccoglie dati, gestisce più account o verifica l'emissione per regione, nulla cambia. I protocolli privati ti nascondono da chi sei andato per invito. I proxy sono necessari dove non vengono rilasciati inviti — e lì continuano a contare il tipo di rete, la reputazione dell'indirizzo e la qualità del pool. È saggio tenere d'occhio Privacy Pass come futuro canale legale per i bot e mantenere parallelamente una normale infrastruttura proxy per il reale.
```