Запиту 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-порту відповідає на менше питання.