Чому Java обрала SOCKS-проксі для вашого HTTP-запиту

Перегляньте результат ProxySelector і чинні налаштування JVM, перш ніж застосовувати старі обхідні рішення для проксі Windows.

HTTP-запит 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 може зламати з'єднання, які мали його використовувати. Виправте неправильне правило в найменшому обсязі, який можете визначити.

Схожі статті