ollama配置国内源怎么弄，下载慢到超时的问题终于解决

很多人第一次处理ollama配置国内源时会卡在细节上，昨天夜里十一点，我在一台刚装好的 Ubuntu 机器上执行 ollama pull qwen2.5:7b，进度条卡在 12% 一动不动，等了二十分钟直接超时。第一反应是网络断了，ping 出去却通，浏览器也能开网页。

索性翻日志，才发现是拉模型时连不上仓库。这篇 ollama配置国内源 的记录就是这么来的，写给同样卡在进度条前的你。先说清楚一件事：ollama 官方没有「国内源」这个配置项可填，网上那些镜像地址大半是第三方转的，稳定性没人担保。所以我这里给的是两条能落地的路——把代理喂给服务，或者把 GGUF 下好再本地导入。

ollama下载慢，先分清卡在哪一段

很多人一上来就怪宽带，我最初也这么想。后来在 pull 的同时另开一个终端跑 ss -tnp，才发现连接一直挂在跟 registry 的握手上，压根没进下载阶段。

我一般先看 pull 的输出里有没有 resolving、pulling manifest 这类字样。卡在 resolving，说明连不上仓库；已经在拉某一层但速度只有几 KB，那是线路的事，性质完全不一样。

ollama pull 干的事分两段：先向仓库要 manifest，再按层拉 blob。国内直连的时候，前一段就容易超时，后一段慢得像拨号。你把这两段拆开看，才知道该动哪一头。

我的判断是：manifest 拿不到，去查 DNS 或者挂代理；blob 下得慢，才轮到镜像站出场。搞混了就会白跑一整晚，我干过。所以做 ollama配置国内源 之前，先把这两段分开看。

顺带说一句，pull 是能中断再续的，下完的层会留在本地，重新拉只补没下来的部分。知道这点你就不必守着一条断线硬等。

ollama配置国内源 之前，先把 OLLAMA_MODELS 挪走

配源之前先挪模型目录，听着像跑题，其实是我踩过坑才懂的。模型全堆系统盘，几十个 G 下去根分区直接红，服务起不来。

挪之前先 df -h 看一眼目标盘，别把模型扔进另一个快满的分区。我用的是单独挂载的数据盘，容量给得宽一点，几个 7B 模型加上缓存才不至于挤。

ollama配置国内源 的第一步不在网络上，而在磁盘上。目录挪好，后面下载失败重试才不至于把盘写满。

sudo mkdir -p /data/ollama/models /etc/systemd/system/ollama.service.d
sudo chown -R ollama:ollama /data/ollama/models
sudo tee /etc/systemd/system/ollama.service.d/override.conf <<'EOF'
[Service]
Environment="OLLAMA_MODELS=/data/ollama/models"
Environment="OLLAMA_HOST=127.0.0.1:11434"
EOF
sudo systemctl daemon-reload && sudo systemctl restart ollama

上面这段写的是 systemd 的 drop-in 配置，路径和变量名都是真实的。OLLAMA_MODELS 换模型目录，OLLAMA_HOST 换监听地址，两个变量名别拼错。

chown 那行千万别省。ollama 服务是以 ollama 用户跑的，目录属主还是 root 的话，重启之后一 pull 就 Permission denied，日志里报得含含糊糊，很容易当成网络问题。我第一台机器就是这么白折腾了半小时。

改完别急着 pull。先跑 sudo systemctl show ollama -p Environment 看一眼，输出能对上才算生效。重点看 Environment 那一行，服务 active 不等于变量吃进去了，这是两码事。

我头一回配就栽在这，服务重启成功，日志里还是默认路径。老实说那一刻挺泄气，明明每一步都做了。

把目录确认好，再谈网速。这也是 ollama配置国内源 里最容易被跳过的一步。

走代理做 ollama镜像加速，最省事的一条路

环境里本来就有代理的话，别急着找镜像站，直接把代理喂给 ollama 的 systemd 服务。这也是 ollama配置国内源 里我最常用、最不容易翻车的一条路。

sudo tee /etc/systemd/system/ollama.service.d/proxy.conf <<'EOF'
[Service]
Environment="HTTPS_PROXY=http://127.0.0.1:7890"
Environment="HTTP_PROXY=http://127.0.0.1:7890"
Environment="NO_PROXY=127.0.0.1,localhost"
EOF
sudo systemctl daemon-reload && sudo systemctl restart ollama

7890 是常见默认端口，换成你自己代理的地址就行。改完一样要 daemon-reload，不然白改。

OLLAMA_NUM_PARALLEL 管的是并发请求数，不是下载线程，调大它并不会让 pull 变快，我试过，没什么用。

有个细节我踩过：只写 HTTPS_PROXY 有时候不够，中间有些库还会发 http 请求，两个都写上省事。NO_PROXY 里带上 127.0.0.1，是防止 ollama 自己回连本地端口时也绕去代理，跟你在终端里敲的那条 curl 没关系。

怎么确认真走了代理？拉个 qwen2.5:0.5b 试水，体积小，几十秒就能看出动静。还卡着的话看 journalctl -u ollama -n 50，报错写得挺直白，一眼能认出来。

配完我习惯从本机打一下接口 curl http://127.0.0.1:11434/api/tags，能吐出 JSON 就说明服务活着、变量也吃到了。返回空或者 connection refused，先回去查 OLLAMA_HOST。

没有代理时，ollama配置国内源 换个走法

有些机器压根出不了网，只能走内网镜像。我的做法是在能出网的机器上把 GGUF 下好，scp 过去再导入，麻烦但管用。大文件传一半断过一次，后来改用 rsync -P，断了能接着续，省事不少。

cat > Modelfile <<'EOF'
FROM /data/models/qwen2.5-7b-instruct-q4_k_m.gguf
PARAMETER num_ctx 8192
EOF
ollama create qwen2.5-local -f Modelfile

PARAMETER num_ctx 是我习惯加的，默认上下文偏小，长文档容易截断，取值按显存来，别硬抄别人的数。

导入完 ollama list 能看到 qwen2.5-local，就说明这条链路通了。名字随你起，关键是 FROM 后面那个路径要跟文件实际位置对上。

GGUF 从哪找？国内几个模型社区有镜像，搜模型名加 gguf 一般能翻到。文件名里的 q4_k_m 是量化等级，位越低占用越小、效果越钝，自己权衡。GGUF 这条路我只在两台内网机上用过，算是 ollama配置国内源 的备选方案。各家命名不统一的地方，以官方文档为准。

几个我踩过的坑

ollama配置国内源 这事我前后在三台机器上折腾过，坑基本都集中在这几个地方。

有次改完 override.conf 直接 restart，忘了 daemon-reload，变量压根没进去，白折腾半小时。现在我改完一定先 reload 再看一眼。

在 Docker 里跑 ollama 又是另一回事，宿主机配了代理容器里没有。容器得单独传 -e HTTPS_PROXY，漏一个就卡住，这点特别容易忘。

还有个隐性坑：公司网络里没把内网段写进 NO_PROXY，请求全被代理绕一圈，反而更慢。看懂这点能省下不少排查时间。

顺手提一句：ollama配置国内源 是让请求走更近的路，不是把模型变快，加载该多久还是多久，别指望配完推理就起飞。

Windows 桌面版的朋友，变量在系统设置里加，加完要把托盘图标退掉重开，不然读不到。这个我确认过好几回。

折腾完这几台机器，我把配置记成了一份清单，换机器直接抄，省得再重新想一遍。

折腾下来最大的感受是：先看清楚卡在哪，再决定改什么。别一上来就找镜像站，那多半是白跑。