Een HTTP/3-verzoek vereist een UDP-geschikt proxypad
Onderscheid het QUIC-transport van HTTP/3 van gewone HTTP CONNECT TCP-tunnels en van de optionele UDP-ondersteuning van een SOCKS5-dienst.
Een client die HTTPS met succes bereikt via een TCP-proxy heeft nog geen route voor HTTP/3 opgezet. HTTP/3 gebruikt QUIC, en QUIC gebruikt UDP.
Een gewone HTTP CONNECT-tunnel levert een TCP-stroom naar zijn bestemming. Hij wordt geen UDP-relay wanneer de URL met HTTPS begint of de bestemming op poort 443 luistert.
SOCKS5 heeft het UDP-pad ook nodig
SOCKS5 definieert een UDP-associatie, maar zowel de client als de server moeten die implementeren, en het relay-eindpunt moet bereikbaar zijn. Een bibliotheek die alleen een SOCKS TCP-dialer biedt, kan geen datagramtransport leveren alleen omdat de naam van het type SOCKS5 zegt.
Evenzo kan een component van een hulpmiddel met de naam proxy een simulatie van pakketverlies voor ontwikkeling zijn in plaats van een algemene upstream-proxyclient. Onderzoek de werkelijke interface en het ondersteunde transport.
Standaarden zoals CONNECT-UDP definiëren een andere manier om UDP door een HTTP-proxysysteem te dragen. Ze vereisen ondersteuning aan beide uiteinden en mogen niet met traditionele CONNECT worden verward.
Als de HTTP-client terugvalt op HTTP/2 of HTTP/1.1 over TCP, kan een verzoek slagen via de gewone proxy terwijl er geen HTTP/3-verbinding werd gebruikt. Noteer het onderhandelde protocol wanneer dat onderscheid van belang is.
De nuttige compatibiliteitsvraag is daarom specifiek: kan deze client zijn QUIC-datagrammen via deze proxy dragen met dit ondersteunde mechanisme? Een werkende browserpagina of een TCP-poortcontrole beantwoordt een kleinere vraag.