Ein HTTP/3-førespurnad treng ein UDP-kapabel proxyveg
Skil HTTP/3 sin QUIC-transport frå vanlege HTTP CONNECT TCP-tunnelar og frå den valfrie UDP-støtta til ein SOCKS5-teneste.
Ein klient som når HTTPS gjennom ein TCP-proxy, har ikkje etablert ein rute for HTTP/3. HTTP/3 brukar QUIC, og QUIC brukar UDP.
Ein vanleg HTTP CONNECT-tunnel gjev ein TCP-straum til destinasjonen sin. Han blir ikkje eit UDP-relé når URL-en byrjar med HTTPS eller destinasjonen lyttar på port 443.
SOCKS5 treng òg UDP-vegen
SOCKS5 definerer ei UDP-tilknyting, men både klienten og tenaren må implementere henne, og relé-endepunktet må vere tilgjengeleg. Eit bibliotek som berre tilbyr ein SOCKS TCP-dialar, kan ikkje levere datagramtransport berre fordi typenamnet seier SOCKS5.
På same måte kan ein komponent i eit verktøy kalla proxy vere ein utviklingssimulator for pakketap i staden for ein generell oppstraums-proxyklient. Undersøk det faktiske grensesnittet og den støtta transporten.
Standardar som CONNECT-UDP definerer ein annan måte å bera UDP gjennom eit HTTP-proxysystem. Dei krev støtte i begge endar og bør ikkje forvekslast med tradisjonell CONNECT.
Viss HTTP-klienten fell tilbake til HTTP/2 eller HTTP/1.1 over TCP, kan ein førespurnad lukkast gjennom den vanlege proxyen utan at noka HTTP/3-tilkopling vart brukt. Noter den forhandla protokollen når denne skilnaden er viktig.
Det nyttige kompatibilitetsspørsmålet er derfor konkret: kan denne klienten bera QUIC-datagramma sine gjennom denne proxyen med denne støtta mekanismen? Ei fungerande nettlesarside eller ein TCP-portkontroll svarar på eit mindre spørsmål.