笙亿网络策划

Ollama拉取模型超时失败后切换源或设置代理的完整方案

约 6 分钟读完 117 阅
文章导读
Ollama 拉取模型超时，通常卡在连接 registry.ollama.ai 这个环节，而不是模型文件本身太大。先确认你遇到的是 DNS 解析慢、TCP 连接被卡、还是下载中断：在超时复现时执行 curl -v https://registry.ollama.ai/v2/，观察返回是连接超时、TLS 握手失败，还是能连上但速度极慢。这个区分决定了你是换镜像源还是走代理。
📋 目录
  1. Ⅰ 先固定拉取命令和验证基线
  2. Ⅱ 方案一：切换镜像源（先做，成本最低）
  3. Ⅲ 方案二：为 Ollama 设置代理（更通用）
  4. Ⅳ 常见失败场景与排查动作
  5. Ⅴ 验证清单：确保你的方案真正生效
A A

Ollama 拉取模型超时，通常卡在连接 registry.ollama.ai 这个环节，而不是模型文件本身太大。先确认你遇到的是 DNS 解析慢、TCP 连接被卡、还是下载中断：在超时复现时执行 curl -v https://registry.ollama.ai/v2/，观察返回是连接超时、TLS 握手失败，还是能连上但速度极慢。这个区分决定了你是换镜像源还是走代理。

判断方向：Ollama 拉取模型超时，先分两类处理——一类是网络层连不上 registry.ollama.ai，优先换镜像源或用环境变量走代理；另一类是能连上但下载中途断，优先调低并发、换更稳的网络，并开启断点续传验证。代理配置只管当前 shell，配置后必须重启 ollama serve 并重新拉取验证。镜像源只改模型存储地址，不会改变你本地模型的使用方式。

先固定拉取命令和验证基线

不管接下来换源还是走代理，先建立一条可重复的拉取命令，方便对比配置前后差异。建议在目标机器上固定使用 ollama pull qwen2.5:7b 作为测试模型，它体积适中，能暴露大多数网络层问题。

# 清空本地已拉取的一半文件，避免旧残留下扰验证
rm -rf ~/.ollama/models/blobs/<目标模型digest前缀>* 2>/dev/null; ollama pull qwen2.5:7b

执行前记录开始时间和失败信息；如果命令能跑完，记录总耗时。后续换源或设置代理前后，都用同一命令同一网络环境验证。注意 rm -rf 只针对测试模型目录，不要清空整个 models 目录。

方案一：切换镜像源（先做，成本最低）

Ollama 支持通过环境变量 OLLAMA_HOST 控制服务地址，但镜像源通常不是改这个，而是设置 OLLAMA_REGISTRY 指向兼容的 registry 地址。这一步适合“能连外网但连官方 registry 很慢”的场景。

具体做法：在启动 ollama serve 的 shell 里设置环境变量后再启动服务。例如使用国内镜像源时，常见配置为：

export OLLAMA_REGISTRY=https://docker.1ms.run
ollama serve

镜像源地址不固定，不同服务商提供的可用性和同步时效不同，建议先拿一个模型试拉，如果报 404 就换另一个镜像地址。验证方式：拉取时观察 ollama pull 输出的下载 URL 域名是否变为镜像地址，或者用 curl -I https://镜像地址/v2/ 看是否返回 200。风险是镜像源可能同步滞后，拉不到最新模型 tag；同时官方 registry 被墙的情况下，镜像源也可能失效，需要同时准备代理方案。

Ollama拉取模型超时失败后切换源或设置代理的完整方案

方案二：为 Ollama 设置代理（更通用）

如果镜像源不可用，或你想保持官方源直接拉取，就给 Ollama 进程显式设置代理。Ollama 本身不读系统代理，需要你在启动它的终端里注入 HTTP_PROXY 和 HTTPS_PROXY。这个方案适合“有代理可用但 ollama 没走代理”的机器。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1
ollama serve

代理端口换成你自己的实际端口。启动后另外开一个终端执行 ollama pull qwen2.5:7b，如果还超时，先看代理是否只对部分域名生效，可以用 curl -x http://127.0.0.1:7890 https://registry.ollama.ai/v2/ 单独测试。注意：如果在 systemd 或 Docker 中运行 Ollama，代理变量要写在对应启动文件里，单纯在普通终端 export 不会影响到后台服务。

常见失败场景与排查动作

配置了代理仍然超时，先别急着换源。按顺序检查三项：

  • 确认 Ollama 服务真的重启了：环境变量只在 ollama serve 启动时读取，改完 export 必须重启服务进程，否则代理配置不会生效。
  • 确认代理本身能访问 registry：用 curl -x 代理地址 https://registry.ollama.ai/v2/ 手动验证，返回 JSON 而不是超时说明代理可用。
  • 看日志区分网络层和下载层错误：后台运行 ollama serve `--verbose` 可以输出详细请求日志；如果日志显示连接建立但下载中断，大概率是代理或网络带宽问题，而不是 DNS 问题。

如果是下载中途反复断，且代理可用，可以试试降低并发下载数。Ollama 默认并发拉取层文件，网络不稳时会加剧超时。设置 OLLAMA_NUM_PARALLEL=1 强制串行拉取，代价是变慢，但能减少中断概率。

验证清单：确保你的方案真正生效

  1. 执行 ollama pull qwen2.5:7b 完整成功，无任何重试提示。
  2. 再次拉取同一个模型，显示 already exists 说明本地缓存正常。
  3. 用 env | grep -i proxy 确认当前 shell 代理变量确实存在。
  4. 如果走镜像源，用 ollama show qwen2.5:7b `--modelfile` 查看模型来源，确认拉取地址是镜像域名而非常规域名，说明换源已生效。

这些验证动作做完，基本能确定是网络层问题还是 Ollama 配置问题。若所有步骤都通过但模型仍超时，就要回到网络本身检查防火墙或运营商层面限制，此时换任何源和代理都很难解决。