En HTTP/3-forespørsel trenger en UDP-kapabel proxyvei
Skill HTTP/3s QUIC-transport fra vanlige HTTP CONNECT TCP-tunneler og fra en SOCKS5-tjenestes valgfrie UDP-støtte.
En klient som når HTTPS gjennom en TCP-proxy, har ikke etablert en rute for HTTP/3. HTTP/3 bruker QUIC, og QUIC bruker UDP.
En vanlig HTTP CONNECT-tunnel gir en TCP-strøm til destinasjonen sin. Den blir ikke en UDP-relé når URL-en begynner med HTTPS eller destinasjonen lytter på port 443.
SOCKS5 trenger også UDP-veien
SOCKS5 definerer en UDP-tilknytning, men både klienten og serveren må implementere den, og relé-endepunktet må være tilgjengelig. Et bibliotek som bare tilbyr en SOCKS TCP-dialer, kan ikke levere datagramtransport bare fordi typenavnet sier SOCKS5.
På samme måte kan en komponent i et verktøy kalt proxy være en utviklingssimulator for pakketap i stedet for en generell oppstrøms-proxyklient. Undersøk det faktiske grensesnittet og den støttede transporten.
Standarder som CONNECT-UDP definerer en annen måte å bære UDP gjennom et HTTP-proxysystem. De krever støtte i begge ender og bør ikke forveksles med tradisjonell CONNECT.
Hvis HTTP-klienten faller tilbake til HTTP/2 eller HTTP/1.1 over TCP, kan en forespørsel lykkes gjennom den vanlige proxyen uten at noen HTTP/3-forbindelse ble brukt. Noter den forhandlede protokollen når denne forskjellen er viktig.
Det nyttige kompatibilitetsspørsmålet er derfor konkret: kan denne klienten bære QUIC-datagrammene sine gjennom denne proxyen med denne støttede mekanismen? En fungerende nettleserside eller en TCP-portkontroll besvarer et mindre spørsmål.