pip and conda behind a proxy

pip and conda both fetch over HTTPS, so both want the s4m HTTP endpoint on port 3128, authenticated with USER:PASS. pip exposes the setting three ways: the --proxy flag for a single command, a proxy line in pip.conf for persistence, and the PIP_PROXY environment variable. pip also honours the standard http_proxy / https_proxy variables, so a shell-level export often fixes things without touching pip's own config.

conda has its own config file. Set proxy_servers for http and https with conda config, which writes to ~/.condarc; conda also reads the environment variables. With s4m you point both tools at http://USER:[email protected]:3128. See the proxy page, the sibling npm/yarn guide, and the shared environment-variable guide for how these variables cross tools.

The most confusing pip failure behind a proxy is not a timeout but an SSL certificate error. That happens when a corporate proxy intercepts and re-signs HTTPS: pip sees an untrusted certificate and refuses. The proper fix is to install the proxy's root CA into your trust store; the quick fix is --trusted-host pypi.org --trusted-host files.pythonhosted.org. s4m's own proxy does not intercept TLS, so you will not hit this with our endpoint — it only forwards your encrypted traffic.

s4m's HTTP proxy is an authenticated datacenter endpoint, metered pay-as-you-go — a clean egress for CI images and developer boxes that must reach PyPI and conda channels from behind a controlled network. It is not a residential proxy and not a package mirror. Encode special characters in your password (@ becomes %40), and set no_proxy for internal package indexes. A 407 means bad credentials — see the 407 guide. When CI needs one allowlisted egress, add a dedicated personal IP; validate any endpoint with the tools.