Enrutamiento proxy QUIC para HTTPS y HTTP/3

BotBrowser 154.0.8037.44 o posterior, con un paquete de perfil coincidente, permite mantener las solicitudes HTTPS y HTTP/3 compatibles dentro de una ruta de navegador aprobada, pero el proveedor debe implementar las operaciones necesarias. La elección depende de distinguir el túnel HTTPS del reenvío UDP y de registrar la respuesta prevista ante un fallo.

Resumen

• Usa CONNECT para túneles HTTPS normales mediante un proxy QUIC.
• Usa MASQUE CONNECT-UDP para HTTP/3 sobre QUIC cuando el proveedor y el flujo lo requieren.
• Una URL quic:// no demuestra que HTTP/3 vaya a negociarse; intervienen el sitio, el navegador y el proveedor.
• Si el proxy no está disponible, BotBrowser no cambia silenciosamente a una conexión directa: permite reintentar, elegir una ruta aprobada o detenerse.

Contenido

• Elegir el transporte
• Configurar una ruta controlada
• Validar límites y fallos
• Publicar con un registro
• Límites operativos y de protocolo
• Conclusión

Elegir el transporte

CONNECT crea un túnel hacia un destino HTTPS. Es la opción normal cuando el proveedor anuncia CONNECT en su servicio proxy QUIC. MASQUE CONNECT-UDP transporta flujos UDP y es la operación relevante para tráfico HTTP/3 compatible. No son operaciones intercambiables. Para entender qué significa CONNECT-UDP y cómo encajan los HTTP Datagrams, consulta MASQUE y CONNECT-UDP para operadores web, que también enumera lo que los operadores deben confirmar con el proveedor del proxy.

Flujo	Operación	Evidencia de decisión
Páginas y API HTTPS	CONNECT	El contrato del proveedor declara CONNECT
HTTP/3 con QUIC permitido	CONNECT-UDP	El proveedor admite MASQUE y reenvío UDP
Tráfico mixto	Ambas o una ruta de respaldo aprobada	Registrar protocolo y respaldo esperado

Configurar una ruta controlada

Usa BotBrowser 154.0.8037.44 o posterior con un paquete de perfil coincidente y relaciona binario, perfil, política del host y endpoint en un registro de versión. Este es el ejemplo de proceso:

chromium-browser \
  --bot-profile="/path/to/profile.enc" \
  --proxy-server="quic://user:[email protected]:443"

Codifica caracteres reservados de URL en las credenciales y guarda los secretos reales en el sistema de secretos del despliegue. Aplica los mismos indicadores aprobados antes de crear la primera página en un contexto. Consulta la documentación de QUIC Proxy Routing y la guía de configuración de proxy.

El enrutamiento por contexto requiere BotBrowser ENT Tier3 y BotBrowser.setBrowserContextFlags; aplica los indicadores aprobados antes de crear una página. Este límite de API y nivel es distinto del ejemplo de CLI de proceso anterior.

Validar límites y fallos

HTTP/3 se negocia por solicitud. El sitio puede elegir HTTP/2, una política puede desactivar QUIC o el proveedor puede ofrecer CONNECT sin CONNECT-UDP. Prueba el recorrido real y anota el protocolo observado. Para saber cómo negocian los navegadores HTTP/3 y recurren a otros protocolos, consulta Conceptos básicos de compatibilidad de HTTP/3 y QUIC en el navegador, que explica por qué una sola ruta de red no es universal.

Cuando el proxy QUIC no está disponible, BotBrowser no pasa silenciosamente a conexión directa. Un reintento controlado, una ruta de respaldo aprobada o una parada explícita mantienen revisables la privacidad, la consistencia y la protección. BotBrowser ofrece la capacidad configurada y el aislamiento de contexto, pero no garantiza la disponibilidad del proveedor, la negociación HTTP/3 ni un respaldo directo. Para planificar rutas aprobadas en orden con un presupuesto de reintentos acotado, consulta Conmutación de proxy y continuidad visible para el usuario, que explica cómo separar los fallos del tramo de proxy de los fallos del destino.

QUIC también difiere de UDP sobre SOCKS5. SOCKS5 usa UDP ASSOCIATE; un proxy QUIC usa su contrato CONNECT y MASQUE. Cambiar el prefijo de URL no crea una capacidad que falte.

Publicar con un registro

Antes de publicar, registra la versión de BotBrowser, la identidad del perfil, el soporte del proveedor para CONNECT y CONNECT-UDP, el responsable de credenciales, el resultado HTTP/3 esperado y la acción aprobada ante una caída. Así se puede revisar la configuración sin exponer secretos ni depender de scripts de página.

Preguntas frecuentes

