Запрос Java может столкнуться с несколькими источниками прокси: явной конфигурацией клиента, селектором по умолчанию, сетевыми свойствами JVM и поддерживаемыми настройками операционной системы. Если в журнале неожиданно упоминается SOCKS, определите, какой источник его выбрал.

Для кода, использующего селектор по умолчанию, проверьте решение для точного пункта назначения:

URI target = URI.create("https://example.com/");
ProxySelector selector = ProxySelector.getDefault();
if (selector != null) {
    System.out.println(selector.select(target));
}

Это показывает кандидатов селектора. Это не доказывает, какое соединение в итоге оказалось успешным, а клиент с собственным явным маршрутом может сделать другой выбор.

Проверьте действующие настройки

Просмотрите http.proxyHost, https.proxyHost, socksProxyHost, их порты и java.net.useSystemProxies. Документация по сетевым свойствам JDK описывает их область действия и приоритет. Обнаружение системного прокси проверяется при запуске; задавайте его осознанно при запуске JVM.

Исторические ответы описывают конкретные комбинации старых диалогов Windows и старых JDK. Эти сообщения могут объяснить происхождение обходного пути, но не доказывают, что в текущей среде выполнения та же ошибка. Запишите версию среды выполнения и вывод селектора, прежде чем менять настройки операционной системы для всех приложений.

Если приложению нужен HTTP-прокси для одного клиента, явная конфигурация прокси может сделать это требование яснее. Если ему нужна централизованная автоматическая маршрутизация, выясните, почему селектор получил или вернул неожиданную запись SOCKS.

Пользовательский селектор должен сохранять намеренные обходы и обработку ошибок. Фильтрация всех кандидатов SOCKS без разбора может разорвать соединения, которые должны были использовать один из них. Исправьте неверное правило в минимально возможной области, которую вы можете определить.

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