HTTP/2, HTTP/3 y QUIC a través de proxies: qué funciona, qué falla y por qué

HTTP/2 atraviesa los proxies sin dificultad porque se ejecuta sobre TCP, y TCP es exactamente lo que transporta un túnel CONNECT o una conexión SOCKS5. HTTP/3 no: se ejecuta sobre QUIC, que se basa en UDP, y los proxies HTTP ordinarios no pueden tunelizar UDP en absoluto, mientras que la mayoría de las implementaciones de SOCKS5 tampoco lo hacen. La consecuencia práctica es que un cliente con proxy casi siempre habla HTTP/2 (o HTTP/1.1) con un sitio incluso cuando el sitio admite HTTP/3 — el navegador cae silenciosamente. Eso está bien para la mayoría del trabajo, pero cambia lo que ve el destino, y vale la pena entenderlo en lugar de descubrirlo.

Los tres protocolos en un minuto

HTTP/1.1 (1997): basado en texto, una solicitud a la vez por conexión; los navegadores abren varias conexiones en paralelo para compensar.
HTTP/2 (2015): tramas binarias, muchas transmisiones concurrentes multiplexadas sobre una conexión TCP, compresión de cabeceras (HPACK), server push (ahora en gran parte abandonado). Mismo TCP + TLS subyacente que HTTP/1.1.
HTTP/3 (2022): la misma semántica que HTTP/2 pero transportada por QUIC, un transporte que se ejecuta sobre UDP, integra TLS 1.3 en su protocolo de enlace, evita el bloqueo de cabeza de línea de TCP y permite que una conexión sobreviva a un cambio de IP (un teléfono que pasa de Wi-Fi a 4G).

Un navegador se entera de que un sitio ofrece HTTP/3 de dos maneras: una cabecera de respuesta Alt-Svc: h3=":443" en una respuesta HTTP/2 anterior, o un registro DNS HTTPS que lo anuncia. Una vez que lo sabe, intenta QUIC en la siguiente conexión y recuerda el resultado.

Cómo transporta cada uno los proxies

Proxy HTTP

Para un destino HTTPS, el cliente envía CONNECT host:443, el proxy abre una conexión TCP al destino y se convierte en un tubo de bytes tonto. Lo que sea que el cliente y el destino negocien dentro de ese tubo — TLS 1.3, luego HTTP/1.1 o HTTP/2 vía ALPN — es invisible para el proxy y funciona sin cambios. HTTP/2 a través de un proxy HTTP es, por lo tanto, completamente normal.

UDP no tiene lugar en este modelo. CONNECT crea un túnel TCP; no hay una forma estándar para que un proxy HTTP/1.1 simple diga “reenvía mis datagramas UDP a este host”. Un navegador configurado con un proxy HTTP simplemente no intenta QUIC hacia los orígenes — Chrome y Firefox deshabilitan HTTP/3 para conexiones proxy — y usa HTTP/2 a través del túnel en su lugar. Sin error, sin advertencia.

Proxy SOCKS5

SOCKS5 sí define un comando UDP ASSOCIATE para retransmitir datagramas. En principio, un proxy SOCKS5 podría transportar QUIC. En la práctica:

muchos proxies SOCKS5 comerciales implementan solo CONNECT (TCP) y rechazan o ignoran UDP ASSOCIATE;
la retransmisión UDP a través de SOCKS5 requiere que el proxy tenga un puerto UDP accesible y que el cliente admita el baile de asociación, lo que los navegadores no hacen para HTTP/3;
Chrome y Firefox tratan un proxy SOCKS igual que uno HTTP para este propósito: no se intenta HTTP/3.

Así que incluso donde el proxy podría reenviar UDP, el navegador no se lo pedirá. Los clientes QUIC de línea de comandos y algunas bibliotecas pueden apuntarse a un proxy SOCKS5 con capacidad UDP, pero esa es una configuración especializada, no la predeterminada. Nuestra comparación SOCKS5 vs HTTP cubre la distinción TCP/UDP de manera más amplia.

Lo que transportaría HTTP/3: MASQUE y CONNECT-UDP

El grupo de trabajo MASQUE del IETF estandarizó CONNECT-UDP (RFC 9298), una extensión que permite que un proxy HTTP/3 (o HTTP/2) tunelice cargas útiles UDP — y por extensión QUIC a un origen. Es lo que usan iCloud Private Relay de Apple y algunos proxies de privacidad más nuevos. El soporte en proxies comerciales de propósito general y en la configuración de proxy del navegador sigue siendo poco común; cuando un proveedor anuncia “soporte HTTP/3”, vale la pena preguntar si se refieren a que el proxy habla HTTP/3 contigo o puede tunelizar HTTP/3 a los orígenes — son cosas diferentes.

Qué sucede realmente, paso a paso

Tu navegador con proxy solicita https://example.com. Abre CONNECT example.com:443 a través del proxy.
Dentro del túnel, realiza un protocolo de enlace TLS 1.3, ofreciendo ALPN h2 y http/1.1. El origen elige h2. Estás en HTTP/2.
La respuesta lleva Alt-Svc: h3=":443". El navegador lo nota — y, debido a que hay un proxy configurado, lo ignora para fines de conexión.
Cada solicitud posterior a ese origen continúa sobre HTTP/2 a través del túnel.

