JDK 25 HttpClient не використовує маршрути SOCKS із ProxySelector
Виберіть транспорт Java HTTP, який справді підтримує SOCKS, замість того щоб покладатися лише на тип, який повертає ProxySelector.
Об'єкт проксі в 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-бібліотека до них звертається. Коли маршрут обов'язковий, непідтримуваний тип проксі слід виявляти до прийняття зовні успішного прямого запиту.