Java прокси објекат описује руту. Мрежни клијент и даље одлучује које врсте рута може да користи. То је важно када доступна крајња тачка говори SOCKS, а апликација користи java.net.http.HttpClient.

У овде испитаној имплементацији JDK 25, код захтева HTTP клијента прихвата HTTP кандидата од селектора. SOCKS кандидат га не покреће на SOCKS преговарање; имплементација може да настави без проксија. Зато успешан одговор није довољан доказ да је коришћен SOCKS унос прилагођеног селектора.

Прво изаберите пренос

За постојећу апликацију засновану на URLConnection, руковаоцу протокола се може дати подржани експлицитни прокси при отварању везе:

Proxy route = new Proxy(Proxy.Type.SOCKS,
    new InetSocketAddress("proxy.example", 1080));
URLConnection connection = URI.create("https://service.example/")
    .toURL().openConnection(route);
connection.setConnectTimeout(5000);
connection.setReadTimeout(15000);

За дозвољена тестирања јавних циљева користите одговарајућу SOCKS крајњу тачку из своје услуге или са листе SOCKS проксија. То је другачији клијентски API, а не алтернативно писање HttpClient.Builder.proxy. Сачувајте одредишни URL како би HTTPS и даље препознавао намењено веб-место.

Апликација која мора да задржи java.net.http може уместо тога да користи компатибилну крајњу тачку HTTP проксија, укључујући одобрени адаптер који преузима даљу SOCKS везу. То додаје стварну компоненту и још једну границу приступа; промена порта 8080 у 1080 не пружа то превођење.

Држите избор и усвајање видљивим

Забележите и резултат селектора и везу коју клијент заиста отвара. Први описује излаз политике; други утврђује да ли га је имплементација усвојила.

Вежите закључке за коришћено извршно окружење и пренос. JVM SOCKS својства која користи једна имплементација сокета нису обећање да их свака HTTP библиотека консултује. Када је рута обавезна, неподржани тип проксија треба открити пре прихватања наизглед успешног директног захтева.

Повезани чланци