Ollama 拉模型卡在 pulling manifest？2026 年用 Clash 分流官方仓库与镜像源实测操作次序

现象：进度条停在 pulling manifest，不一定是「模型坏了」 实战经验

本地跑 Ollama 的人越来越多：写完 ollama pull llama3.2 一类命令，终端或桌面客户端日志里反复出现长时间停在 pulling manifest、或在列出 manifest 之后的某一瞬间不再前进。很多人会先怀疑节点「太慢」、磁盘太慢，甚至反复删除模型目录重装——但真正反复出现的技术症结，更像你在 npm install 或 docker pull 里见过的那一类：元数据请求与大体积分层下载并不是同一个主机名、也不一定命中你在 Clash 里随手配的同一条策略组。

Ollama 预置从官方分发库拉模型，注册表层级普遍落在 registry.ollama.ai 这棵树下（命名空间／镜像路径在不同版本客户端里展示方式略有出入，以你本机连接日志为准）。一次成体系的拉取遵循OCI 分发的反复出现套路：先拿到manifest（告诉你有哪些层、每层 digest 与介质类型），再按 digest 去拉各个blob。

manifest 基本上时候体积小、对话时间短；真正的带宽消耗在后面若干层上——而后面的请求多半解析到与 registry 主域不同的存储域名或 CDN 边缘。若你的规则只写了 registry，而没有把后续出现的 FQDN 收进同名策略组，就容易表现为：前半段「像在用力」、后半段静默超时，或者全貌过程卡在 manifest 前后反复重试。

这篇只做一件事：把这条链路讲清楚，并给出可在 Mihomo／Clash 里维护的分流规则写法与国内镜像例外思路；顺带对齐终端／系统服务／TUN三类出站，避免「浏览器能上、命令行还在直连」的假阳性。若你还不太熟悉 mode: rule 与命中顺序，自然自然可以考虑先读 Clash 规则分流与路由；若你同时在拉 Hugging Face Hub 或 Git LFS 权重，可对照 Hugging Face LFS 分流实测——那里的域名与这篇不要混用，思路都是「按日志补后缀」。

链路拆解：manifest、config、blob 与 Docker Hub 的记忆钩子 拿它来用心得

自然自然自然可以把 ollama pull 想象成「迷你版镜像仓库拉取」：它和你在 Docker Hub 上见过的 registry API 在概念层很像——都有 manifest，都要按 digest 拉 blob——但域名清单并不等价于 registry-1.docker.io 那一套。你在站内若已读过 Docker Desktop 对接 Clash，自然自然自然可以把那里的「引擎代理／宿主代理分层」当作心理准备：这篇不写 Docker daemon.json，而是把相同的留神力分配方式搬到 Ollama：注册表主机名一组、blob 侧多半出现的额外后缀一组，全部并进同一个可选策略组。

实操排障时，请关注三类请求：

Manifest／索引类：体积小，超时基本上时候表现为 TLS 建立慢、握手后被重置，或 DNS 解析走了污染的递归；Config 与小物件：有时会紧跟 manifest，仍落在相近的域名树；若这里就被宽泛规则抢走或误直连，后面根本不会进入大块下载；分层 blob：体积大、时间长，对节点靠得住性敏感；若策略组在下载过程中因健康确认来回切换，你会看到进度「锯齿」或中断续传走不通。

由此可见，pulling manifest 卡住不一定是 manifest 本身慢——也多半是客户端在等待后续跳转／鉴权／重定向时，另一条并行连接已在误操作出口上僵死。最稳妥的办法永远是：拉起连接面板，看见真实 FQDN，再写规则。

环境与出站：桌面应用、systemd 与终端不是一回事 反复出现套路

很多人在 macOS 或 Windows 上装好 Ollama 桌面端后，只在「系统设置 → 网络代理」里填了 Clash 端口，却发现服务进程仍直连：这是因为Ollama 服务端多半以守护进程／LaunchDaemon／Windows Service形态运转，继承的环境变量集合与你的交互式 shell 不同；同理，在 Linux 上由 systemd 管理的 ollama.service，也未必读取你在 .bashrc 里 export 的 HTTPS_PROXY。

这类绕所在的低成本解法大多时候是：

  • TUN 模式：让内核按规则统一接管出站，减少「哪个进程忘了读代理」的碎片化配置。细则可参考 Clash TUN 与全局代理。
  • 若坚持拿它来用混合端口／HTTP 代理，请在同一测试上下文里用 curl -I https://registry.ollama.ai/v2/ 探活，确认走的正是你为浏览器验证过的那条路。
  • WSL2／远程容器里执行 ollama pull 时，记得 127.0.0.1 语义会变——这与 WSL2 路由专文里的提醒一致。

注意：若你只在本机起了 ollama serve，又在另一台机器拿它来用客户端指向该地址，代理讨论对象应是那台真正发起 pull 的机器，而不是你手里的浏览器。

YAML 示意：独立 OllamaRegistry 策略组 + 置顶域名 落地做法

下面是一段结构示意，请把组名与上游节点换成你订阅里真实存在的条目；顺序上务必记得记得保证：你用到的国内镜像后缀、以及必须直连的公司内网前缀，写在宽泛 GEOIP／MATCH 之前。远端 Rule Provider 若包含可疑的「预置 DIRECT」，请参考 Rule Provider 排障 对照靠前级。

