Une requête HTTP/3 exige un chemin de proxy compatible UDP
Distinguez le transport QUIC de HTTP/3 des tunnels TCP HTTP CONNECT ordinaires et de la prise en charge UDP facultative d'un service SOCKS5.
Un client qui atteint HTTPS avec succès via un proxy TCP n'a pas établi de route pour HTTP/3. HTTP/3 utilise QUIC, et QUIC utilise UDP.
Un tunnel HTTP CONNECT ordinaire fournit un flux TCP vers sa destination. Il ne devient pas un relais UDP lorsque l'URL commence par HTTPS ou que la destination écoute sur le port 443.
SOCKS5 a aussi besoin du chemin UDP
SOCKS5 définit une association UDP, mais le client comme le serveur doivent l'implémenter, et le point de relais doit être joignable. Une bibliothèque qui n'expose qu'un dialer TCP SOCKS ne peut pas fournir un transport de datagrammes simplement parce que le nom de son type indique SOCKS5.
De même, un composant d'un outil nommé proxy peut être un simulateur de perte de paquets de développement plutôt qu'un client de proxy amont général. Examinez son interface réelle et le transport pris en charge.
Des normes comme CONNECT-UDP définissent un autre moyen de transporter UDP à travers un système de proxy HTTP. Elles exigent une prise en charge aux deux extrémités et ne doivent pas être confondues avec le CONNECT traditionnel.
Si le client HTTP revient à HTTP/2 ou HTTP/1.1 sur TCP, une requête peut réussir via le proxy ordinaire alors qu'aucune connexion HTTP/3 n'a été utilisée. Notez le protocole négocié lorsque cette distinction compte.
La question utile de compatibilité est donc précise : ce client peut-il transporter ses datagrammes QUIC à travers ce proxy avec ce mécanisme pris en charge ? Une page de navigateur qui fonctionne ou un contrôle de port TCP répond à une question plus étroite.