The R installed in a Conda environment can use a different libcurl build from the curl executable in the terminal. Ask the failing R session which library it actually has:

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

The character value reports the linked libcurl version. Its ssl_version attribute identifies the TLS implementation, while protocols lists that library’s supported destination protocols. These describe R’s built-in libcurl path, not a shell command named curl.

Match the report to the download method

download.file with method='libcurl' uses this library. method='curl' launches the external executable. Current automatic HTTP(S) selection uses libcurl, and a NULL download.file.method option can leave that default in place.

Run the inspection in the actual environment selected by the job or IDE. Another R installation can report another version or TLS backend even when its scripts look identical.

A listed https protocol means HTTPS destinations are supported. It does not prove that a particular proxy listener accepts TLS. An ordinary HTTP proxy for an HTTPS download still has an http:// proxy URL.

Keep the library report alongside the chosen method and connection error. A certificate failure, unsupported proxy scheme and refused listener remain different findings; a version number alone is not their diagnosis.

Tënë sô zo