В приложении на Apache HttpClient 4 HTTPS-назначение не означает, что каждое соединение начинается с TLS. К обычному HTTP-прокси обращаются по незашифрованному соединению, прежде чем CONNECT откроет туннель и TLS будет наложен в сторону назначения.

Если собственный менеджер соединений регистрирует только https, первый шаг через прокси может завершиться ошибкой UnsupportedSchemeException: http protocol is not supported.

Для API 4.5 включите обе фабрики при создании этого менеджера:

var registry = RegistryBuilder.<ConnectionSocketFactory>create()
    .register("http", PlainConnectionSocketFactory.getSocketFactory())
    .register("https", tlsFactory)
    .build();

var manager = new PoolingHttpClientConnectionManager(registry);
var client = HttpClients.custom()
    .setConnectionManager(manager)
    .setProxy(new HttpHost("proxy.example.net", 8080, "http"))
    .build();

tlsFactory — существующая SSLConnectionSocketFactory приложения с предусмотренной проверкой доверия и имени хоста. Показанные типы относятся к пакетам org.apache.http Apache 4. Фрагмент предполагает вывод типов локальных переменных Java; более старый код Java может использовать явные типы.

Прикрепите исправленный менеджер к клиенту, который действительно используется для запроса. Для разрешённого публичного HTTPS-запроса без аутентификации прокси HTTP-запись из списка HTTP-прокси может заполнить адрес прокси в HttpHost. Настройка другого builder не обновляет уже созданный клиент.

Проверьте и принадлежность builder: HttpClientBuilder документирует, что явно переданный менеджер соединений может переопределить его отдельные входы конфигурации SSL. Помещайте нужные фабрики в реестр менеджера, а не предполагайте, что последующий вызов setSSLContext заменит его внутренности.

Эта диагностика касается локального реестра схем. Запрос аутентификации прокси или отклонённое назначение — более поздний, другой результат. Сохраняйте обе регистрации фабрик, пока исследуете эти ответы.

Похожие статьи