Um pedido HTTP/3 precisa de um caminho de proxy compatível com UDP
Distinga o transporte QUIC do HTTP/3 dos túneis TCP HTTP CONNECT comuns e do suporte UDP opcional de um serviço SOCKS5.
Um cliente que chega com êxito a HTTPS através de um proxy TCP não estabeleceu uma rota para HTTP/3. O HTTP/3 usa QUIC, e o QUIC usa UDP.
Um túnel HTTP CONNECT comum fornece um fluxo TCP até ao seu destino. Não se transforma num repetidor UDP quando o URL começa por HTTPS ou quando o destino escuta na porta 443.
O SOCKS5 também precisa do caminho UDP
O SOCKS5 define uma associação UDP, mas tanto o cliente como o servidor têm de a implementar, e o ponto final do repetidor tem de ser alcançável. Uma biblioteca que só expõe um dialer TCP SOCKS não pode fornecer transporte de datagramas apenas porque o nome do seu tipo diz SOCKS5.
Do mesmo modo, um componente de uma ferramenta chamado proxy pode ser um simulador de perda de pacotes de desenvolvimento e não um cliente genérico de proxy ascendente. Examine a sua interface real e o transporte suportado.
Normas como CONNECT-UDP definem outra forma de transportar UDP através de um sistema de proxy HTTP. Exigem suporte nas duas extremidades e não devem ser confundidas com o CONNECT tradicional.
Se o cliente HTTP recuar para HTTP/2 ou HTTP/1.1 sobre TCP, um pedido pode ter êxito através do proxy comum sem que tenha sido usada qualquer ligação HTTP/3. Registe o protocolo negociado quando essa distinção importar.
Portanto, a pergunta útil de compatibilidade é específica: este cliente consegue transportar os seus datagramas QUIC através deste proxy com este mecanismo suportado? Uma página de navegador que funciona ou uma verificação de porta TCP responde a uma pergunta menor.