Unha solicitude HTTP/3 necesita unha ruta de proxy con capacidade UDP
Distinga o transporte QUIC de HTTP/3 dos túneles TCP ordinarios de HTTP CONNECT e do soporte UDP opcional dun servizo SOCKS5.
Un cliente que chega con éxito a HTTPS a través dun proxy TCP non estableceu unha ruta para HTTP/3. HTTP/3 usa QUIC, e QUIC usa UDP.
Un túnel HTTP CONNECT ordinario proporciona un fluxo TCP ata o seu destino. Non se converte nun repetidor UDP cando o URL comeza por HTTPS ou cando o destino escoita no porto 443.
SOCKS5 tamén necesita a ruta UDP
SOCKS5 define a asociación UDP, pero tanto o cliente como o servidor deben implementala, e o extremo repetidor debe ser accesible. Unha biblioteca que só expón un dialer TCP de SOCKS non pode ofrecer transporte de datagramas só porque o nome do seu tipo diga SOCKS5.
Do mesmo xeito, un compoñente dunha ferramenta chamado proxy pode ser un simulador de perda de paquetes de desenvolvemento e non un cliente xeral de proxy ascendente. Examine a súa interface real e o transporte que admite.
Estándares como CONNECT-UDP definen outra forma de transportar UDP a través dun sistema de proxy HTTP. Requiren soporte nos dous extremos e non deben confundirse co CONNECT tradicional.
Se o cliente HTTP retrocede a HTTP/2 ou HTTP/1.1 sobre TCP, unha solicitude pode ter éxito a través do proxy ordinario sen que se usase ningunha conexión HTTP/3. Rexistre o protocolo negociado cando esa distinción importe.
Por iso a pregunta útil de compatibilidade é concreta: pode este cliente transportar os seus datagramas QUIC a través deste proxy con este mecanismo admitido? Unha páxina de navegador que funciona ou unha comprobación de porto TCP responde a unha pregunta menor.