Java DatagramSocket и ретрансляция UDP через SOCKS5
Поймите, почему Java UDP-сокету нужна реализация SOCKS5 UDP, даже когда TCP-соединения уже используют SOCKS.
Ваш HTTP-запрос на Java работает через SOCKS, но функция UDP по-прежнему отправляет трафик напрямую или завершается ошибкой. Установка свойств SOCKS JVM не даёт DatagramSocket реализации SOCKS5 UDP.
API DatagramSocket отправляет и принимает датаграммы, адресованные сетевым конечным точкам. Его метод connect() выбирает партнёра для этого сокета. Он не выполняет согласование SOCKS с партнёром.
Маршрут UDP через SOCKS5 требует дополнительной работы
SOCKS5 определяет UDP-ассоциацию, устанавливаемую поверх управляющего соединения TCP. Затем клиент обменивается инкапсулированными датаграммами с адресом ретрансляции, который предоставляет прокси. Каждое инкапсулированное сообщение указывает своё назначение. Реализация клиента должна обрабатывать эту инкапсуляцию и время жизни управляющего соединения.
Направление обычного UDP-сокета на TCP-порт прослушивания прокси пропускает эти шаги. Отправка сырых датаграмм вашего приложения на этот адрес не заменяет ассоциацию.
Выберите библиотеку или функцию приложения, которая явно поддерживает ретрансляцию UDP через SOCKS5, и убедитесь, что сервер тоже её поддерживает. Библиотека, заявляющая поддержку SOCKS, может реализовывать только TCP CONNECT. Спецификация протокола различает эти команды.
Ретрансляции UDP тоже нужен пригодный путь
Успешное TCP-соединение с прокси устанавливает только управляющий путь. Межсетевые экраны или поведение NAT всё ещё могут мешать датаграммам, отправляемым на ретрансляцию. Соберите возвращённую конечную точку ретрансляции и любую ошибку ретрансляции, прежде чем заключать, что назначение приложения недоступно.
Наконец, поддержка транспорта SOCKS не добавляет UDP гарантий доставки. Собственные тайм-ауты вашего приложения, обработка потерь и ограничения размера сообщений по-прежнему действуют после смены маршрута.