Apaga el proxy y recarga: el navegador ahora honra Alt-Svc y el mismo sitio se sirve sobre HTTP/3. Nada se rompe en ningún caso; el protocolo simplemente difiere.

Por qué importa

Rendimiento

Las ventajas de HTTP/3 — protocolos de enlace más rápidos, sin bloqueo de cabeza de línea en enlaces con pérdida, migración de conexión — se pierden a través de un proxy. Para proxies de datacenter en buenos enlaces, la diferencia es pequeña. Para proxies móviles, donde el último salto es un enlace celular con pérdida, QUIC habría ayudado más y es exactamente donde no puedes tenerlo. Presupuesta un poco más de latencia de la que mostraría una conexión HTTP/3 directa; consulta la metodología en cómo medir la velocidad y el tiempo de actividad del proxy.

Huella digital y consistencia

Este es el sutil. Los sistemas anti-bot registran qué protocolo usó un cliente y cómo se veían sus ajustes HTTP/2 (consulta cómo funcionan los sistemas anti-bot). Un Chrome moderno en una conexión directa llega a la mayoría de los sitios grandes sobre HTTP/3. El mismo Chrome a través de un proxy llega sobre HTTP/2. Por sí solo, eso no es sospechoso — muchos usuarios reales están detrás de proxies corporativos y nunca usan HTTP/3 — pero es un punto de datos más, y significa que tu huella digital HTTP/2 (valores de SETTINGS, orden de cabeceras) ahora está siempre expuesta y debe ser consistente con el navegador declarado. Los clientes HTTP que suplantan a los navegadores deben suplantar la capa HTTP/2, no solo la capa TLS, por exactamente esta razón; el artículo sobre huellas digitales TLS explica la pila.

Herramientas de scraping

El requests de Python habla solo HTTP/1.1; httpx puede hacer HTTP/2 con el extra h2; aiohttp es HTTP/1.1. Ninguno hace HTTP/3 a través de un proxy. Dado que un navegador con proxy está en HTTP/2 de todos modos, usar HTTP/2 en tu cliente (donde la biblioteca lo admita) te mantiene más cerca de cómo se ve un usuario real con proxy. Ejemplos en Proxies en Python.

Guía práctica

Situación	Lo que obtienes	Acción
Navegador + proxy HTTP, sitio HTTP/3	HTTP/2 vía túnel CONNECT	Nada que hacer; esto es normal
Navegador + proxy SOCKS5, sitio HTTP/3	HTTP/2 (el navegador no intenta QUIC sobre SOCKS)	Nada que hacer
Necesitas sí o sí HTTP/3 a un origen a través de un proxy	Requiere soporte CONNECT-UDP/MASQUE de extremo a extremo	Pregunta específicamente al proveedor; asume que no a menos que se confirme
El sitio se comporta diferente con proxy vs directo	Posiblemente relacionado con el protocolo, más probablemente relacionado con la IP	Compara con un navegador real en el mismo proxy antes de culpar a HTTP/3
Suplantar a un cliente para sitios protegidos	Debe coincidir con los ajustes HTTP/2 y el orden de cabeceras de un navegador	Usa un cliente que suplante HTTP/2, no solo TLS
Medir la latencia del proxy	Compara cosas similares: HTTP/2 directo vs HTTP/2 con proxy	No compares HTTP/3 directo contra HTTP/2 con proxy

Preguntas frecuentes

¿Funciona HTTP/2 a través de un proxy?

Sí. HTTP/2 se ejecuta sobre TCP y TLS, que un túnel CONNECT o una conexión SOCKS5 transporta de manera transparente. El proxy no necesita entender HTTP/2 en absoluto.

¿Funciona HTTP/3 a través de un proxy?

Generalmente no. HTTP/3 usa QUIC sobre UDP; los proxies HTTP no pueden tunelizar UDP y los navegadores no intentan QUIC cuando hay un proxy configurado. El navegador cae automáticamente a HTTP/2. Solo los proxies que admiten CONNECT-UDP (MASQUE) pueden transportar HTTP/3 a los orígenes, y eso es raro.

¿Puede un proxy SOCKS5 transportar QUIC?

El protocolo tiene un comando de retransmisión UDP, pero muchos servicios SOCKS5 comerciales no lo implementan y los navegadores no lo usan para HTTP/3. Los clientes especializados pueden, si el proxy realmente admite UDP ASSOCIATE.

¿Usar HTTP/2 en lugar de HTTP/3 hará que me detecten?

No por sí solo — muchos usuarios legítimos están detrás de proxies que fuerzan HTTP/2. Pero significa que tu huella digital HTTP/2 siempre es visible, por lo que debe ser consistente con el navegador que dices ser.

¿Es HTTP/3 más rápido a través de un proxy?

No obtienes HTTP/3 a través de un proxy ordinario, así que la pregunta no surge; obtienes HTTP/2, que es ligeramente más lento en enlaces con pérdida de lo que sería HTTP/3. En buenos enlaces de datacenter, la diferencia es insignificante.

¿Qué es Alt-Svc?

Una cabecera de respuesta HTTP mediante la cual un sitio le dice al cliente que el mismo recurso está disponible a través de otro protocolo o puerto — típicamente h3=":443" para anunciar HTTP/3. Los navegadores lo honran en conexiones directas y lo ignoran para fines de conexión cuando hay un proxy configurado.