Заявката по HTTP/3 изисква прокси път с поддръжка на UDP
Разграничете QUIC транспорта на HTTP/3 от обикновените TCP тунели HTTP CONNECT и от незадължителната UDP поддръжка на услуга SOCKS5.
Клиент, който успешно достига HTTPS през TCP прокси, не е установил маршрут за HTTP/3. HTTP/3 използва QUIC, а QUIC използва UDP.
Обикновеният тунел HTTP CONNECT предоставя TCP поток към дестинацията си. Той не се превръща в UDP ретранслатор, когато URL адресът започва с HTTPS или дестинацията слуша на порт 443.
SOCKS5 също се нуждае от UDP път
SOCKS5 дефинира UDP асоциация, но и клиентът, и сървърът трябва да я реализират, а крайната точка на ретранслация трябва да е достъпна. Библиотека, която предлага само SOCKS TCP dialer, не може да осигури транспорт на дейтаграми само защото името на типа ѝ е SOCKS5.
По същия начин компонент на инструмент с име proxy може да е симулатор на загуба на пакети за разработка, а не общ клиент на upstream прокси. Проверете действителния му интерфейс и поддържания транспорт.
Стандарти като CONNECT-UDP дефинират друг начин за пренос на UDP през HTTP прокси система. Те изискват поддръжка от двете страни и не бива да се бъркат с традиционния CONNECT.
Ако HTTP клиентът премине към HTTP/2 или HTTP/1.1 през TCP, заявката може да успее през обикновеното прокси, без да е използвана HTTP/3 връзка. Записвайте договорения протокол, когато това разграничение е важно.
Затова полезният въпрос за съвместимост е конкретен: може ли този клиент да пренесе своите QUIC дейтаграми през това прокси чрез този поддържан механизъм? Работеща страница в браузър или проверка на TCP порт отговаря на по-малък въпрос.