為什麼終端機會一直停在「pulling manifest」？

多數使用者在本地跑大型語言模型時，第一個挫折往往不是推理速度，而是ollama pull才下到一半、終端機卻像凍結一樣停在某個階段文字，例如pulling manifest或看似已開始卻遲遲沒有下一行進度。這個狀態多半代表用戶端已經嘗試向模型庫取得版本清單／manifest 描述，但該 HTTP(S) 連線在當前網路路徑上無法在合理時間內完成：可能是出口抖動、被寬泛規則誤導到不合適的策略、DNS 回傳與實際連線目的地不一致，或你的行程根本沒有走進本機的 Clash／Mihomo。

與瀏覽器看網頁不同，Ollama 的命令列工具在拉模型時會拆成多個「主機名不一定連續」的步驟：預設上會先對官方模型庫（一般為registry.ollama.ai）取得 manifest，這份 JSON 描述後續需要哪些層（layers）與其雜湊；接著才會依 digest 去抓實際的二進位 blob。若你的分流規則只命中其中一段、或讓其中一段早一步落入過於保守／過於激進的策略，就會出現「看起來卡在清單、其實是清單永遠拿不到；或是清單拿到了，大檔卻永遠下不完」兩種不同表象，但根因常常都是要回到連線紀錄與規則順序一起讀。

合規提示：Clash／Mihomo 為本機路由與轉送工具，不提供公開節點；請在合法合規與組織政策允許的情境下使用代理，並避免將訂閱或內部倉庫位址對外公開。

若你才剛匯入訂閱並開始對照前端顯示名稱，建議先完成 訂閱匯入教學，再回到本文細修規則，避免proxy-groups名稱與訂閱實際節點不相符而整份設定無法載入。

manifest、blob 與「看起來同一個 pull」其實是兩段式流量

要把問題收斂，先把心智模型畫成兩層：metadata 層與payload 層。前者的請求量小，但對延遲與 TLS 連線建立非常敏感；後者資料量大，對吞吐與長連線穩定度敏感。畫面如果長時間停在 pulling manifest，優先懷疑的是你是否能穩定地完成對模型庫 registry 的 HTTPS 握手指向，而不是先換一顆更大的硬碟或更大的模型。

registry：清單與標籤解析發生在哪裡？

在預設命名空間下，ollama pull llama3.2這類指令會對registry.ollama.ai下的/v2/ API 取得manifests資訊。這一步若被錯誤的GEOIP、過舊的RULE-SET、或過寬的MATCH導向不穩節點，終端機就會像你看到的一樣停在清單階段不動；某些網路環境還會在 TLS 層重試，表面上像「沒有錯誤訊息但其實永遠沒進下一階段」。因此撰寫 Clash 規則時，請把「官方模型庫相關網域」視為獨立的一類流量，與一般影音或社群站分流邏輯分開管理。

blob：大檔層與可能的 CDN／物件儲存子網域

manifest 成功回來後，用戶端會開始拉取各層 blob。實務上blob 的 hostname 不一定與 registry 主機名一模一樣：可能仍在同一註冊表後端，也可能因分發架構而落在其他子網域或第三方 CDN。這也是為什麼「只放一條DOMAIN-SUFFIX,ollama.ai」有時仍不夠——你需要的不是關鍵字猜測，而是連線紀錄裡實際出現過什麼域名，再依域名補齊規則。這種拆段思路與 npm registry 與 tarball CDN 分流非常相似：metadata 與 bytes 常常分屬不同主機名，規則不能只顧其中一端。

若你同時會從 Hugging Face Hub 或 Git LFS拉大型權重，本站另文已拆解huggingface.co、cdn-lfs與 IDE／CLI 混合流量；與本篇並列閱讀時，請注意不要混用不相干的第三方規則集，以免把教育網流量誤傷到企業內網或反向。

docker pull 映像與 ollama pull 模型：不是同一條鏈路

