Activating a Conda environment selects an environment; it does not make every program inside it use Conda's configuration. Conda and pip are separate download clients.

Conda can have proxy routes in .condarc:

proxy_servers:
  http: http://203.0.113.10:8080
  https: http://203.0.113.10:8080

These example values tell Conda how to reach destinations of each scheme. pip does not automatically adopt the proxy_servers mapping merely because it is installed in that environment.

Inspect both configurations

Check the Conda configuration sources and the pip associated with the active Python:

conda config --show-sources
python -m pip --version
python -m pip config debug

The outputs can reveal different configuration locations, an unexpected interpreter, or an environment variable that one test did not use. Review private URLs and credentials before sharing them.

For pip, use its documented proxy option, pip-specific configuration, or the appropriate networking environment. Do not copy a .condarc YAML section directly into a pip INI file.

Trust settings are separate too

Conda's ssl_verify can identify a CA bundle or, on supported versions and Python runtimes, select system trust with truststore. That is not a command to configure pip's trust source.

If the proxy performs approved TLS inspection, establish how each client trusts that authority. A successful Conda request proves that its own route and trust worked for that request; it does not prove pip received the same setup.

Compare the actual destinations

The clients may use different package indexes and file hosts. An intermediary allowing one channel can deny another index or a later archive URL. Check the failing hostname and response before attributing the difference to the selected Python environment alone.

A useful report identifies the interpreter, each client's configuration source, the requested host, and the first connection or certificate error. “Conda works” is a starting comparison, not a full test of pip's network path.

Tënë sô zo