企业官网建设流程全解析

第一次见到CondaHTTPError: HTTP 000 CONNECTION FAILED for url这行红字的时候，我盯着那个000看了好一会儿——HTTP 状态码表里根本没有 000 这个值，从 1xx 到 5xx，最接近的是 4xx、5xx，000 压根不在规范里。后来才反应过来，它根本不是服务端返回的响应码，而是 Python 网络栈在“连请求都没发出去、或者发出去了没等到任何响应”时填的一个占位符。换句话说，conda 连跟对方说上话的机会都没有，就已经被判出局了。

这个报错在 conda 生态里出现频率极高，几乎所有用 conda 管环境的人都撞过。它让人抓狂的地方在于：提示信息看起来像“网络问题”，但网络明明能上网；提示里写着“HTTP”，但问题往往出在 DNS、TLS 证书、端口策略、甚至系统时间上。更要命的是，它的报错文案在不同版本、不同 solver、不同操作系统下差别很大，网上搜到的答案经常对不上你的现场。

这篇东西就是把我这些年处理这个报错的路子完整摊开：从报错文本本身怎么读，到 DNS、端口、证书三关怎么逐层定位，再到 channel 换源、conda 参数调整、离线兜底这几条备选路径。目标很明确——不管你是在自己笔记本上折腾，还是在公司内网、实验室机房里被卡住，读完能按图索骥把问题摁住。基础薄弱的读者可以先照着第 6 章的速查表抄作业，想弄明白原理的往后翻。

1. HTTP 000 到底在说什么

1.1 报错文本逐字拆解

先把一段完整的报错摊开看。这是最典型的一种形态：

CondaHTTPError: HTTP 000 CONNECTION FAILED for url <https://repo.anaconda.com/pkgs/main/win-64/repodata.json> Elapsed: - An HTTP error occurred when trying to retrieve this URL. HTTP errors are often intermittent, and a simple retry will get you on your way. ConnectTimeout(MaxRetryError("HTTPSConnectionPool(host='repo.anaconda.com', port=443): Max retries exceeded with url: /pkgs/main/win-64/repodata.json (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0x000001>, 'Connection to repo.anaconda.com timed out. (connect timeout=9.15)')))

这段文本里，真正有信息量的其实只有三处。

第一处是url后面尖括号里那个地址。它告诉你 conda 正在访问哪个域名、哪个路径。绝大多数人一看到报错就去搜关键词，却忽略了这个地址——而它往往是最直接的线索。如果地址里是repo.anaconda.com，说明你在走默认 channel；如果是conda.anaconda.org，说明某个第三方 channel 直连；如果是你自己配的镜像站域名，那问题大概率出在那个镜像站上。

第二处是Elapsed: -。这个短横线表示计时器根本没启动，也就是说请求卡在了“建立连接”阶段，还没进入“传输数据”阶段。如果Elapsed后面有具体秒数比如Elapsed: 00:00:30.12，那说明连接建立了、但读取超时，排查方向完全不同。

第三处是括号里那段Caused by之后的内容。这是整段报错的心脏，它直接告诉你底层到底抛了什么异常。很多人只看第一行的HTTP 000，把后面的括号全略过了，等于把最关键的证据扔了。

1.2 括号里的四种关键词，对应四条处理路径

Caused by后面的异常类型基本能归成四类，每一类对应的处理手段差别很大。下面这张表是我自己排障时贴在手边的对照：

让我强调一下Connection reset by peer这种情况，它特别容易被误判。TCP 握手成功了，TLS 也可能成功了，甚至已经开始传 repodata 了，结果传到一半连接被重置。这在一些对长连接或者大文件传输有策略限制的网络环境里很常见——repodata.json动辄几 MB 到几十 MB，小请求能过、大请求过不去，症状就是“conda search偶尔成功、conda install必挂”。

还有一种容易被忽略的形态：报错显示的 URL 结尾是repodata.json.zst。这是 conda 较新版本的行为，它会优先请求 zstd 压缩版索引，失败后才回退到普通版。如果你看到 zst 的 URL 报错但后续没有回退日志，说明连回退那次请求也挂了，问题比想象中严重。

1.3 一分钟分诊：先确定故障在哪一层

在敲任何命令之前，我建议先做一件事：把报错里那个 URL 原封不动复制出来，粘到浏览器地址栏，回车。

