Ollama 拉模型卡在 pulling manifest？2026 年用 Clash 分流官方仓库与镜像源实测一路走下来

现象：进度条停在 pulling manifest，不一定是「模型坏了」 内在逻辑与实践

本地跑 Ollama 的人越来越多：写完 ollama pull llama3.2 一类命令，终端或桌面客户端日志里司空见惯长时间停在 pulling manifest、或在列出 manifest 之后的某一瞬间不再前进。

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 分流实测——那里的域名与下文不要混用，思路都是「按日志补后缀」。

很多人会先怀疑节点「太慢」、磁盘太慢，甚至反复删除模型目录重装——但真正司空见惯的技术由来，更像你在 npm install 或 docker pull 里见过的那一类：元数据请求与大体积分层下载并不是同一个主机名、也不一定命中你在 Clash 里随手配的同一条策略组。

链路拆解：manifest、config、blob 与 Docker Hub 的记忆钩子 技术拆解

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

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

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

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

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

环境与出站：桌面应用、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 段落里「偷懒」。

节点拿定：拉模型不是刷耗时测试榜 结构解析

和 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 与日志里的后续后缀并进同一策略组，再为国内镜像单独保留直连在前级，整条链路就会从「玄学等待」还原成可观测、可迭代的分流表。

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

若你希望换一款经得起折腾的桌面内核客户端统一管理规则与节点，可从本站 下载页 获取适合你系统的安装包，装好后再按上文顺序做一次最小模型的冷拉验证——按常规片刻功夫内就能确认 manifest 与 blob 是否已经齐步走同一出口。→ 立即免费下载 Clash，开启流畅上网新实际感受

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