En HTTP/3-forespørsel krever en UDP-kompatibel proxyvei
Skill QUIC-transporten i HTTP/3 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 opprettet 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. Den blir ikke en UDP-videresender når URL-en starter med HTTPS eller destinasjonen lytter på port 443.
SOCKS5 trenger også UDP-veien
SOCKS5 definerer en UDP-tilknytning, men både klienten og tjeneren må implementere den, og videresenderens endepunkt 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 transporten som støttes.
Standarder som CONNECT-UDP definerer en annen måte å fø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 føre QUIC-datagrammene sine gjennom denne proxyen med denne støttede mekanismen? En fungerende nettleserside eller en TCP-portkontroll svarer på et mindre spørsmål.