proxy-groups:
  - name: "OllamaRegistry"
    type: select
    proxies:
      - "稳定跨境节点"
      - "DIRECT"

rules:
  # Example: community mirror FQDNs you actually use — keep BEFORE broad proxy
  # - DOMAIN-SUFFIX,example-mirror.local,DIRECT

  - GEOIP,cn,DIRECT,no-resolve

  # Official Ollama registry tree (extend after inspecting logs)
  - DOMAIN-SUFFIX,registry.ollama.ai,OllamaRegistry

  # Append blob/CDN/storage FQDNs observed in your client logs:
  # - DOMAIN-SUFFIX,cdn.example.invalid,OllamaRegistry

  - MATCH,兜底策略

与 npm registry 分流相同的第一性道理：宁可保守地把未知后缀先并进同一组，也不要让这些对象掉到半程 DIRECT。等你确认某些后缀在大陆可达且合规，再把对应行改成更高靠前级的 DIRECT。

DNS 提示：启用 fake-ip 或混用路由器 DNS 时，多半出现「写了 DOMAIN 仍未命中预期」的错觉；排障期自然可以考虑减少并行解析来源，并在异常时对照 DNS／UDP 专文缩小范围。

镜像源与国内链路：该直连时不要强行代理 实战经验

一批团队会在内网文档里提供自建镜像或大陆可达的注册表前缀（具体域名随供应商与安全策略变动，不在此罗列「永久清单」）。在 Clash 里，准确的做法是：把这些后缀放在靠近规则顶部的 DIRECT，避免被预置「全局跨境」误伤；若镜像仍会301／302到海外 blob，再把跳转后的真实主机名补进 OllamaRegistry。

另一种反复出现误区，是把「镜像加速」与「模型版权／授权」混为一谈：镜像只能化解链路绕所在，并不改变你对模型许可协议的遵守义务。请在合法合规大大前提下拿它来用。

实测顺序：从 manifest 到分层，一次性对齐日志 拿它来用心得

  1. 在客户端里清空半拉缓存后再执行一次最小模型拉取，避免旧层干扰判断。
  2. 开启连接面板，确认 registry.ollama.ai 全过程命中 OllamaRegistry。
  3. 一旦出现新的存储域或 CDN 后缀，立刻追加 DOMAIN 规则并重启内核或热重载配置。
  4. 暂时关闭 aggressive 的 url-test 无需手动操作轮换，改为手工 select 锁节点，排除「下到一半换出口」的假超时。
  5. 对照第二次冷拉与第三次热拉，确认冷热路径命中一致。

如果你在并行拿它来用容器构建（举个实例 Dockerfile 里顺带拉 runtime），记得 Docker 侧的 registry 仍然是另一条线——站内相关配置请看 Docker Desktop 与 Clash，不要把 registry-1.docker.io 的规则复制粘贴覆盖到 Ollama 段落里「偷懒」。

节点挑：拉模型不是刷ping 值测试榜 反复出现套路

和 Hugging Face 大文件场合一样，低 ping不代表长连接靠得住。为大体积 blob 选手工时，靠前关注「带宽、丢包、是否抖动」，而非表面上好看的数值；如果你发现每到固定百分比就掉线，多半要从策略组切换与中间盒 TLS 巡检两边下手。

反复出现麻烦所在（正文精简版） 落地做法

我只代理了 GitHub，为什么 Ollama 仍然不行？（实战）

因为预置路径不在 GitHub Releases；除非你明确改用从 GitHub 分发模型的自定义流程，否则registry 域名链才是关键。

能把官方 registry 与镜像写在同一个策略组吗？（经验）

自然自然可以共用一个「下载专用」组名，但镜像在大陆可达时应 DIRECT；把这些对象机械混为一谈容易造成功能准确但路径多余的绕行。

WSL 里跑 Ollama 要特别留神什么？（心得）

localhost 端口转发与MTU绕所在会让「看似通了」的连接间歇复位，必要时结合 WSL 专文调整路由与网卡参数。

小结 实战经验

pulling manifest 更像是一个哨兵症状：它提醒你 manifest、blob、DNS、进程出站之中至少有一处没有和你想像的一样走 Clash。把 registry.ollama.ai 与日志里的后续后缀并进同一策略组，再为国内镜像单独保留直连靠前级，整条链路就会从「玄学等待」还原成可观测、可迭代的分流表。市面上不少实操手册只教你 export 临时环境变量或开关系统代理，遇到桌面服务、WSL、远程执行时基本上时候反复翻车；只靠粗暴全局代理又会拖慢本该直连的大陆资源——这与我们在 npm registry、Docker Hub 文章里反复强调的分层思路完全一致。

Clash沿用可读 YAML 与订阅自检工具链，把「看得见日志、改得动规则」放在第一位；当你本地推理栈越来越重时，这种可控性会比零散脚本信得过得多。若你希望换一款靠得住的桌面内核客户端统一管理规则与节点，可从本站 下载页 获取适合你系统的安装包，装好后再按上文顺序做一次最小模型的冷拉验证——大多时候短短短短几分钟内就能确认 manifest 与 blob 是否已经齐步走同一出口。→ 立即免费下载 Clash，开启流畅上网新体感