依赖下载超时，为什么四个包管理器的处理方式各不相同
pip 报 ReadTimeoutError，cargo 停在 Updating index，go mod 卡在 downloading，Maven 反复重试同一个 jar，这些都是拉依赖超时，但排查手段并不通用：四个工具的默认超时不同，镜像配置的位置不同，超时发生的阶段也不同。本文按 pip、cargo、go mod、Maven 的顺序，逐个给出镜像配置和超时参数的写法，最后用一张对比表汇总。所有默认值和键名对照各工具官方文档整理，查阅日期为 2026 年 9 月 20 日，文中的镜像地址一律使用 example 占位域名，请替换成你实际使用的镜像站。
动手之前先做一件小事：判断超时发生在哪个阶段。连接阶段超时，说明到目标域名的通路有问题，调大超时数值没有意义；下载阶段超时，说明连得上但速度太低或者中途停顿，这时超时和重试参数才有用。用 curl -o /dev/null -sS -w "%{time_connect} %{time_appconnect} %{speed_download}\n" 目标地址 测一次，就能大致分清是连不上、握手慢，还是下载速度低。
pip：超时和重试是两个独立参数
pip 官方文档里，--timeout 是套接字超时，默认 15 秒；--retries 是建立新 HTTP 连接的最大尝试次数，默认 5 次。也就是说，一个响应慢的镜像源可能在 15 秒内没有返回数据就被判定超时，再重试 5 次，总耗时反而更长。
怎么临时调整，怎么永久生效
临时使用镜像并放宽超时，可以直接在命令行里写：
pip install --index-url https://mirror.example.com/simple --timeout 60 --retries 8 requests需要长期生效时，用 pip 自带的配置命令写入配置文件，或者设置对应的环境变量 PIP_INDEX_URL、PIP_TIMEOUT、PIP_RETRIES：
pip config set global.index-url https://mirror.example.com/simple
pip config set global.timeout 60镜像如果只提供 HTTP 而没有有效证书，pip 会拒绝连接，可以用 --trusted-host 把该主机标记为可信，但这个选项会降低传输安全性，只建议在内网可控环境中使用。
cargo：慢速连接会被主动中止再重试
cargo 的行为比 pip 更细致。官方配置文档里，http.timeout 默认 30 秒，net.retry 默认重试 3 次，还有一个容易被忽略的 http.low-speed-limit，默认值是 10：如果平均传输速度在 http.timeout 的时间内一直低于每秒 10 字节，cargo 会判定连接太慢，中止并重试。这意味着线路极不稳定时，你看到的「超时」其实可能是慢速中止。
怎么配置镜像与代理
镜像通过替换源来配置，写在 ~/.cargo/config.toml 中：
[source.crates-io]
replace-with = "my-mirror"
[source.my-mirror]
registry = "sparse+https://mirror.example.com/crates.io-index/"
[http]
timeout = 60
[net]
retry = 5注册表协议方面，文档说明 registries.crates-io.protocol 默认是 sparse，它通过 HTTPS 只下载需要的索引文件，相比克隆整个 git 索引要轻很多。代理的读取顺序是：CARGO_HTTP_PROXY，其次是 HTTPS_PROXY 或 https_proxy，HTTP 请求则用 http_proxy。如果这些都没设置，cargo 还会检查全局 git 配置里的 http.proxy。依赖里有 git 仓库时，设置 net.git-fetch-with-cli = true 可以改用系统的 git 命令来拉取，这样 git 自己的代理和 SSH 配置也会生效。
go mod：没有专门的超时参数，重点在 GOPROXY 的写法
Go 模块参考文档里，GOPROXY 是以逗号分隔的代理地址列表，也可以包含关键字 direct（直接访问版本控制系统）和 off（不发起任何请求），默认值是 https://proxy.golang.org,direct。我查阅的文档里没有看到专门控制下载超时的环境变量，所以 Go 的处理重点是把代理列表配对。
为什么第一个代理不可达时，不会自动换下一个
文档的示例说明，用逗号分隔的多个代理，只有前一个代理对请求返回 404 或 410 时，才会尝试下一个。连接超时不在这个描述之列，所以把一个不稳定的镜像放在列表第一位，超时的时候通常是直接报错，而不是悄悄换到下一个。写法示例：
go env -w GOPROXY=https://goproxy.example.com,direct私有模块需要用 GOPRIVATE 或 GONOPROXY 排除在代理之外，校验和数据库由 GOSUMDB 控制。如果 go mod download 卡在校验和验证阶段，要单独检查这一项，而不是继续调整代理。
Maven：先确认你的版本用的是哪套传输层
Maven 官方文档特别提醒，从 3.9.0 起默认传输层不再是 Wagon，而是 Resolver 自带的原生传输。这一点决定了你该改哪里：老资料里的 Wagon 超时配置写在 settings.xml 的 server 节点下，新版本则通过 Resolver 的配置属性控制。先执行 mvn -v 确认版本。
镜像怎么写，超时怎么调
镜像配置写在 ~/.m2/settings.xml，官方示例如下，mirrorOf 为 central 表示替换中央仓库，同一个仓库只允许配一个镜像，逗号分隔的列表里不要有空格：
<mirrors>
<mirror>
<id>other-mirror</id>
<name>Other Mirror Repository</name>
<url>https://mirror.example.com/maven2</url>
<mirrorOf>central</mirrorOf>
</mirror>
</mirrors>超时方面，Resolver 配置页给出的 HTTP 属性包括连接超时（默认 30000 毫秒）、请求超时（默认 1800000 毫秒，即 30 分钟，指两个数据包之间的最大空闲时间）以及重试次数（默认 3）。不同 Maven 版本内置的 Resolver 版本不同，属性名前缀可能有差异，具体写法请以你所用版本对应的 Resolver 配置页为准，可以通过 -D 参数、.mvn/maven.config 或 MAVEN_OPTS 传入。
四个工具的对照表
| 工具 | 默认超时与重试 | 镜像配置位置 | 代理相关 |
|---|---|---|---|
| pip | --timeout 15 秒，--retries 5 次 | --index-url 或 pip config 的 global.index-url | 命令行 --proxy 或环境变量 |
| cargo | http.timeout 30 秒，net.retry 3 次，低速阈值 10 字节/秒 | config.toml 的 source 替换 | CARGO_HTTP_PROXY、HTTPS_PROXY |
| go mod | 无专门超时项，依赖 GOPROXY 列表 | go env -w GOPROXY | 沿用系统代理环境变量 |
| Maven | 连接 30000 毫秒，请求空闲 1800000 毫秒，重试 3 次 | settings.xml 的 mirrors | settings.xml 的 proxies |
pip 的代理参数和 Go、Maven 的代理写法，我没有逐项对照官方文档，表中该列只列出方向，具体请查阅对应工具的文档。
镜像配好了仍然慢，问题可能在出口线路
镜像解决的是源站离得远的问题，如果镜像本身的连接也时快时慢，就要看线路。一个可以自己复现的对照方法：清空本地缓存后，在同一台机器上拉同一个中等大小的依赖包，分早、中、晚三个时段各做三次，记录耗时和 curl 的 time_connect 数值，再换一个网络环境重复一遍。波动集中在某个时段或某个网络，说明线路是瓶颈，调超时参数只会让失败来得更慢。
需要同时使用多个 AI 和开发工具的团队，可以考虑给开发机换一条更稳定的出口。NasaCode 提供通用的全球加速能力，并针对 Claude Code、Cursor 等 IDE 场景做了直连优化，依赖拉取这类日常操作也走同一条线路。是否改善，仍以你自己的耗时记录为准。
先判断超时发生在连接还是下载阶段，再决定是换镜像、加代理还是调参数；pip 看 --timeout 和 --retries，cargo 看 http.timeout、low-speed-limit 和 sparse 协议，Go 看 GOPROXY 列表的写法，Maven 先确认传输层版本。遇到镜像和线路都需要评估的情况，可以用文中的耗时记录法先取数据。本文的默认值和键名以 2026 年 9 月 20 日查阅的官方文档为准，升级工具版本后请重新核对。
延伸阅读
