En HTTP/3-förfrågan kräver en UDP-kapabel proxyväg
Skilj HTTP/3:s QUIC-transport från vanliga HTTP CONNECT TCP-tunnlar och från en SOCKS5-tjänsts valfria UDP-stöd.
En klient som når HTTPS via en TCP-proxy har inte etablerat en väg för HTTP/3. HTTP/3 använder QUIC, och QUIC använder UDP.
En vanlig HTTP CONNECT-tunnel ger en TCP-ström till sitt mål. Den blir inte en UDP-relä när URL:en börjar med HTTPS eller målet lyssnar på port 443.
SOCKS5 behöver också UDP-vägen
SOCKS5 definierar en UDP-association, men både klienten och servern måste implementera den, och reläets ändpunkt måste vara nåbar. Ett bibliotek som bara erbjuder en SOCKS TCP-dialer kan inte tillhandahålla datagramtransport bara för att typnamnet säger SOCKS5.
På samma sätt kan en komponent i ett verktyg som heter proxy vara en utvecklingssimulator för paketförlust i stället för en allmän uppströms-proxyklient. Undersök dess faktiska gränssnitt och transport som stöds.
Standarder som CONNECT-UDP definierar ett annat sätt att bära UDP genom ett HTTP-proxysystem. De kräver stöd i båda ändar och bör inte förväxlas med traditionell CONNECT.
Om HTTP-klienten faller tillbaka till HTTP/2 eller HTTP/1.1 över TCP kan en förfrågan lyckas via den vanliga proxyn utan att någon HTTP/3-anslutning användes. Notera det förhandlade protokollet när den skillnaden spelar roll.
Den användbara kompatibilitetsfrågan är därför specifik: kan den här klienten bära sina QUIC-datagram genom den här proxyn med den här stödda mekanismen? En fungerande webbläsarsida eller en TCP-portkontroll besvarar en mindre fråga.