Запыту 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-дыялер, не можа даць транспарт датаграм толькі таму, што яе назва тыпу — SOCKS5.
Гэтак жа кампанент інструмента з назвай proxy можа быць сімулятарам страт пакетаў для распрацоўкі, а не звычайным кліентам вышэйшага проксі. Праверце яго фактычны інтэрфейс і падтрыманы транспарт.
Стандарты, такія як CONNECT-UDP, вызначаюць іншы спосаб перадачы UDP праз сістэму HTTP-проксі. Яны патрабуюць падтрымкі з абодвух бакоў і не павінны блытацца з традыцыйным CONNECT.
Калі HTTP-кліент адкочваецца да HTTP/2 або HTTP/1.1 праз TCP, запыт можа паспяхова прайсці праз звычайны проксі, хоць злучэнне HTTP/3 не выкарыстоўвалася. Фіксуйце ўзгоднены пратакол, калі гэтае адрозненне важнае.
Таму карыснае пытанне сумяшчальнасці канкрэтнае: ці можа гэты кліент перадаць свае датаграмы QUIC праз гэты проксі з дапамогай гэтага падтрыманага механізму? Працоўная старонка браўзера або праверка TCP-порта адказвае на меншае пытанне.