R Proxy Settings: Package Downloads vs API Requests
Trace the R session environment and the HTTP client a package actually uses instead of combining incompatible proxy recipes from old R releases.
If R can install a package but that package cannot reach its API, compare the two requesting clients. download.file(), RCurl and a package's own HTTP layer need not read the same options.
Check the running session's inputs
A terminal launch inherits that terminal's environment. A desktop shortcut or an IDE already running can have different values. The appropriate R startup environment file can contain:
http_proxy=http://proxy.example:8080
https_proxy=http://proxy.example:8080These are environment-file entries with an example endpoint. For public package or API requests allowed through public intermediaries, the HTTP proxy list offers candidates for those values. R expressions such as options(download.file.method = "libcurl") belong in R code, not .Renviron. Putting the right-looking setting in the wrong format leaves it unused.
Identify the startup file selected by R's site/user, environment and working-directory rules. A project-local file can explain a difference between two projects in the same IDE. Change the intended file and restart the relevant session; editing it does not update the process already running.
Follow the failing package's request
Identify the actual download method or HTTP implementation. An external curl executable, R's libcurl method and RCurl are distinct consumers with their own supported inputs. Compare the same destination through the failing package, with secrets redacted.
Keep recipes matched to that implementation and R release. Old Windows --internet2 advice describes historical behavior. Also retain the real proxy listener's transport scheme: an HTTPS destination can still use an HTTP proxy endpoint. Successful installation through another downloader establishes neither this client's configuration nor the proxy's availability for this request.