Зошто Java избра SOCKS прокси за вашето 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 кандидати без разлика може да ги прекине врските што требало да се користат. Поправете го неточното правило со најмалиот опсег што можете да го утврдите.