这一步看着很土，但信息量极大，能直接把问题劈成两半：

如果浏览器能打开、能看到一大坨 JSON 或者直接触发下载，说明域名解析、端口、TLS 在你的系统层面都是通的。那么问题就在 conda 进程自己的环境里——可能是它读到的.condarc指向了另一个地址、可能是它继承了某个奇怪的环境变量、也可能是它的证书库和系统证书库不是同一套。

如果浏览器也打不开，报错是“无法访问此网站”“连接超时”之类，那就是纯网络层问题，老老实实按第 2 章往下走。

还有第三种结果：浏览器转了半天，最后给你一个证书警告页面。这种最常见于企业内网或者需要登录认证的公共网络，本质是 TLS 握手时对方出示的证书不被信任。这种情况下 conda 报的通常是SSLError，但偶尔也会被包装成HTTP 000，因为它压根没拿到 HTTP 响应。

分诊做完，再决定往哪个方向使劲。我见过太多人一遇到这个报错就去改.condarc换源，结果换了三个源还是报错——因为他的问题在 DNS，换源根本对症不下药。

2. 网络层排查：把 DNS、端口、证书三关走一遍

2.1 第一关：域名能不能解析

DNS 是整条链路上最容易被忽视、又最容易出问题的一环。尤其是接入了某些公共 DNS 或者公司内网 DNS 之后，一些镜像站的域名可能解析到错误的地址，甚至直接返回 NXDOMAIN。

Linux 和 macOS 上，dig和nslookup都行，我习惯用dig看得更清楚：

dig +short repo.anaconda.com dig +short mirrors.example.edu.cn

Windows 上nslookup更顺手，PowerShell 里也可以：

Resolve-DnsName repo.anaconda.com -Type A

正常应该返回一到多个 IPv4 地址。如果返回空、返回SERVFAIL、或者返回一个明显不属于该域名所有者的 IP（比如你根本没配过任何本地转发，却解析到了127.0.0.1或者0.0.0.0），那基本可以锁定是 DNS 层面被干扰了。

0.0.0.0这个结果要特别警惕。它通常意味着某个 hosts 文件或者本地过滤规则把这个域名“黑洞”掉了。检查一下这几个位置：

• Linux/macOS：/etc/hosts
• Windows：C:\Windows\System32\drivers\etc\hosts

cat /etc/hosts | grep -i anaconda

如果里面确实有把相关域名指向0.0.0.0或127.0.0.1的条目，删掉再试。

另外还有一个坑：某些系统上 IPv6 优先，而目标站点的 AAAA 记录虽然存在但实际不可达。表现是ping一直转圈、curl卡很久最后超时。可以用curl -4强制走 IPv4 验证一下：

curl -4 -I --max-time 10 https://repo.anaconda.com/pkgs/main/noarch/repodata.json

如果-4能通、不加就超时，那就在系统层面调整 IPv6 优先级，或者在 conda 层面绕开——不过 conda 本身没有强制 IPv4 的开关，实际做法是在/etc/gai.conf里调precedence ::ffff:0:0/96 100，这一条属于系统级调整，动之前记得备份原文件。

2.2 第二关：443 端口能不能握手成功

域名解析出 IP 只是第一步，能不能在那个 IP 的 443 端口上完成 TCP 握手是另一回事。ping在这里几乎没有参考价值——ICMP 被大量网络设备默认丢弃，ping不通不代表 443 不通，ping通也不代表 443 通。

我用得最多的是curl -v，因为它会把从 DNS 解析、TCP 连接、TLS 握手到 HTTP 响应的每一步都打出来，一份输出就能分出故障在哪一段：

curl -v -I --max-time 15 https://repo.anaconda.com/pkgs/main/noarch/repodata.json

输出里重点看几行：

