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

现象：进度条停在 pulling manifest，不一定是「模型坏了」 要点速览

本篇正文只做一件事：把这条链路讲清楚，并给出可在 Mihomo／Clash 里维护的分流规则写法与国内镜像例外思路；顺带对齐终端／系统服务／TUN三类出站，避免「浏览器能上、命令行还在直连」的假阳性。

本地跑 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 前后反复重试。

若你还不太熟悉 mode: rule 与命中顺序，不妨先读 Clash 规则分流与路由；若你同时在拉 Hugging Face Hub 或 Git LFS 权重，可对照 Hugging Face LFS 分流实测——那里的域名与本篇正文不要混用，思路都是「按日志补后缀」。

链路拆解：manifest、config、blob 与 Docker Hub 的记忆钩子 关键信息

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

得以把 ollama pull 想象成「迷你版镜像仓库拉取」：它和你在 Docker Hub 上见过的 registry API 在概念层很像——都有 manifest，都要按 digest 拉 blob——但域名清单并不等价于 registry-1.docker.io 那一套。

这里要多说一句：你在站内若已读过 Docker Desktop 对接 Clash，得以把那里的「引擎代理／宿主代理分层」当作心理准备：本篇正文不写 Docker daemon.json，而是把相同的当心力分配方式搬到 Ollama：注册表主机名一组、blob 侧或许出现的额外后缀一组，全部并进同一个可选策略组。

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

于是，pulling manifest 卡住不一定是 manifest 本身慢——也或许是客户端在等待后续跳转／鉴权／重定向时，另一条并行连接已在疏漏出口上僵死。最稳妥的办法永远是：启用连接面板，看见真实 FQDN，再写规则。

环境与出站：桌面应用、systemd 与终端不是一回事 关键点梳理

同理，在 Linux 上由 systemd 管理的 ollama.service，也未必读取你在 .bashrc 里 export 的 HTTPS_PROXY。

换个说法：很多人在 macOS 或 Windows 上装好 Ollama 桌面端后，只在「系统设置 → 网络代理」里填了 Clash 端口，却发现服务进程仍直连：这是因为Ollama 服务端或许以守护进程／LaunchDaemon／Windows Service形态持续持续运行，继承的环境变量集合与你的交互式 shell 不同；

这类困扰的低成本解法多数现状下是：

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

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

YAML 示意：独立 OllamaRegistry 策略组 + 置顶域名 完备说明

远端 Rule Provider 若包含可疑的「出厂 DIRECT」，请参考 Rule Provider 排障 对照第一顺位级。

下面是一段结构示意，请把组名与上游节点换成你订阅里真实存在的条目；顺序上切记保证：你用到的国内镜像后缀、以及必须直连的公司内网前缀，写在宽泛 GEOIP／MATCH 之前。

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 段落里「偷懒」。

节点选定：拉模型不是刷响应时间测试榜 关键点梳理

和 Hugging Face 大文件采用使用场景一样，低 ping不代表长连接平稳。为大体积 blob 选手工时，第一顺位关注「带宽、丢包、是否抖动」，而非表面上好看的数值；

如果你发现每到固定百分比就掉线，多半要从策略组切换与中间盒 TLS 巡检两边下手。

普遍困扰（正文精简版） 完备说明

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

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

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

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

WSL 里跑 Ollama 要特别当心什么？（清单）

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

小结 要点速览

Clash沿用可读 YAML 与订阅自检工具链，把「看得见日志、改得动规则」放在第一位；当你本地推理栈越来越重时，这种可控性会比零散脚本可信得多。

pulling manifest 更像是一个哨兵症状：它提醒你 manifest、blob、DNS、进程出站之中至少有一处没有和你想像的一样走 Clash。把 registry.ollama.ai 与日志里的后续后缀并进同一策略组，再为国内镜像单独保留直连第一顺位级，整条链路就会从「玄学等待」还原成可观测、可迭代的分流表。

市面上不少指南只教你 export 临时环境变量或开关系统代理，遇到桌面服务、WSL、远程执行时经常反复翻车；只靠粗暴全局代理又会拖慢本该直连的大陆资源——这与我们在 npm registry、Docker Hub 文章里反复强调的分层思路完全一致。

关键点是：若你希望换一款平稳的桌面内核客户端统一管理规则与节点，可从本站 下载页 获取适合你系统的安装包，装好后再按上文顺序做一次最小模型的冷拉验证——多数现状下一点时间内就能确认 manifest 与 blob 是否已经齐步走同一出口。→ 立即免费下载 Clash，开启流畅上网新上手感觉