Барањето 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 може да биде симулатор на загуба на пакети за развој, а не општ клиент на нагорно прокси. Проверете го нејзиниот вистински интерфејс и поддржаниот пренос.
Стандарди како CONNECT-UDP дефинираат друг начин за пренос на UDP низ HTTP прокси систем. Тие бараат поддршка на двата краја и не треба да се мешаат со традиционалниот CONNECT.
Ако HTTP клиентот се врати на HTTP/2 или HTTP/1.1 преку TCP, барањето може да успее преку обичното прокси, а притоа да не е користена HTTP/3 врска. Забележете го договорениот протокол кога оваа разлика е важна.
Затоа корисното прашање за компатибилност е конкретно: може ли овој клиент да ги пренесе своите QUIC датаграми преку ова прокси со овој поддржан механизам? Работна страница во прелистувач или проверка на TCP порта одговара на помало прашање.