許多人在本機用容器跑 Ollama 服務，會先執行docker pull ollama/ollama再於容器內拉模型。這兩步請你在心裡當成兩張票：Docker Hub／映像倉庫的層下載走的是容器映像分發鏈路，常見涉及docker.io以及映像倉庫前後的 CDN；而容器進入執行後，Ollama 服務向模型庫抓取權重的 HTTPS 連線仍可能指向registry.ollama.ai與其後 blob 節點。若只把瀏覽器或 Docker Desktop 的代理設好，但伺服器行程在另一張網卡命名空間或沒有經過 TUN，終端機仍可能出現「容器已啟動，但 exec 進去後 ollama pull 繼續卡住」的錯位現象。

針對 Windows 與 macOS 上 Docker Desktop 與宿主的對齊方式，請交叉閱讀 Docker Desktop 與 Clash 代理：該篇從 HTTP／HTTPS 代理、WSL2 後端到容器內環境變數分層說明；本篇則補上模型庫與 blob 專用規則，兩側一起收斂才算完成閉環。

規則順序為什麼永遠是第一個要檢查的變因？

在mode: Rule下，rules由上而下命中即停止。任何巨大RULE-SET或GEOIP若出現在你想細修的官方庫規則之前，後面補上的DOMAIN-SUFFIX就根本輪不到比對。因此處理 pulling manifest 卡頓時，請先把目標網域規則前置到會提早結束比對的集合之前；整體骨架可對照 國內國外規則分流 一文，理解「置前例外」與「底層兜底 MATCH」如何分工。

若你啟用 TUN 模式，除錯時建議拆兩個問題：第一，終端機行程的封包是否真的進到 Mihomo；第二，進來之後規則顯示命中的策略群組是否與你預期相同。系統 Proxy、TUN、以及 IDE 內嵌終端三套入口若不同步，最常製造「瀏覽器順、命令列卡」的假訊號；此時先看連線紀錄與 DNS 行為，比先換節點更能省時間。

可貼上再依日誌微調的規則骨架

下列片段為教學級示意，請替換OLLAMA_DEV_PROXY內的實際節點名稱，並將整段放置在會攔截 Ollama 上游的大型規則集之前。若日誌顯示 blob 主機是額外子網域，請把該主機名以DOMAIN或DOMAIN-SUFFIX補上，而不要只用過寬的關鍵字規則。

YAMLproxy-groups:
  - name: "OLLAMA_DEV_PROXY"
    type: select
    proxies:
      - "NODE_LOW_LATENCY"
      - DIRECT
  - name: "NODE_LOW_LATENCY"
    type: url-test
    proxies:
      # paste real proxies from subscription
    url: "https://registry.ollama.ai/v2/"
    interval: 300

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  # Ollama upstream (prepend before broad GEOIP / RULE-SET)
  - DOMAIN-SUFFIX,ollama.ai,OLLAMA_DEV_PROXY
  - DOMAIN-SUFFIX,registry.ollama.ai,OLLAMA_DEV_PROXY
  # Docker image pull path (add CDN hostnames seen in logs)
  - DOMAIN-SUFFIX,docker.io,OLLAMA_DEV_PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

粒度提醒：請勿為了省事把DOMAIN-KEYWORD,ollama擴到整個網際網路相關字串；寬鬆關鍵字容易誤傷不相干服務並讓除錯更困難。以日誌實際 hostname為準逐步補規則，是較可審計也更安全的作法。

鏡像、環境變數與 DNS／Fake-IP：另一組會讓「manifest 永遠拉不到」的陷阱

部分環境會在企業文件或社群文章中看到改指向鏡像站或自架庫的教學；若你已把 Ollama 的上游改成本地或區域鏡像，請在分流裡為該鏡像域名前插 DIRECT（或對應企業內網路由），避免它被全域PROXY再繞一圈海外節點，反而比官方路徑更慢。相反地，如果鏡像本身架設在海外且仍不穩，則要把鏡像區域名納入可觀測、可切換的群組並用連線紀錄核對策略命中。

