El 27 de julio de 2026, el equipo de Cloudflare Research lanzó al público pvcli — un cliente de consola para protocolos de red privados. A simple vista, es "curl para OHTTP": el mismo estilo de comandos, pero en lugar de una solicitud común, la herramienta recopila un intercambio cifrado de tres vías, en el que el servidor receptor no ve tu IP, y el nodo intermedio no ve el contenido de la solicitud. El código está bajo Apache 2.0, y se planea el soporte para MASQUE y Privacy Pass.
Para la industria de proxies, esto no es "otro lanzamiento en GitHub". Es la primera manera conveniente de experimentar con el stack de protocolos que Apple, Google, Mozilla y Meta han estado implementando silenciosamente durante varios años — y que regularmente se presenta como "una alternativa a los proxies". Analicemos qué hay realmente detrás de esto y respondamos honestamente a la pregunta principal: ¿este stack resuelve las necesidades por las cuales las personas compran proxies residenciales y móviles? Spoiler: no, y la razón es arquitectónica, no "porque aún no hemos llegado".
Qué se ha abierto: pvcli en detalle
pvcli está escrito en Rust y se instala con un solo comando a través de cargo install --git. Según el README, es un cliente HTTP/2 y HTTP/3 con soporte para GET y POST, TLS 1.3 y cifrado HPKE (RFC 9180). El modo principal es Oblivious HTTP: el cliente especifica el primer salto (relay) y el gateway, y la herramienta realiza toda la criptografía y empaquetado en HTTP binario por sí misma.
- Solicitud normal:
pvcli https://example.com/cdn-cgi/trace, con la bandera--http3— sobre QUIC. - Modo OHTTP:
pvcli --ohttp --first-hop https://relay --proxy https://gateway -X POST https://target. - Proxy clásico:
pvcli -x https://proxy.example.com https://target.example.com— es decir, HTTP CONNECT no ha desaparecido.
Los autores advierten honestamente: el software es experimental y no ha pasado auditoría, el HPKE post-cuántico aún no está soportado, y parte de las especificaciones ni siquiera se han convertido en RFC. Es una herramienta de depuración, no un producto listo para producción. Y es precisamente por eso que es interesante: antes, verificar la integración OHTTP de otros solo se podía hacer con tu propio código en Swift o Rust.
Oblivious HTTP: divide y no reines
OHTTP fue estandarizado como RFC 9458 el 12 de enero de 2024. La idea es tan simple que es elegante: separar el conocimiento de "quién eres" y "qué estás pidiendo" entre dos participantes independientes.
- El cliente cifra la solicitud con una clave efímera sobre la clave pública del gateway — se genera un nuevo par de claves para cada solicitud.
- Relay (relay oblivioso) ve tu dirección IP, pero recibe un texto cifrado: no puede leer físicamente a dónde y sobre qué estás preguntando.
- Gateway descifra la solicitud y la envía al origen, pero ve la IP del relay, no la tuya.
La garantía clave es unlinkability: el origen no puede vincular tus dos solicitudes entre sí. La limitación clave es la confianza: si el relay y el gateway se confabulan o están bajo un mismo operador, toda la privacidad se desmorona. El NCC Group ha señalado en auditorías las dificultades prácticas — rotación de claves, limitación de tasa y tolerancias en retrasos de red.
En producción, el protocolo ya está funcionando, y la lista es impresionante:
- Apple — Private Cloud Compute para solicitudes de Apple Intelligence y Enhanced Visual Search en "Fotos"; el soporte para OHTTP en Swift apareció en agosto de 2024.
- Google — Privacy Sandbox, k-anonimidad y verificación de URL en Safe Browsing sin revelar la IP; Fastly actúa como relay.
- Mozilla — recopilación de métricas de rendimiento de Firefox sin identificación del usuario.
- Meta — Private Processing para Meta AI en WhatsApp (2025), también a través del relay Fastly.
- Flo — "modo anónimo" del rastreador de ciclos basado en Cloudflare Privacy Gateway desde 2022.
Los gateways, además de Cloudflare y Fastly, son proporcionados por Internet Security Research Group en el servicio Divvi Up. Es decir, la infraestructura es real, no solo en papel.
MASQUE: esto ya se parece a un proxy
La segunda parte del stack que Cloudflare promete agregar a pvcli es MASQUE. Es un conjunto de protocolos del grupo de trabajo IETF que lleva el proxying dentro de HTTP:
- RFC 9298 (agosto de 2022), CONNECT-UDP — proxying UDP dentro de HTTP; el cliente envía un CONNECT extendido con
:protocol: connect-udp, y el proxy convierte los cuadros QUIC DATAGRAM en paquetes UDP. - RFC 9484 (octubre de 2023), CONNECT-IP — ya es un nivel IP completo: los paquetes IP en bruto se envuelven en HTTP Datagrams, y el servidor HTTP/3 se convierte en un gateway VPN, capaz de manejar simultáneamente TCP, UDP e ICMP.
Ambas especificaciones requieren un fallback a HTTP/2 donde QUIC y UDP están bloqueados a nivel de red, lo cual ocurre regularmente en redes corporativas y de proveedores. En esencia, MASQUE es lo que sustenta los modernos "relays privados" a nivel de sistema operativo, donde el tráfico pasa por dos saltos independientes: el primero te conoce, pero no conoce al destinatario, el segundo al contrario.
Privacy Pass: un pase anónimo en lugar de un captcha
El tercer componente es Privacy Pass, estandarizado en tres documentos: RFC 9576 (arquitectura), RFC 9577 (esquema de autenticación HTTP) y RFC 9578 (protocolos de emisión de tokens, verificables de forma privada y pública). La lógica se desarrolla en dos pasos: emisión — demuestras una vez que eres humano o un cliente de confianza, y recibes un lote de tokens firmados ciegamente; redención — presentas el token al sitio, y este te deja pasar sin captcha, sin poder vincular el token con el momento de emisión.
Este es exactamente el mecanismo detrás de la idea de "dar acceso legítimo a buenos bots" — que también está en la base de agentes firmados y Web Bot Auth. La tendencia es la misma: separar la identidad en línea (IP) y los derechos de acceso (token, firma).
¿Reemplazará esto a los proxies? Análisis sin ilusiones
Cada vez que surge una noticia de este stack, aparece la afirmación "¿por qué ahora necesitar proxies si hay OHTTP?". El problema es que los protocolos privados y los proxies resuelven diferentes problemas, y reemplazar uno por otro se desmorona en cuatro puntos.
1. OHTTP solo funciona donde el sitio lo ha desplegado
No es una superposición sobre Internet, sino un opt-in por parte del receptor: el gateway se levanta y configura el origen (o su contratista) por sí mismo. No se puede "entrar a través de OHTTP" en un mercado o red social arbitraria — simplemente no hay gateway. Todas las implementaciones mencionadas son empresas que ocultan la IP de sus propios usuarios de sus propios backend. Para recopilar datos de un sitio externo, el mecanismo no es aplicable en principio.
2. El punto de salida es un centro de datos, y todos lo saben
Incluso si hay un gateway, la solicitud sale con la dirección de Cloudflare, Fastly o ISRG. Estos son ASN conocidos de proveedores de hosting con rangos públicos. Los sistemas anti-bots clasifican las IP por tipo de red, y la dirección de un relay en la nube recibe exactamente la misma puntuación que cualquier otra dirección de centro de datos. Has obtenido privacidad del origen, pero "parecer un usuario doméstico común" — no. Esto es precisamente lo que hacen los proxies residenciales con direcciones reales de proveedores y grupos móviles de redes CGNAT de operadores.
3. No hay geografía, rotación y sesiones pegajosas
La infraestructura de proxies ofrece lo que los protocolos privados no tienen por diseño: elección de país, región y operador, rotación de IP gestionada, sesiones pegajosas durante el tiempo necesario, diferentes grupos para diferentes cuentas. OHTTP no te permite elegir "salir desde Alemania, desde la red de un ISP específico" — no hay concepto de punto de salida a tu disposición. Para verificar la entrega local, precios por regiones o trabajar con contenido geográficamente restringido, esta es una diferencia insalvable.
4. El modelo de confianza es diferente
OHTTP protege contra la vinculación de solicitudes a un origen específico siempre que el relay y el gateway sean independientes. El proxy protege contra que el sitio vea tu verdadera dirección y perfil de red. Lo primero es sobre la privacidad de la telemetría y las solicitudes del usuario, lo segundo es sobre acceso y distribución de carga. Las tareas se cruzan solo parcialmente, y "moverse" de uno a otro no es posible.
Qué de esto es realmente útil en la práctica
- Si eres un desarrollador de un producto que envía telemetría o solicitudes a su API — OHTTP a través de Privacy Gateway o Divvi Up realmente reduce la cantidad de datos personales recopilados y simplifica la conversación con los abogados. pvcli ahora permite depurar esto sin tener que escribir un cliente desde cero.
- Si estás recopilando datos públicos — el stack no cambia nada: el punto de salida y su reputación siguen siendo tu responsabilidad. Para el scraping masivo, la combinación sigue siendo efectiva — proxies de centro de datos con rotación en plataformas leales y residenciales donde se ha activado un serio anti-bot.
- Si trabajas con múltiples cuentas — los protocolos privados no resuelven la cuestión de la aislamiento: las sesiones en las plataformas se vinculan no solo por IP, sino también por huella de navegador y comportamiento. La diferencia entre la capa de IP y la capa de identidad se ha analizado en el material sobre las diferencias entre proxies y VPN.
- Si automatizas el acceso "en blanco" — aquí es donde debes prestar atención. Privacy Pass y los agentes firmados van hacia un modelo donde se le da acceso al bot mediante el token presentado, y no por "parecer humano". Esta es la parte más prometedora de la noticia.
Conclusión
La apertura de pvcli es un buen indicador de madurez: los protocolos privados han salido de la etapa de preprints de investigación y han adquirido herramientas de depuración. OHTTP, MASQUE y Privacy Pass realmente están reformulando cómo Internet maneja la dirección del cliente, y en un par de años "el sitio ve tu IP" dejará de ser un axioma para el tráfico de usuarios.
Pero para aquellos que recopilan datos, gestionan múltiples cuentas o verifican la entrega por regiones, nada cambia. Los protocolos privados te ocultan de a quién has llegado por invitación. Los proxies son necesarios donde no se otorgan invitaciones, — y allí, el tipo de red, la reputación de la dirección y la calidad del grupo siguen siendo determinantes. Es razonable seguir de cerca Privacy Pass como un futuro canal legal para bots y, al mismo tiempo, mantener una infraestructura de proxy adecuada para lo real.
```