Запросу 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-порта отвечает на меньший вопрос.