pip y conda detrás de un 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:PASS@proxy.s4m.online:3128. See the proxy page, the sibling npm/yarn guide, and the shared environment-variable guide for how these variables cross tools.

El fallo de pip más confuso detrás de un proxy no es un tiempo de espera, sino un error de certificado SSL. Eso sucede cuando un proxy corporativo intercepta y vuelve a firmar HTTPS: pip ve un certificado no confiable y se niega. La solución adecuada es instalar la CA raíz del proxy en tu almacén de confianza; la solución rápida es --trusted-host pypi.org --trusted-host files.pythonhosted.org. El propio proxy de s4m no intercepta TLS, así que no te encontrarás con esto en nuestro punto final: solo reenvía tu tráfico cifrado.

El proxy HTTP de s4m es un punto final autenticado de centro de datos, con pago por uso — una salida limpia para imágenes de CI y cajas de desarrolladores que deben acceder a PyPI y canales de conda desde detrás de una red controlada. No es un proxy residencial ni un espejo de paquetes. Codifica caracteres especiales en tu contraseña (@ se convierte en %40), y establece no_proxy para índices de paquetes internos. Un 407 significa credenciales incorrectas — consulta la guía 407. Cuando CI necesita una salida permitida, añade una IP personal dedicada; valida cualquier punto final con las herramientas.