En HTTP/3-anmodning kræver en UDP-egnet proxyvej
Skeln mellem HTTP/3's QUIC-transport og almindelige HTTP CONNECT TCP-tunneler og en SOCKS5-tjenestes valgfrie UDP-understøttelse.
En klient, der med succes når HTTPS gennem en TCP-proxy, har ikke etableret en rute til HTTP/3. HTTP/3 bruger QUIC, og QUIC bruger UDP.
En almindelig HTTP CONNECT-tunnel giver en TCP-strøm til sin destination. Den bliver ikke en UDP-relay, når URL'en begynder med HTTPS, eller når destinationen lytter på port 443.
SOCKS5 har også brug for UDP-vejen
SOCKS5 definerer UDP-association, men både klient og server skal implementere den, og relay-endepunktet skal være tilgængeligt. Et bibliotek, der kun tilbyder en SOCKS TCP-dialer, kan ikke levere en datagramtransport, blot fordi dets typenavn siger SOCKS5.
På samme måde kan en komponent i et værktøj med navnet proxy være en udviklingssimulator for pakketab i stedet for en generel upstream-proxyklient. Undersøg dens faktiske grænseflade og understøttede transport.
Standarder som CONNECT-UDP definerer en anden måde at bære UDP gennem et HTTP-proxysystem. De kræver understøttelse i begge ender og bør ikke forveksles med traditionel CONNECT.
Hvis HTTP-klienten falder tilbage til HTTP/2 eller HTTP/1.1 over TCP, kan en anmodning lykkes gennem den almindelige proxy, uden at der blev brugt en HTTP/3-forbindelse. Noter den forhandlede protokol, når denne forskel er vigtig.
Det nyttige kompatibilitetsspørgsmål er derfor konkret: kan denne klient bære sine QUIC-datagrammer gennem denne proxy med denne understøttede mekanisme? En fungerende browserside eller en TCP-portkontrol besvarer et mindre spørgsmål.