* Trying 104.16.x.x:443... * Connected to repo.anaconda.com (104.16.x.x) port 443 (#0) * TLSv1.3 (OUT), TLS handshake, Client hello (1): ... * SSL certificate verify ok. > HEAD /pkgs/main/noarch/repodata.json HTTP/2 < HTTP/2 200

看到Connected to ... port 443说明 TCP 通了；看到SSL certificate verify ok说明 TLS 也通了；看到HTTP/2 200说明应用层正常。哪一步缺失，故障就卡在哪一步。

如果输出停在Trying ...就没了，那是 TCP 握手没完成，基本可以断定这个 IP 的 443 端口在你的网络里不可达。这时候再换一个更轻量的工具交叉验证：

# Linux / macOS nc -zv -w 5 repo.anaconda.com 443 # Windows PowerShell Test-NetConnection -ComputerName repo.anaconda.com -Port 443

Test-NetConnection的输出里TcpTestSucceeded : True/False一目了然，比较适合不熟悉命令行的同学。

如果确认是端口不通，那基本没什么优雅解法了，只能换目标——换一个在你当前网络里能通的镜像站，或者走内网自建的 channel。这也是我在第 3 章重点要讲的。

2.3 第三关：证书链与系统时间

TCP 通了、TLS 握手却失败，报SSLError，这种场景在企业内网和高安全要求的环境里非常普遍。

最常见的原因是系统时间偏差。TLS 证书有notBefore和notAfter两个时间边界，客户端本地时间如果偏出这个区间，校验必然失败。我见过一台虚拟机因为长时间挂起恢复后时间慢了三天，结果所有 HTTPS 请求全挂，排查了半小时才发现是时间问题。验证很简单：

date -u

Linux 上也可以用timedatectl看同步状态：

timedatectl status

Windows 上：

w32tm /query /status

如果时间偏差超过几分钟，先同步时间再谈别的。偏差个几十秒有时也能过，但那是运气，不可依赖。

第二个原因是证书链不完整或被替换。有些企业网络出口会做 TLS 检查，客户端看到的证书是由企业内部 CA 签发的替换证书。这个证书不会出现在系统信任库里，于是校验失败。这种场景下你在浏览器里访问会看到证书警告，但很多人点了“继续访问”就以为没事了，其实 conda 不会给你这个选项。

解决办法是把企业根证书导入信任库。系统层面导入之外，还要注意 conda 用的是 Python 的ssl模块，它读的是系统证书库或者certifi提供的证书包。有时候系统信任库导入了，Python 那边还是不认识。这时候可以显式指定：

export SSL_CERT_FILE=/path/to/merged-ca-bundle.pem export REQUESTS_CA_BUNDLE=/path/to/merged-ca-bundle.pem

merged-ca-bundle.pem的做法是把企业根证书和自己的证书合并到一个文件里。在 Linux 上一般就是：

cat /etc/ssl/certs/ca-certificates.crt /path/to/corp-root.crt > /tmp/merged-ca-bundle.pem

Windows 上对应的环境变量设置要在 PowerShell 里做，注意设置完要新开一个终端窗口，因为已经启动的进程不会重新读取环境变量。

注意：不要图省事直接关掉 SSL 校验作为长期方案。校验关掉之后你所有的包下载都失去了来源验证，包完整性只能靠哈希值兜底，风险是实打实的。

2.4 环境变量里那些“历史遗留”的转发配置

这一条是隐藏最深、也最容易让人怀疑人生的。你的 shell 里可能存在一个很早以前设的、指向某个已经不可用的地址的转发类环境变量，导致 conda 的所有请求都被送到一个死掉的地址上去。

先看有没有：

env | sort

在输出里找形如http_xxx、https_xxx、all_xxx这类变量。如果发现了，但又确定当前网络环境不需要它，直接清掉：

unset http_proxy https_proxy all_proxy

Windows PowerShell 里是：

Remove-Item Env:http_proxy -ErrorAction SilentlyContinue Remove-Item Env:https_proxy -ErrorAction SilentlyContinue

别只清当前窗口，还要检查它是不是被写在了 shell 的启动脚本里——~/.bashrc、~/.zshrc、~/.bash_profile、Windows 的系统环境变量面板，都得翻一遍。我遇到过一次是同事在~/.zshrc里写死了三个变量，每次开终端就自动注入，他自己完全忘了这回事。

conda 自己还有一层配置。用下面这条命令看当前所有配置项的来源：

conda config --show-sources

输出会列出每个.condarc文件的位置和内容。如果你的.condarc里存在与网络转发相关的键值，而当前环境又不需要，那就删掉：

conda config --remove-key proxy_servers

这一步做完，再跑conda config --show确认一遍配置干干净净，然后重新执行原本失败的命令。我统计过自己处理过的案例，大概有两成是纯环境变量残留导致的，跟网络质量一点关系都没有。

3. 换 channel：把请求打到一条能走通的路

3.1 默认 channel 为什么容易出问题

conda 默认走的defaultschannel，背后对应repo.anaconda.com这个域名。这个域名在部分网络环境下响应确实不理想，加上repodata.json文件体积大、请求频率高，稍有波动就会超时。

更麻烦的是defaults其实是个逻辑集合，它展开之后包含多个子 channel：pkgs/main、pkgs/r、pkgs/msys2（Windows）。每个子 channel 都要单独拉一次 repodata。你执行的虽然是conda install numpy一条命令，底层可能是四五个 HTTPS 请求并发，任何一个卡住，整个操作就失败。

这就是为什么很多人觉得“我明明能打开网页，为什么 conda 就是不行”——网页请求是单个小文件，conda 是一批大文件并发，对网络质量的敏感度完全不是一个量级。

换成国内镜像站，除了就近访问带来的延迟下降，更重要的是把“多个不可控域名”收敛成“一个可控域名”，出问题时至少排查范围是确定的。

3.2 .condarc 的完整写法与逐行解释

.condarc是 YAML 格式，位置在用户主目录下。Windows 上是C:\Users\<用户名>\.condarc，Linux/macOS 上是~/.condarc。如果文件不存在，直接新建。

下面是我常用的一份模板，域名用占位符代替，实际使用时把mirrors.example.edu.cn换成你所在网络里能访问的那个开源镜像站域名。国内几所高校和几家云厂商都提供这类镜像，搜索引擎一搜就有，选一个你curl得通的即可。

channels: - defaults - conda-forge default_channels: - https://mirrors.example.edu.cn/anaconda/pkgs/main - https://mirrors.example.edu.cn/anaconda/pkgs/r - https://mirrors.example.edu.cn/anaconda/pkgs/msys2 custom_channels: conda-forge: https://mirrors.example.edu.cn/anaconda/cloud pytorch: https://mirrors.example.edu.cn/anaconda/cloud show_channel_urls: true channel_priority: flexible remote_connect_timeout_secs: 30 remote_read_timeout_secs: 120 remote_max_retries: 5 ssl_verify: true

逐行说一下为什么这么配。

channels里的defaults是一个逻辑名，它本身不是一个 URL，它的实际内容由default_channels决定。这个机制是很多人踩坑的根源——他们以为把default_channels改成镜像地址了，结果channels里根本没有defaults，配置压根不生效。所以第一段里必须保留defaults这一项。

conda-forge放在channels里，它会通过custom_channels里定义的前缀拼接成完整地址：https://mirrors.example.edu.cn/anaconda/cloud/conda-forge。这个拼接规则是固定的，写custom_channels时只需要写到cloud这一层。

show_channel_urls: true让conda list和安装日志里显示包的实际来源 URL。排查时特别有用，能一眼看出某个包到底是从镜像拿的还是从官方拿的。默认是false，我建议常开。

channel_priority在较新版本里有strict、flexible、disabled三个取值。strict能避免同一个包在不同 channel 里版本混乱，但对镜像的完整性要求高——如果镜像同步不全，strict下可能直接找不到包。flexible是折中选项，适合镜像还在同步中的情况。我一般先用flexible跑通，稳定后再切strict。

remote_connect_timeout_secs、remote_read_timeout_secs、remote_max_retries这三个是 conda 自己的超时和重试控制，下一节会专门算一下它们的实际影响。

ssl_verify: true保持默认，除非你已经把企业根证书正确导入了。

3.3 换源之后必须补的两步

配置写完，很多人直接就跑conda install，然后又报错，于是开始怀疑配置写错了。其实八成是缓存没清。

conda 会把拉到的repodata.json缓存在本地，有效期默认不短。你换了源，但 conda 还在用旧源缓存的索引，自然会继续去找那些不可达的地址。清索引缓存：

conda clean -i -y

注意-i只清索引缓存，不动已经下载的包文件。如果你想连包缓存一起清，那是conda clean --all -y，但在离线或者带宽紧张的环境下别乱用，包缓存清掉之后重新下载成本很高。

清完缓存，第二步是验证。不要直接上conda install，先用conda search做一个轻量验证：

conda search numpy

如果这条能正常返回一大串版本列表，说明索引拉取这条路已经通了。同时可以看看conda config --show channels的输出，确认真实生效的 channel 列表和你的预期一致。

还有一个细节：conda info的输出里有一块channel URLs，那是实际展开后的完整地址列表。这个列表比conda config --show channels更真实，因为它已经把defaults展开、把custom_channels拼接完成了。排查配置到底生没生效，看这个最准。

conda info | sed -n '/channel URLs/,/package cache/p'

3.4 只对单个项目换源，不动全局配置

全局换源有时候不是好主意。比如你在公司内网，全局.condarc指向内网镜像，但某个临时项目需要从另一个源装包，改全局配置会影响到所有人所有项目。

这时候用命令行参数临时覆盖，优先级高于配置文件：

conda create -n project-x python=3.11 \ --override-channels \ -c https://mirrors.example.edu.cn/anaconda/pkgs/main \ -c https://mirrors.example.edu.cn/anaconda/cloud/conda-forge

--override-channels这个参数很关键。不加它的话，命令行-c指定的 channel 是追加在全局 channel 列表后面的，全局那些不可达的源还是会被请求，照样报错。加上它才是真正“只用我指定的这几个”。

对应的还有conda install，用法一样：

conda install --override-channels -c <你的镜像地址> pandas

如果你想更彻底，可以在项目目录下放一个.condarc，conda 会从当前工作目录开始向上逐级查找，找到的就覆盖全局配置。这样不同项目目录下cd进去就自动应用不同的源配置，非常适合同时维护多个来源不同环境的情况。这个行为可以用conda config --show-sources验证，它会按优先级从高到低把找到的配置文件都列出来。

4. 从 conda 本体下手：版本、校验、超时与重建

4.1 先确认你用的是哪套 solver 与哪个版本

conda 24.x 之后默认启用了 libmamba 作为依赖求解器，网络层的行为和老的经典 solver 不完全一样。有些报错文案变了，有些超时参数的作用范围也不同。

先看版本：

conda --version conda info | grep -i solver

如果 solver 显示是libmamba，而你在网上找到的解决方案是基于经典 solver 的参数，可能对不上。可以临时切回经典 solver 做对比验证：

CONDA_SOLVER=classic conda install numpy

Windows PowerShell 里是：

$env:CONDA_SOLVER="classic" conda install numpy

如果切回经典 solver 之后报错消失了，那问题就在 libmamba 的网络配置上，而不是你的网络本身。这种情况下升级 conda 版本往往能解决——libmamba 在不同版本里对超时、重试、证书的处理有过几次调整。

升级：

conda update -n base conda -y

但如果网络已经不通，升级本身也会失败，会陷入死循环。这时候有两条路：一是用离线包手动更新，二是直接换一个发行版。

我这边比较常用的做法是换成Miniforge。它默认只带conda-forge一个 channel，没有defaults，某种意义上天然绕开了repo.anaconda.com这个高频出问题的域名。安装包小，初始化快，环境变量配置也干净。对于已经确认是 channel 层面问题的场景，重装一个 Miniforge 往往比修修补补更快。

提示：重装之前先把现有环境列表导出来，conda env list > envs.txt，装完再按列表重建，别直接删目录了事。

4.2 SSL 校验关掉的正确姿势与风险边界

我知道很多人第一反应是关掉 SSL 校验。这个操作本身是有效的，但必须清楚它的边界。

关闭方式有两种。一种是命令行临时关：

conda install numpy --insecure

另一种是写进配置：

conda config --set ssl_verify false

两种都能让报错消失，但如果问题的根因是网络中间设备拦截了 TLS，你关掉校验只是把“拒绝连接”变成了“接受一个来源不明的证书”，数据完整性从此没有保障。而且在某些环境里，关掉校验之后依然会因为其他策略限制而失败，白折腾。

我的判断标准很简单：--insecure只用来验证问题是不是出在证书上。如果加上--insecure之后命令立刻成功，那就确认是证书链问题，接着该做的是导入根证书，而不是长期关闭校验。如果加上--insecure依然报同样的错，那问题根本不在证书，关校验纯属浪费时间。

用完记得恢复：

conda config --set ssl_verify true

4.3 超时和重试参数怎么定（附计算）

默认参数下，conda 的连接超时大概是 9 秒多一点，这个值在慢速网络里明显不够。但更值得算的是总耗时。

假设你的channels展开后有 4 个 URL，remote_max_retries是 3，连接超时 9 秒，那么最坏情况下一条命令要等：

4 个 channel × 3 次重试 × 9 秒 ≈ 108 秒

将近两分钟才开始报错。这期间终端没有任何输出，看起来就像卡死了，很多人等不到就 Ctrl+C 了，然后以为命令执行失败是因为别的原因。

把参数调大不是为了让失败变慢，而是为了让“慢但能通”的场景有机会成功。我的经验值是：

对应命令：

conda config --set remote_connect_timeout_secs 30 conda config --set remote_read_timeout_secs 120 conda config --set remote_max_retries 5

调大之后要注意副作用：真正的“不可达”场景下，报错会来得更晚。所以调试阶段我建议把remote_max_retries临时设成 1，先快速拿到报错信息，定位清楚了再调回去。

4.4 最后的办法：重建 base 环境

如果所有参数都试过了，base 环境还是各种奇怪的报错，那就要考虑 base 本身可能已经损坏。常见诱因包括：磁盘写入中断导致的包元数据损坏、手动往site-packages里塞过东西、多个 Python 版本在同一个环境里互相覆盖。

判断方法：

conda doctor

这个子命令在较新版本里可用，会检查环境完整性和文件一致性。老版本没有的话，用conda list --revisions看历史记录，可以回滚到某个已知正常的版本：

conda list --revisions conda install --revision 3

回滚是温和方案，但只对“能用但坏了”的环境有效。如果连 conda 命令本身都跑不动，那就只能重装。

重装的正确顺序是：先导出环境列表conda env list，再对每个重要环境conda list --explicit > spec-file.txt导出精确规格，然后卸载重装 conda，最后用conda create --file spec-file.txt逐个恢复。--explicit导出的文件里包含完整的包 URL 和哈希值，恢复时是一比一复刻，不会因为解析器版本变化导致包版本漂移。

千万别在没导出的情况下直接删目录。我吃过这个亏，一个跑了半个月的实验环境，重装之后某个依赖的次要版本变了，结果复现不出原来的结果，白折腾两天。

5. 离线兜底：当网络这条路彻底堵死

5.1 本地 channel：把包变成文件

有些环境是真的没有任何外网出口，比如绝密项目的内网机器、工业控制现场的封闭网络。这种时候再优化网络参数都是徒劳，唯一的办法是把包搬进去。

思路是把 conda 包下载成文件，然后用本地目录当 channel。第一步，在一台能上网的机器上，用--download-only把包下下来：

conda install -n base --download-only -y numpy pandas scipy

包文件会落在pkgs缓存目录里，路径用conda info查package cache那一行。把这些.conda或.tar.bz2文件拷贝到内网机器上，放到一个目录里，比如/data/offline-channel。

然后给这个目录建索引：

conda index /data/offline-channel

这个命令会生成repodata.json等索引文件，让这个目录看起来像一个标准 channel。之后就可以直接用了：

conda install --override-channels -c file:///data/offline-channel numpy

也可以不建索引，直接指定包文件路径安装：

conda install /data/offline-channel/numpy-1.26.4-py311h*.conda

这种方式最简单，代价是每次都得手动解决依赖——因为 conda 不知道那个目录里还有哪些包。

还有一种更省事的办法：如果知道确切版本，直接conda install --offline numpy=1.26.4，只要这个版本在本地包缓存里存在，conda 会直接从缓存装，完全不碰网络。前提是你之前下载过。

5.2 conda-pack：整套环境搬走

conda-pack解决的是“环境已经在 A 机器上跑通了，要原样搬到 B 机器”这个需求。它把整个环境目录打包成一个压缩包，解压后可以直接激活，不需要重新解析依赖。

源机器上：

conda install -n base conda-pack -y conda pack -n myenv -o myenv.tar.gz

如果报错说环境里有未打进去的包，加--ignore-missing-files跳过。

目标机器上：

mkdir -p ~/envs/myenv tar -xzf myenv.tar.gz -C ~/envs/myenv source ~/envs/myenv/bin/activate conda-unpack

conda-unpack这一步不能省。打包时环境里的脚本 shebang 和路径都是源机器的绝对路径，conda-unpack会把它们重写成目标机器的路径。跳过这一步，激活后各种命令会提示找不到文件。

Windows 上路径差异更大，源机器和目标机器的用户名不同、盘符不同都会出问题。我的做法是尽量让两台机器的用户名保持一致，或者干脆打包成 tar 之后手动检查Scripts目录下的 shebang。

5.3 pip 侧的车轮文件离线安装

conda 装不上的时候，很多人会切到 pip。但如果网络本来就不通，直接pip install一样报错，只是错误信息变成Could not find a version that satisfies the requirement。

正确做法是在有网的机器上先把 wheel 文件下全：

pip download -d ./wheels \ --only-binary=:all: \ --platform manylinux2014_x86_64 \ --python-version 311 \ --implementation cp \ -r requirements.txt

--only-binary=:all:强制只下二进制包，避免下到源码包还得在目标机器上编译。--platform和--python-version要和目标机器一致，否则下下来的轮子装不上。这一步是离线安装最容易翻车的地方——版本和平台对不上，装的时候提示not a supported wheel on this platform。

把wheels目录整包拷到目标机，然后：

pip install --no-index --find-links=./wheels -r requirements.txt

--no-index表示完全不查任何在线索引，--find-links指定本地目录。这两个必须同时给，只给--find-links的话 pip 还是会去查默认索引，网络不通依然报错。

如果目标机和源机器架构不同，比如源机器是 x86_64、目标是 ARM，那就得在目标架构的机器上做pip download，或者用交叉编译出来的轮子。这种情况我一般建议直接在那台 ARM 机器上临时接一次网，省下来的时间足够喝两杯咖啡。

6. 高频场景速查与踩坑记录

6.1 十种报错现象对照表

下面这张表是我从自己的排障记录里归纳的，按“现象”查“动作”，命中率大概八成。

6.2 几个只有踩过才知道的细节

别迷信“重装能解决一切”。我见过太多人一遇到 conda 报错就卸载重装，结果重装完发现问题出在公司网络的 DNS 上，重装十遍也没用。排查顺序应该是从外到内：先网络、再 channel 配置、再 conda 本体、最后才重装。每一步都要有明确的验证结果再往下走。

报错里的域名是最强线索，先看它。很多人搜报错只搜CondaHTTPError HTTP 000，搜出来一堆答案但都不对症。其实只要把报错 URL 里的域名拎出来，问题范围立刻缩小一半：是官方域名、是镜像站域名、还是你某个同事三年前留下的内网地址。我遇到过最离谱的一次，是.condarc里有个早已下线的内网 channel，所有人都在报错，但没人记得它的存在。

关了 SSL 校验之后一定要恢复。我给自己定了个规矩：任何--insecure的操作之后，立刻在便签上写下“恢复校验”，并且当天必须处理掉。这事拖久了就会忘，忘了之后你的环境就一直在裸奔，直到某天从一个不可信的源装进来一个奇怪的包。

国内镜像站同步有延迟，别把“找不到最新版本”当成故障。镜像同步通常是定时任务，新包发布后几个小时甚至一天才同步过去很正常。这时候conda search找不到某个刚发布的版本，不是镜像坏了，是它还没跟上。真要用最新版，就临时加一个--override-channels -c指向官方源装这一个包，装完再切回去。

多个环境共享 base 的包缓存，清缓存前想清楚。conda clean --all会清掉pkgs目录下所有环境的共享包缓存。在离线环境或者带宽紧张的情况下，这个操作可能让你后面所有环境都得重新下载。我一般只清索引conda clean -i，包缓存留着，磁盘实在不够时再针对性地清。

配置文件的位置比内容更容易出错。~/.condarc只是其中一个位置，还有/etc/conda/.condarc（系统级）、环境目录下的.condarc、以及CONDA_ROOT下的一份。conda config --show-sources会按优先级把所有找到的列出来，排查“为什么配置没生效”时这是第一条命令，没有之一。

最后分享一个我自己养成的习惯：每次配好一套能用的.condarc，我都会在旁边存一份带注释的副本，命名成.condarc.working。下次遇到疑难杂症，先用这份能用的替换回去，验证是不是配置问题；确认是配置问题之后再逐行比对差异。比起从头猜哪里配错了，这个方法的效率高出太多。环境这东西，能快速回到“已知可用状态”，比什么都重要。