另一個常見地雷是 shell、CI、容器與系統層殘留的HTTPS_PROXY、ALL_PROXY、NO_PROXY互相打架：某些工具會直接讀環境變數而繞過你以為已經啟動的 TUN，或是在NO_PROXY裡排除了特定網域卻導致意外直連到被封鎖的出口。建議除錯時先固定單一路徑（例如只保留本機 Mihomo 混合埠，清理多餘代理變數），再重試一次最小復現的ollama pull。

DNS 方面，若你在使用 Fake-IP，請同步確認解析結果與實際連線目的地是否一致；部分情境下 manifest 與 blob 若對應不同 IP 家族或不同路由策略，會在連線紀錄看起來「同一個程式卻交替成功失敗」。可交叉參考 Verge／Rev 在 Windows 上的 fake-ip 與 redir-host 設定（若你使用相同用戶端），把 DNS 模式與規則層一起對齊。

實測與除錯劇本：建議照這個順序收斂

  1. 最小復現模型：先挑一款中型公開模型，暫停同時間的其他大型下載與 IDE 背景索引，避免並行造成節點測速群組頻繁切換。
  2. 鎖定單一策略對照：在代理群組中用select暫時固定一枚低抖動節點，確認 pulling manifest 是否仍無限重試；若固定後錯誤型態改變，才再把焦點放回自動測速閾值。
  3. 抄實際 hostname 清單：依序記錄 manifest 請求與 blob 請求的策略命中是否一致；若 blob 對到新域名卻落在DIRECT或相反，立刻補規則而不是猜。
  4. 分泳道驗證 Docker 與裸機：若同一台機器同時需要拉映像與拉模型，請分兩次實驗，避免把兩種錯誤混在一起解讀。
  5. 回到公司政策：若組織規定必須經過內部 MITM 或指定出口，請把證書信任鏈與放行名單一并納入，而不是只在 Clash 裡套用節點。

常見問題速答

我已經開全域規則為什麼還卡？因為「全域」並不保證你的終端機子行程真的進入同一個入口；請看連線紀錄裡該行程的策略名稱與域名。若紀錄中出現你未預期的DIRECT，多半仍是規則順序或環境變數在作祟。

Ollama 與 Docker Hub 都要走同一個節點才對嗎？不一定；你可以把它們放在同一個select群組方便手動切換，但是否需要相同節點取決於你的實測。部分情況下映像層與模型庫對延遲與頻寬的敏感度不同，最佳解是日誌導向而不是口耳相傳的萬能節點名單。

能用巨型 RULE-SET 一把取代逐條域名嗎？第三方規則集可以作為起點，但開發者場景常有企業內網與鏡像站例外；請以日誌微調置前規則，而不是關閉思考只依賴更新頻率。

結語

2026 年本地模型與邊緣推理需求持續升溫，ollama pull這種看似簡單的指令，背後卻是registry 清單、blob 下載、容器映像層與各層 DNS／代理環境交織的鏈路。與其只在社群複製單句「換鏡像」或「關掉公司 VPN」，不如先把連線紀錄與規則順序讀清楚：大多數卡在 pulling manifest 的案例，都能在置前域名規則與清理環境變數後顯著改善，而不必犧牲模型版本或專案可重現性。

相較於依賴零散文或一次性腳本，不少工具組難以把終端、容器與 GUI 用戶端的實際命中策略對齊，也更少談論可審計的 YAML；團隊一旦跨 macOS、Windows 與 WSL，問題還會被放大。Clash 官網把規則敘述與 Docker／WSL／TUN／開發者套件等場景放在同一脈絡，讓你能用連線紀錄對照「manifest 與 blob 是否同一策略」「Docker 與 Ollama 是否分泳道驗證」。若你希望把本文流程固化為可重用的設定範本，不妨在合法合規前提下 免費下載 Clash 官網，並搭配 教學文件將規則調整成你可向同事展示與審核的版本。