¿quic:// obliga a todos los sitios a usar HTTP/3?

No. Depende del destino, la política del navegador y el proveedor; HTTPS aún puede usar HTTP/2 mediante CONNECT.

¿CONNECT-UDP es necesario para HTTPS normal?

No. HTTPS normal usa CONNECT. CONNECT-UDP sirve para reenvío UDP, incluido HTTP/3 compatible.

¿Qué sucede si QUIC falla?

BotBrowser permite aplicar una ruta proxy QUIC configurada en un contexto autorizado, pero no garantiza la disponibilidad del proveedor, la negociación HTTP/3 ni una ruta directa de respaldo. Mantiene el límite de protección configurado y deja que el operador reintente, elija una ruta aprobada o detenga el recorrido.

Para comparar configuraciones, consulta configuración de proxy. Trata UDP sobre SOCKS5 como una capacidad separada del proveedor.

Límites operativos y de protocolo

Límites operativos.

HTTP/3 asigna solicitudes y respuestas HTTP a flujos QUIC. Esto es distinto de la operación proxy usada para alcanzar el destino. CONNECT establece un túnel cuyo intercambio interno sigue entre navegador y origen. CONNECT-UDP permite transportar datagramas UDP por el proxy; navegador y origen negocian su propio protocolo por esa ruta. Por ello, “proxy QUIC” no significa que el proxy termine o comprenda el intercambio HTTP/3 del origen.

La negociación HTTP/3 utiliza los identificadores de protocolo definidos para HTTP/3 sobre QUIC, incluido h3 durante la negociación del protocolo de aplicación. Un sitio que admite HTTP/3 puede negociar otro protocolo en una conexión concreta. Influyen los protocolos ofrecidos por el navegador, la ruta de red, el proxy y la respuesta del origen. Distingue soporte anunciado de resultado observado. RFC 9114 define el comportamiento de HTTP/3, pero no garantiza que cada solicitud lo seleccione.

Los flujos QUIC son flujos de bytes ordenados y separados dentro de una conexión. HTTP/3 usa este modelo para sus flujos de solicitud. Sin embargo, eso no significa que todas las solicitudes terminen independientemente de la congestión, los recursos del host o las dependencias de la aplicación. Una página puede seguir esperando una respuesta crítica. Estas propiedades explican diferencias posibles frente a HTTP/2, pero no prometen mayor velocidad para una ruta proxy.

CONNECT-UDP pertenece a otra capa. Identifica un destino y permite transportar datagramas UDP a través de un contexto proxy HTTP. RFC 9298 define el uso de HTTP Datagrams o Capsule Protocol entre cliente y proxy. No convierte el proxy en un túnel general para cualquier protocolo ni elimina la política del proveedor. Destinos, puertos, nivel de cuenta y límites de datagramas siguen sujetos al contrato del servicio.

Con HTTPS mediante CONNECT, el túnel no convierte al proxy en el extremo TLS del origen: el navegador normalmente establece su conexión protegida con el sitio a través del túnel. En HTTP/3 por una ruta UDP, la negociación QUIC y TLS con el origen es distinta de la conexión QUIC usada para llegar al proxy. “Túnel cifrado” tampoco significa ausencia de metadatos: el proveedor puede conocer destino y tiempos, y BotBrowser no controla sus registros.

Cada comprobación responde una pregunta distinta. Una conexión proxy demuestra que el servicio es alcanzable. La aceptación de CONNECT o CONNECT-UDP demuestra que se permitió esa operación. Una solicitud HTTPS completada demuestra el intercambio con la aplicación; el protocolo HTTP/3 observado demuestra la negociación del origen. No uses un paso exitoso como evidencia automática de los demás.

HTTP/2 puede ser un resultado normal de compatibilidad si el flujo solo requiere HTTPS. También puede significar que no se cumplió un requisito específico de HTTP/3. El protocolo no decide cuál interpretación es correcta: depende del requisito declarado. Indica antes del despliegue si HTTP/2 es aceptable. Si HTTP/3 es obligatorio, registra soporte proxy y protocolo negociado por separado.

Los estándares describen protocolos, no condiciones comerciales de un proxy concreto. RFC 9114 explica HTTP/3 sobre QUIC y RFC 9298 especifica CONNECT-UDP para proxies HTTP. El proveedor define endpoint, autenticación, destinos, disponibilidad y límites de cuenta. BotBrowser puede aplicar la ruta documentada, pero no habilitar funciones del proveedor ni garantizar que el origen elija HTTP/3.

