Una solicitud HTTP/3 necesita una ruta de proxy con capacidad UDP
Distinga el transporte QUIC de HTTP/3 de los túneles TCP ordinarios de HTTP CONNECT y del soporte UDP opcional de un servicio SOCKS5.
Un cliente que llega con éxito a HTTPS a través de un proxy TCP no ha establecido una ruta para HTTP/3. HTTP/3 usa QUIC, y QUIC usa UDP.
Un túnel HTTP CONNECT ordinario proporciona un flujo TCP hasta su destino. No se convierte en un repetidor UDP cuando la URL comienza con HTTPS o cuando el destino escucha en el puerto 443.
SOCKS5 también necesita la ruta UDP
SOCKS5 define la asociación UDP, pero tanto el cliente como el servidor deben implementarla, y el extremo repetidor debe ser accesible. Una biblioteca que solo expone un dialer TCP de SOCKS no puede ofrecer transporte de datagramas solo porque el nombre de su tipo diga SOCKS5.
Del mismo modo, un componente de una herramienta llamado proxy puede ser un simulador de pérdida de paquetes de desarrollo y no un cliente general de proxy ascendente. Examine su interfaz real y el transporte que admite.
Estándares como CONNECT-UDP definen otra forma de transportar UDP a través de un sistema de proxy HTTP. Requieren soporte en ambos extremos y no deben confundirse con CONNECT tradicional.
Si el cliente HTTP retrocede a HTTP/2 o HTTP/1.1 sobre TCP, una solicitud puede tener éxito a través del proxy ordinario sin que se haya usado ninguna conexión HTTP/3. Registre el protocolo negociado cuando esa distinción importe.
Por eso la pregunta útil de compatibilidad es concreta: ¿puede este cliente transportar sus datagramas QUIC a través de este proxy con este mecanismo admitido? Una página de navegador que funciona o una comprobación de puerto TCP responde a una pregunta menor.