R, установленный в окружении Conda, может использовать другую сборку libcurl, чем исполняемый файл curl в терминале. Спросите у сбойного сеанса R, какая библиотека у него на самом деле:

info <- libcurlVersion()
info
attr(info, 'ssl_version')
attr(info, 'protocols')

Символьное значение сообщает версию связанной libcurl. Его атрибут ssl_version определяет реализацию TLS, а protocols перечисляет целевые протоколы, поддерживаемые этой библиотекой. Они описывают встроенный путь libcurl в R, а не команду оболочки с именем curl.

Сопоставьте отчёт со способом загрузки

download.file с method='libcurl' использует эту библиотеку. method='curl' запускает внешний исполняемый файл. Текущий автоматический выбор HTTP(S) использует libcurl, и параметр download.file.method со значением NULL может оставить это поведение по умолчанию.

Выполняйте проверку в той среде, которую выбирает задание или IDE. Другая установка R может сообщать другую версию или другой TLS-бэкенд, даже если её скрипты выглядят одинаково.

Указанный протокол https означает, что цели HTTPS поддерживаются. Это не доказывает, что конкретный прослушивающий прокси принимает TLS. Обычный HTTP-прокси для загрузки по HTTPS по-прежнему имеет URL прокси с http://.

Храните отчёт о библиотеке вместе с выбранным способом и ошибкой соединения. Сбой сертификата, неподдерживаемая схема прокси и отклонённый прослушиватель остаются разными находками; один номер версии не является их диагнозом.

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