Поставьте согласование SOCKS в Netty перед протоколом вашего приложения

Разместите обработчик прокси SOCKS Netty перед трафиком приложения и сохраняйте неразрешённый адрес назначения, когда DNS на стороне прокси намеренный.

Для существующего bootstrap/pipeline Netty, где сервер SOCKS должен разрешать адрес назначения:

bootstrap.resolver(NoopAddressResolverGroup.INSTANCE);

pipeline.addFirst(
    new Socks5ProxyHandler(new InetSocketAddress("127.0.0.1", 1080))
);

bootstrap.connect(
    InetSocketAddress.createUnresolved("example.com", 443)
);

Конечная точка прокси — локальный порт 1080; неразрешённая цель соединения — example.com:443. Не используйте адрес прокси для обеих ролей и не разрешайте имя до того, как обработчик его получит. Для публичных целей на разрешённом маршруте публичного прокси список прокси SOCKS5 предоставляет кандидатов для конечной точки прокси обработчика.

Разместите Socks5ProxyHandler перед обработчиками, обменивающимися трафиком к цели. Ждите future прокси-соединения, а не просто канал, достигший слушателя. Отклонённый метод или адрес назначения относится к этому этапу настройки.

Для HTTPS следующий слой TLS использует имя хоста назначения, требуемую проверку и доверие — а не идентичность конечной точки SOCKS. Только затем начинается обмен HTTP/приложения.

Фрагмент не предоставляет циклы событий, типы каналов, обработчики TLS/HTTP или обычную обработку ошибок. Выберите конструктор SOCKS, соответствующий требованиям аутентификации; обработчик HTTP Basic — другой протокол.

Используйте no-op resolver только там, где этот нижестоящий обработчик владеет разрешением имён хостов. Другим соединениям может понадобиться локальный поиск. При диагностике сбоя держите отдельно вывод resolver, future прокси, TLS и результат приложения.

Похожие статьи