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

Праверце вынік ProxySelector і эфектыўныя налады JVM, перш чым ужываць старыя абыходныя рашэнні для Windows.

Запыт 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 можа парушыць злучэнні, якія павінны былі выкарыстоўваць адзін з іх. Выпраўце няправільнае правіла ў найменшым абсягу, які зможаце вызначыць.

Падобныя артыкулы