昨晚在自己机器上执行ollama pull qwen，等了几秒钟，终端直接甩了这串报错：
Error: pull model manifest: dial tcp: lookup registry.ollama.ai i/o timeout说实话这种报错我碰到过不止一次，网上也经常有人问。它既不是模型本身的问题，也不是 Ollama 装坏了，而是客户端在获取模型清单（manifest）的第一步就失败了——域名解析都过不去。今天我把这次的排查过程和行之有效的修复方法完整记录下来，包括怎么确认是 DNS 问题、怎么改配置、怎么离线兜底，适合所有被 ollama 下载卡住的朋友参考。文章既覆盖个人电脑，也适用于内网服务器和公司工作站。
qwen 是阿里开源的千问系列大模型，Ollama 仓库里的 qwen 提供了多个参数量版本，日常体验拉 7B/14B 这类量化版本就够用。但如果你连模型清单都拿不到，后面所有事情都无从谈起，所以先把网络层的问题解决掉。
1. 先看懂这行报错：i/o timeout 卡在 DNS 而不是连接
1.1 pull model manifest 环节发生了什么
执行ollama pull qwen时，Ollama 客户端要先联系模型仓库服务，读取 qwen 模型的 manifest 清单文件。这个清单里记录了模型分层的 digest、大小、存储位置等元数据。只有当 manifest 拿到之后，客户端才会开始拉取真正的模型权重文件。
所以Error: pull model manifest这半句说明：还没走到下载权重的阶段，问题出在最前面的清单获取环节。很多人误以为这是模型文件太大、下载慢导致的超时，然后反复重试，其实方向就错了。你重试多少次都没用，因为卡住的位置在整个链路的最前端。
1.2 为什么"lookup"失败却提示 i/o timeout
后半句dial tcp: lookup registry.ollama.ai i/o timeout的关键部分是lookup。这个关键字代表DNS 解析阶段，也就是把域名registry.ollama.ai解析成 IP 地址的过程。整套流程里的网络活动有三段：DNS 解析、TCP 握手、TLS 鉴权。lookup失败说明第一步就断了，连 IP 都没拿到，更谈不上和服务器建立连接。
那为什么报错里写的是i/o timeout而不是no such host？这两个错误代表不同的故障方向。no such host表示 DNS 服务器明确回答"查无此域名"，通常是域名写错了，或者本地安全软件做了域名拦截；而i/o timeout表示向当前配置的 DNS 服务器发起查询后，在等待回复期间超时了。也就是说，DNS 请求发出去了，但没人应答，或者应答在途中丢了。
这种情况最常见的原因是：本机设置了一个响应缓慢或不可达的 DNS 服务器，或者当前网络路径上的 DNS 查询被某种因素干扰。在我这次的实际环境里，系统默认 DNS 指向了路由器下发的内网地址，但那个地址对公网域名做了转发却没有成功拿到递归结果，表现就是 timeout。
1.3 三个绕不开的先决条件
想让registry.ollama.ai能被正常访问并拉取模型，实际上依赖三个条件同时成立：
- DNS 能正确解析出域名对应的可用 IP；
- 出方向 443 端口能独立建立 TCP 连接；
- 从本机到服务器之间的路由不丢包、不震荡。
排查的时候最好按 DNS、端口、路由的顺序来。DNS 在最前面，成本最低，往往也是最大的拦路虎。不要一上来就怀疑模型仓库宕机或者 Ollama 程序有问题，先把这三个前置条件验证清楚，问题基本能缩小到很小的范围。
2. 完整排查链路：我是怎么一步步定位根因的
2.1 先确认本机网络基础，别一上来就改动配置
遇到这个报错后，我第一件事不是立刻改 DNS，而是先看本机基础网络是否正常。先 ping 网关和公网 IP，确认物理链路是通的：
# Windows 下测试公网 IP 连通性 ping -n 4 223.5.5.5 # Linux 下测试公网 IP 连通性 ping -c 4 223.5.5.5这里刻意不 ping 域名，因为 ping 域名本身就会触发 DNS 解析，域名解析有问题时 ping 也会失败，那样就没法和后面的结果作区分。先 ping IP 确认出网正常，再 ping 域名定位 DNS 环节。这一步我实测下来是通的，说明物理链路和网关都没问题。
接下来再 ping 一下域名：
ping registry.ollama.ai如果 IP 能通而域名 ping 不通，或者域名 ping 直接报"找不到主机"，那问题就基本锁定在 DNS。如果两者都通，但 ollama 还是报 time out，那可能需要检查是不是端口或者进程级网络限制，不过这种概率相对小。
2.2 nslookup 实测：把解析卡在哪一步暴露出来
接着我用 nslookup 直接查域名：
nslookup registry.ollama.ai如果返回DNS request timed out，基本能确定问题出在 DNS 服务器或中间链路。此时再向公共 DNS 服务器指定查询一次：
nslookup registry.ollama.ai 223.5.5.5这一步能区分两种场景：如果指定公共 DNS 后能迅速解析出 IP，说明是当前系统使用的 DNS 配置有问题；如果指定公共 DNS 后依然超时，说明可能是本机防火墙、路由器或运营商网络对 UDP 53 端口的向外查询有限制，需要进一步排查。
我在实测中遇到的情况是：系统默认的 DNS 解析超时，但指定 223.5.5.5 后能正常解析，所以问题直接锁定在 DNS 服务器配置这一层。结论很明确：不是网络断了，也不是模型仓库挂了，就是本机拿到的 DNS 配置不合格。
2.3 常见陷阱一：IPv6 DNS 查询拖慢整体解析
还有一个非常容易被忽略的因素：IPv6。现在很多系统会同时发起 A（IPv4）和 AAAA（IPv6）记录的查询。如果网卡配置了 IPv6 地址，但实际网络没有可用的 IPv6 路由，那么 AAAA 查询就会一直等，等到超时再回退到 IPv4，最终直观感受就是整体解析非常慢，甚至被上层判断为超时。
排查方法：
# Windows 查看本机 IPv6 配置 ipconfig /all # Linux 查看系统 IPv6 地址 ip -6 addr show如果确认没有可用的 IPv6 出口，但网络环境又反复出现解析超时，可以考虑在系统层面把 IPv6 的解析优先级降低，或者直接关闭网卡上的 IPv6 绑定，后面的修复方案里会展开说明。
2.4 常见陷阱二：域名解析被 hosts 或安全软件拦截
另一个排查方向：本机的 hosts 文件、安全软件、或者路由器内置的域名过滤策略，都可能对registry.ollama.ai做特殊处理。检查一下 hosts 文件：
# Windows type C:\Windows\System32\drivers\etc\hosts # Linux cat /etc/hosts如果在 hosts 里意外存在registry.ollama.ai的绑定记录，并且指向了一个不可达的 IP，那么所有查询都会瞬间被定向到一个坏 IP 上，表现同样是连接超时。这个问题在安装过各种安全软件、网络优化软件的机器上尤其常见，建议顺手看一眼，有异常记录直接清掉。
2.5 汇总诊断结果与判定方向
| 检测动作 | 结果A | 结果B | 结论 |
|---|---|---|---|
| ping 公网 IP | 通 | 不通 | 不通先查网卡、网关、路由器 |
| nslookup 默认 DNS | 超时 | 正常返回 | 超时说明默认 DNS 有问题 |
| nslookup 指定 223.5.5.5 | 正常 | 超时 | 指向系统 DNS 配置问题 |
| curl 测试 443 端口 | 通 | 不通 | 端口被防火墙/安全组拦截 |
这张表基本能覆盖 90% 的registry.ollama.ai解析超时场景。链路一旦定位清楚，修复就很直接了。我这次的情况对应表里的第三行：默认 DNS 超时，指定公共 DNS 正常，所以整个修复思路就是围绕替换 DNS 配置展开。
3. 五条修复路径，按成功率和成本排序
3.1 方案A：把 DNS 换成公共 DNS，最推荐
实测最有效的办法，是把系统 DNS 改成公共 DNS。这是成本最低、改动最小的操作，推荐优先尝试。Windows 下以管理员身份运行：
netsh interface ip set dns "以太网" static 223.5.5.5 netsh interface ip add dns "以太网" 114.114.114.114 index=2注意网卡名要和ipconfig显示的一致，可能是"以太网""WLAN"或"Ethernet0"之类。改完之后刷新 DNS 缓存：
ipconfig /flushdnsLinux 下如果使用传统的 /etc/resolv.conf 管理方式，直接编辑：
sudo vim /etc/resolv.conf写入：
nameserver 223.5.5.5 nameserver 114.114.114.114 options timeout:2 attempts:2options timeout:2 attempts:2这两个参数很关键：每 2 秒就判定一次查询超时并重试，总共最多 2 次。默认值在有些系统里是 5 秒甚至更长，遇到网络抖动时会让人误以为服务彻底不可用。如果你用的是 Ubuntu 22.04+ 这类带 systemd-resolved 的系统，直接改 /etc/resolv.conf 会在重启后被覆盖，正确做法是用resolvectl：
sudo resolvectl dns 全局 223.5.5.5 sudo resolvectl dns eth0 223.5.5.5这里的eth0要替换成实际网卡名，resolvectl status可以查看当前生效的 DNS 配置。改完之后重新测试：
nslookup registry.ollama.ai一旦解析速度从超时变成几十毫秒返回结果，马上重新执行ollama pull qwen，大概率直接恢复。我在这次修复后第一次 pull 就成功了。
3.2 方案B：关闭 IPv6 解析或调整其优先级
如果你确认网络环境没有可用的 IPv6 出口，那减小 AAAA 记录的查询影响会有立竿见影的效果。Windows 上最简单的方式是在网卡属性里取消勾选"Internet 协议版本 6 (TCP/IPv6)"，或者用 PowerShell 禁用：
Get-NetAdapterBinding -ComponentID ms_tcpip6 | Disable-NetAdapterBindingLinux 上可以在 /etc/gai.conf 中取消注释，强制优先走 IPv4：
precedence ::ffff:0:0/96 100这样 DNS 解析会优先返回 A 记录的 IPv4 结果，不会因为 AAAA 查询卡住而拖慢整个流程。这个方案对双栈配置不完整的机器来说很实用。不少云服务器和家用路由器其实没有真正的 IPv6 出口，但系统默认开启了 IPv6 协议栈，结果就是每次解析都要等一遍 AAAA 超时，拉模型自然被拖到 timeout。
3.3 方案C：hosts 静态绑定，应急用别当长期方案
临时救急的时候，可以在 hosts 文件里把域名直接绑定到一个可用的 IP。前提是你要先拿到一个正确的、可达的 IP，可以通过在线 DNS 查询工具或者下面的命令获取：
nslookup registry.ollama.ai 223.5.5.5拿到 IP 后，写入 hosts 文件：
# Windows notepad C:\Windows\System32\drivers\etc\hosts # Linux sudo vim /etc/hosts格式：
1.2.3.4 registry.ollama.ai这里必须提醒一下：registry.ollama.ai是 CDN 形态的域名，它的 IP 会随运营商和地域发生变化，手工绑定一个 IP 可能今天能用，明天就失效。所以这个方案我只建议应急使用，问题解决后优先回到方案A。如果 hosts 里原来就有相关条目，记得一并清理，避免旧 IP 残留导致后续又踩坑。
3.4 方案D：离线兜底，从可用环境拉模型再导入
如果 DNS 层面的问题短时间解决不了，或者你在内网环境里根本没有外网出口，那应该走离线路径。
第一种做法：找一台能正常访问外网且能跑 Ollama 的机器，执行ollama pull qwen，然后把本地的 Ollama 模型目录完整拷贝到目标机器。Ollama 的模型默认存在用户目录下的.ollama/models里，Windows 路径是%USERPROFILE%\.ollama\models，Linux 路径是~/.ollama/models。拷贝时注意保持blobs目录和manifests目录的相对结构，可以用 scp 或者优盘转移：
scp -r user@source-host:~/.ollama/models/* target-host:~/.ollama/models/覆盖到目标机器同样的位置后，重启 Ollama 服务，再执行ollama list就能看到模型。
第二种更可控的做法：使用ollama create从 GGUF 文件导入。先找可访问的模型站点下载 qwen 对应的 GGUF 文件，比如 Q4_K_M 量化版本，然后在本地写一个 Modelfile：
FROM ./qwen2.5-7b-instruct-q4_K_M.gguf在同目录执行：
ollama create qwen-local -f ./Modelfile这样即使完全没有外网访问能力，也能在离线环境里跑起本地 qwen 模型。缺点是需要自己维护模型文件来源和校验，但胜在稳定可靠，适合生产环境。我一般在部署到隔离内网前都会先准备好这样的模型包，省得到现场再抓瞎。
3.5 方案E：检查企业网络或路由器出站限制
如果你的办公网络或自建路由器有出站访问控制，可能存在两种限制：UDP 53 端口只允许访问内网 DNS，不允许向外网 DNS 服务器发起查询；或者服务器 IP 白名单里没有registry.ollama.ai。这类限制无法靠客户端配置解决，正确做法是找到网管或路由器管理后台，确认出站规则是否放行了：
- 目的地址：registry.ollama.ai
- 协议端口：TCP 443
- DNS 查询所需的 UDP 53 对公网 DNS 的访问
我自己曾在内网环境遇到过类似情况，所有域名解析都走内网 DNS，但内网 DNS 对registry.ollama.ai这个新域名没有做递归查询配置，导致一直超时。后来在路由器上调整了 DNS 转发策略才解决。
3.6 各方案适用场景对比
| 方案 | 改动成本 | 是否长期有效 | 适用场景 |
|---|---|---|---|
| 公共 DNS | 低 | 是 | 绝大多数家庭和办公网络 |
| IPv6 优先级调整 | 中 | 是 | 双栈配置异常的环境 |
| hosts 绑定 | 低 | 应急 | 临时救命 |
| 离线导入 | 高 | 是 | 完全无外网环境 |
| 网络层面排查 | 中 | 是 | 企业内网或受管控网络 |
4. 模型拉到本地之后：验证、换盘存储与接口调用
4.1 拉取成功的验证标准
重新执行ollama pull qwen，如果进度条能正常走到 100%，说明清单获取和权重下载都已通过。接下来用ollama list确认模型清单里出现了 qwen，再用ollama run qwen实际跑一条对话，确保不只是下载成功，推理也能正常工作。首次加载需要读磁盘、初始化显存，会比平常慢，不是故障，耐心等几秒即可。
4.2 顺手解决"模型占满 C 盘"的问题
模型随便就是几个 GB，默认放在 C 盘用户目录很容易把系统盘塞满。设置环境变量OLLAMA_MODELS可以把模型目录迁移到其他盘。Windows 下先打开"系统属性"→"环境变量"，新建一个用户变量：
OLLAMA_MODELS=D:\ollama然后完全退出 Ollama，包括托盘图标，再重新启动。已经存在旧位置的模型不会再自动迁移，建议先把旧目录里的内容复制到新目录再启动，这样ollama list还能看到原来的模型，不需要重新 pull。Linux 下同样配置系统级环境变量，然后重启 ollama 服务即可。
4.3 模型就绪后的接口调用方式
如果你打算把本地 ollama 模型集成到自己的项目里，拉完模型后最常见的是通过 HTTP 接口调用。ollama 默认监听 11434 端口，也提供了 OpenAI 兼容的接口，可以用 curl 直接发起对话请求：
curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"qwen","messages":[{"role":"user","content":"你好"}]}'很多人在这一步会搭配 FastAPI 写一层业务封装，或者接入 Dify 这类工具作为模型提供商。这样做的好处是本地模型只暴露给内部服务，数据不用出内网。不过这些都是拉完模型之后的事，当前阶段先把下载问题解决掉才是重点。
5. 从这次排错延伸出去：一套通用的 DNS 故障排查习惯
5.1 同样会中招的还有 docker pull / pip install / git clone
这次遇到的问题本质是 DNS 解析超时，它不只影响 ollama。docker pull 镜像、pip install 安装包、git clone 仓库，都会在第一步做域名解析。你可以把这些工具想象成同一个小区里的住户，DNS 就相当于小区的门牌查询服务，只要这个服务有问题，不管谁要出小区都会卡在大门口。
应对思路完全一样：先确认系统 DNS 是否可用，再考虑是否配置了公共 DNS，最后检查是不是走了本地缓存或 hosts 拦截。很多时候，"某个软件下载慢"这个问题，其实是 DNS 解析缓慢而不是带宽问题。用 curl 观察解析耗时会有直观感受：
curl -o /dev/null -s -w "DNS解析耗时:%{time_namelookup}s\n" https://registry.ollama.ai如果 time_namelookup 经常超过 1 秒甚至直接失败，那问题基本就在 DNS。用这条命令做验证，比反复执行ollama pull碰运气高效得多。
5.2 我建议的排错顺序
结合这次踩坑，我把自己的排查顺序固定成了这样：
- 先 ping 公网 IP 确认链路可用；
- 再 ping 域名确认是否触发 DNS 解析问题；
- 用 nslookup 指定公共 DNS 做交叉验证；
- 检查 IPv6 地址和 hosts 文件是否有干扰；
- 最后才考虑路由器、防火墙等网络层拦截。
按这个顺序走一遍，基本能在五分钟内定位到根因。另外一个小技巧：遇到网络层面的问题，不要连续快速重试。频繁重试会让本地网络设备和 DNS 服务器来不及恢复，反而更容易触发超时。单次请求设置合理的等待时间，隔几十秒再试一次，成功率往往更高。这次问题改成公共 DNS 后，我第一次 pull 就成功，后面拉其他模型也一直很稳定。