Interpreta el protocolo observado como evidencia de una conexión, no como etiqueta de toda la página. Una página puede consultar varios orígenes y cada conexión puede usar un protocolo distinto. Que el documento principal use HTTP/2 no demuestra que una API o un recurso multimedia use lo mismo; una respuesta HTTP/3 de un origen tampoco demuestra que todos los recursos usen HTTP/3. Define qué origen y solicitud forman parte de la aceptación y registra el resultado con ese alcance.

Compara el rendimiento con las mismas variables: destino, región, versión del navegador, paquete de perfil, nivel de cuenta y flujo de trabajo. QUIC puede cambiar el establecimiento de conexión y la gestión de pérdidas, pero una página más rápida no demuestra que la ruta proxy causó la diferencia. Indica si mides una conexión nueva o reutilizada y usa el mismo hito visible, como una respuesta API completa o una página utilizable. Repite pruebas autorizadas para reflejar la variación normal de red y comunica un rango, no un único resultado excepcional.

La reutilización de conexiones también cambia lo que demuestra una prueba. Varias solicitudes pueden compartir una conexión existente, por lo que una respuesta HTTP/3 posterior no implica una nueva negociación del proxy. Una conexión nueva puede tener costes de establecimiento ausentes en una ejecución repetida. Mantén separadas las observaciones de inicio en frío y las solicitudes repetidas cuando sean importantes para la aplicación. Usa un contexto de prueba controlado y no cambies datos o ajustes de privacidad para obtener el protocolo deseado.

La capacidad del proxy QUIC la define el contrato del proveedor, no la escritura de una URL. Confirma CONNECT para túneles HTTPS y CONNECT-UDP para datagramas UDP de HTTP/3 compatible, además de autenticación, restricciones de destino, límites UDP, disponibilidad y nivel de servicio. Algunos planes anuncian QUIC sin incluir CONNECT-UDP; eso es un límite del servicio.

Registra la propiedad del endpoint, de la cuenta del proveedor, de las credenciales y del paquete de perfil. Guarda el identificador del endpoint junto con la versión de BotBrowser y la revisión del perfil para distinguir una migración del proveedor de un cambio del navegador. Un hostname compartido no demuestra qué equipo o plan es responsable.

Las credenciales son datos de despliegue. Codifica los caracteres reservados, inyecta los secretos desde un almacén aprobado y no los pongas en código, historial de shell, tickets ni diagnósticos. Tras una rotación, repite la misma operación y endpoint. Un fallo de autenticación debe seguir siendo visible como tal, no provocar un endpoint sin revisión.

Un proxy no disponible es un evento de política. BotBrowser no cambia silenciosamente a conexión directa. La respuesta aprobada puede ser un reintento limitado, una ruta de respaldo revisada o una parada. El respaldo debe tener revisados proveedor, geografía, registros, credenciales y política de destino; la conexión directa no debe decidirse durante un incidente.

Separa las capas del fallo: resolución del endpoint, transporte QUIC, autenticación, rechazo de CONNECT o CONNECT-UDP, y negociación del destino. HTTP/2 elegido por el destino no equivale al mismo fallo que una autenticación rechazada. Cada estado tiene un responsable distinto.

Valida de forma acotada con un endpoint autorizado y pocos destinos en un contexto no productivo. Registra operación requerida, protocolo esperado y observado, identificador de ruta, categoría de estado y acción ante fallo. HTTP/2 puede ser válido para HTTPS normal; HTTP/3 requiere comprobar CONNECT-UDP y la negociación del destino por separado.

Conserva solo la evidencia necesaria: hora, ruta, operación y resultado. No guardes credenciales, cookies, URLs sensibles ni contenido de páginas. El proveedor puede retener metadatos según sus propios términos y BotBrowser no controla esa retención. El propietario del despliegue debe revisar acceso y duración por separado.

Una conexión QUIC al proxy solo demuestra el primer salto. No prueba que el origen eligiera HTTP/3. La política del navegador puede desactivar QUIC y el proveedor puede limitar UDP por cuenta o destino. Las notas de salida deben indicar si HTTP/2 era aceptable y, si HTTP/3 era obligatorio, si ambas comprobaciones tuvieron éxito.

Después de cambiar proveedor, credenciales, perfil o navegador, repite el registro de aceptación con BotBrowser 154.0.8037.44 o posterior, paquete de perfil coincidente, alcance de proceso o ENT Tier3, endpoint y operación declarados. Así las decisiones de privacidad y consistencia siguen vinculadas a la configuración revisada.

Conclusión

Elige CONNECT para HTTPS, añade CONNECT-UDP solo cuando el proveedor y el flujo lo necesiten y verifica el recorrido real. Un registro breve conserva privacidad y consistencia operativa y deja claros los límites de BotBrowser.

Fuentes

• MDN: HTTP/3
• RFC 9114: HTTP/3
• RFC 9298: HTTP Datagrams and CONNECT-UDP