Żądanie HTTP/3 wymaga ścieżki proxy obsługującej UDP
Odróżnij transport QUIC w HTTP/3 od zwykłych tuneli TCP HTTP CONNECT oraz od opcjonalnej obsługi UDP w usłudze SOCKS5.
Klient, który z powodzeniem dociera do HTTPS przez proxy TCP, nie ustanowił trasy dla HTTP/3. HTTP/3 używa QUIC, a QUIC używa UDP.
Zwykły tunel HTTP CONNECT zapewnia strumień TCP do celu. Nie staje się przekaźnikiem UDP, gdy adres URL zaczyna się od HTTPS lub cel nasłuchuje na porcie 443.
SOCKS5 też potrzebuje ścieżki UDP
SOCKS5 definiuje asocjację UDP, ale zarówno klient, jak i serwer muszą ją zaimplementować, a punkt końcowy przekaźnika musi być osiągalny. Biblioteka udostępniająca tylko dialer TCP SOCKS nie może zapewnić transportu datagramów tylko dlatego, że jej nazwa typu mówi SOCKS5.
Podobnie komponent narzędzia o nazwie proxy może być symulatorem utraty pakietów dla celów rozwojowych, a nie ogólnym klientem proxy nadrzędnego. Sprawdź jego rzeczywisty interfejs i obsługiwany transport.
Standardy takie jak CONNECT-UDP definiują inny sposób przenoszenia UDP przez system proxy HTTP. Wymagają wsparcia po obu stronach i nie należy ich mylić z tradycyjnym CONNECT.
Jeśli klient HTTP przejdzie na HTTP/2 lub HTTP/1.1 przez TCP, żądanie może się powieść przez zwykłe proxy, mimo że nie użyto połączenia HTTP/3. Zapisz wynegocjowany protokół, gdy to rozróżnienie ma znaczenie.
Dlatego użyteczne pytanie o zgodność jest konkretne: czy ten klient może przenieść swoje datagramy QUIC przez to proxy tym obsługiwanym mechanizmem? Działająca strona przeglądarki lub sprawdzenie portu TCP odpowiada na mniejsze pytanie.