為什麼 Ollama 拉 Hugging Face 特別容易「主站通了，下載卻掛掉」？
許多人在本機部署本機大模型時，會用 Ollama 從 Hugging Face（或相容 registry）拉取權重檔。表面上這只是「下載一個很大的檔案」，但實務連線往往會拆成多段：網頁／API仍在 huggingface.co 一側，真正的大檔案卻可能經由LFS、物件儲存或 CDN 主機名送出；有些流程還會夾雜重新導向、分段校驗與 Range 請求。當你把 Clash 規則寫得過於粗略時，常見症狀就是：網頁可開、token 正常，但 ollama pull 卡在握手、停在某個百分比，或直接報逾時。這不一定是節點本身壞掉，而是分流沒有跟著實際命中的主機集合一起走。
另一個容易被忽略的維度是誰在發起連線：瀏覽器走的是系統代理；終端機裡的 Ollama 未必自動繼承同一設定。你可能花了時間調 YAML，卻發現連線根本沒進 Clash，因而誤判為「規則無效」。本文會先拆開 HF／CDN／容器 registry 三種流量桶，再把它們對應到 Clash 的策略組與規則順序；並建議與本站Docker 映像倉庫分流、GitHub Raw／規則集更新這類開發者向主題並讀：前者談容器 pull 的 daemon 邊界，後者談規則集 URL 與 GitHub 路徑；本篇則聚焦HF 生態的多主機名下載與 Ollama CLI。
先把流量分桶：主站、LFS／CDN、容器與認證
在調規則前，建議把現象分類，避免把「上游限速」誤判成「規則沒寫好」。第一類是入口網頁與 REST／GraphQL API：典型主機名落在 huggingface.co 與短鏈 hf.co 之下，症狀多半是頁面載入、模型卡片或搜尋異常。第二類是大型檔案與 LFS：實際傳輸常落到帶有 cdn、lfs、雲廠商儲存後綴或其他別名的主機名；這類連線對頻寬、RTT 與長連線穩定度特別敏感，最容易出現「進度條不動」或「重試耗盡」。第三類是容器映像：部分發行流程會涉及 ghcr.io 或其他 registry；這與 HF 網頁流量不一定同一條出口策略，硬塞在同一組自動選速，常常會在大檔案中途換節點而放大失敗率。第四類是本機開發環境邊界：WSL2、遠端 SSH、或 systemd 服務裡跑的 Ollama，與桌面 Clash 之間隔著一層網路命名空間時，「系統代理開了」也不代表 CLI 真的經過同一個出入站。
分桶之後，你在 Clash 連線預覽裡會更容易對照：若某個 CDN 主機名意料之外地顯示直連或落入錯誤的策略組，優先處理規則順序與網域覆蓋；若連線根本沒出現在列表裡，就要回到TUN、系統代理或環境變數那一層排查。
分流套路：為 HF／下載流量開獨立策略組
實務上最穩的做法，是在 proxy-groups 新增一個專用條目（例如 HF_DOWNLOAD），類型優先用 select，讓你能把出口手動鎖定在少數經過實測、對大檔案友善的節點上。模型下載屬於典型的大檔案、長連線、可重試工作負載，對「自動測速在工作進行中頻繁換出口」特別敏感：有些協定在換線後需要重新協商範圍請求，使用者體感就是進度條來回跳動或直接失敗。
接著在 rules 區段裡，為 HF 相關網域加上明確且靠前的規則，把它們指向上面的策略組。你可以使用 DOMAIN-SUFFIX、DOMAIN-KEYWORD（謹慎，避免過寬），或把規則集裡的開發者／雲服務類別合併進來。重點永遠是：讓 HF／CDN 規則在過寬的 GEOIP、國內直連或最終 MATCH 前先命中。若你對 proxy-groups 與規則優先級仍不熟，可先讀Clash YAML 配置深度解析，再回到本文把「HF 下載」視為獨立管線維護。
網域層：不要只寫一條 huggingface.co
實務上，一次完整的拉取往往會同時看到多種主機名：huggingface.co／hf.co 側完成索引與授權相關流程，而真正的數 GB 資料可能經由不同的 CDN 或儲存端點輸出。這正是許多人困惑的來源：你把主站送去海外節點，但 CDN 仍命中直連或預設組，結果跨境鏈路品質不足時就會在資料面爆炸。
建議你在測試環境做一次可重現的拉取，打開 Clash 連線列表逐條對照：凡是反覆出現、且與下載進度同步刷新的主機名，都應納入同一個「HF 下載」策略視圖裡統一管理。若你使用第三方規則集，請確認其中策略組名稱與你的設定檔一致，並留意規則集是否把「開發者站」與「任意 HTTPS」混在一起，導致你想細分的 CDN 流量無法獨立調整。
ghcr.io 與模型資產：要不要跟 HF 同一桶？
在部分教學或發行流程中，會出現需要從 GitHub Container Registry（ghcr.io）取得映像或工件的情境。它與 Hugging Face 網頁／CDN 並無必然的同一出口最佳解：有些網路環境對 Azure CDN、對特定區域的 ghcr 前綴表現差異很大。若你把 ghcr 與 HF 硬綁在同一個自動組，常會遇到「其中一邊永遠慢」的副作用。
較穩的作法是為 ghcr.io 另建策略組，或在規則裡先匹配 ghcr，再匹配 HF 後綴；並避免讓這類大流量落入會頻繁切換出口的 url-test／fallback，除非你已確認節點池對 Range 下載相容。若你也在本機玩容器堆疊，可與Docker registry 分流一文對照閱讀，理解daemon 是否接入代理與 Clash 規則之間的邊界。
Ollama CLI、系統代理與環境變數
即使你 YAML 寫得正確，若 Ollama 行程沒有把 TLS 流量送到 Clash，規則仍不會生效。桌面環境下常見路徑包括：系統代理指向本機 mixed／HTTP 埠、或開啟 TUN／虛擬網卡讓進程無感穿過 Clash。終端機場景則可能要補 HTTPS_PROXY／HTTP_PROXY，並用 NO_PROXY 放行走區網與本機服務，避免副作用。
請不要把「設定 HF_TOKEN」與「修正路由」混成一題：token處理的是身份與權限；逾時與斷流多半是連線路徑與CDN品質問題。當然，缺乏token時伺服器可能直接拒絕或限速，症狀有時也像逾時；因此仍建議先確認錯誤碼與日誌語意，再決定要先補憑證還是先調分流。
若你在 Windows 上透過 WSL 跑 Ollama，請留意Windows 宿主與 Linux 子系統各自的預設閘道與 DNS；這類跨環境題與本站WSL2 Ubuntu 與 Windows mixed-port的思路相近：先確保「流量真的進到同一個 Clash 入口」，再談規則細節。
DNS、Fake-IP 與規則一致性
本站文件頁的 DNS 與 Fake-IP 說明已解釋為何建議讓解析與連線決策對齊。對 HF 下載場景，你需要額外確認：終端機／服務使用的 DNS 與 Clash DNS 模組是否一致；若出現「解析結果與策略不匹配」的分裂情況，會表現為間歇性失敗或 TLS SNI 看起來怪異。
若你啟用 Fake-IP，某些驗證嚴格的 CDN 路徑可能對特定主機名解析形態較敏感；這時需要在 fake-ip-filter 放行走真實解析的主機名集合，並重新對照連線日誌。另請留意 TUN 與其他 VPN／過濾軟體的路由競合；這與Windows TUN 排查裡提到的「多代理疊加」屬於同一類風險——長下載會放大任何路由抖動。
設定檔示意：獨立策略組與靠前規則（概念範例）
下列為概念示意，策略組名稱、節點清單與網域請以你的訂閱與連線紀錄為準；合併進正式設定檔前請先備份。
proxy-groups:
- name: HF_DOWNLOAD
type: select
proxies:
- YOUR_STABLE_NODE
- DIRECT
- name: GHCR_PROXY
type: select
proxies:
- YOUR_STABLE_NODE
- DIRECT
rules:
# Optional: container registry split (observe logs)
- DOMAIN-SUFFIX,ghcr.io,GHCR_PROXY
# Hugging Face site + short domain
- DOMAIN-SUFFIX,huggingface.co,HF_DOWNLOAD
- DOMAIN-SUFFIX,hf.co,HF_DOWNLOAD
# Add CDN/LFS hosts seen in your connection logs:
# - DOMAIN-SUFFIX,cdn-lfs.huggingface.co,HF_DOWNLOAD
# Keep LAN / RFC1918 DIRECT rules above noisy GEOIP if needed
實務上你通常還會在更前面加入企業內網、區網或細部 DIRECT 規則，以避免誤送代理；重點仍是順序可讀、註解完整，讓數月後的你仍能回憶「為何這條要壓在這個位置」。
驗證流程：用一次可重現的 ollama pull 驗收
完成調整後，建議按固定順序驗證：第一步，確認拉取過程中所有高頻主機名都命中 HF_DOWNLOAD（或你的命名），而不是落入預設組或意料之外的直連。第二步，固定節點後重試同一模型三次，觀察是否仍會在固定百分比失敗；若有固定拐點，通常還有子網域未覆蓋。第三步，若同機瀏覽器快、終端機慢，優先檢查終端機是否真的經過 Clash；必要時短期設定 HTTPS_PROXY 做對照實驗。第四步，檢查自動規則集更新後是否改動了策略組名稱或優先級，避免「昨天可用、今天規則改名」。
這套方法能把「HF 拉模型總逾時」從玄學敘事，收斂成可對照的連線清單與規則順序問題；也能避免你一開始就把鍋甩給單一節點供應商，忽略網域分裂與 CLI 邊界。
常見問題（補充）
我已經把 huggingface.co 配好規則，為什麼還會逾時？
多半是因為大檔案實際來源主機名不在這條規則涵蓋範圍。請以連線紀錄為準補齊 CDN／LFS 相關網域，並確認規則優先級夠靠前。
要不要先設定 HF_TOKEN？
公開模型通常不必；若資源需要身份，伺服器會回錯誤訊息而非無限握手。若你確定權限無虞卻仍逾時，請優先查 CDN 分流與 CLI 代理。
ghcr 可以和 HF 用同一個自動組嗎？
可以但不建議作為長期預設：兩類流量的最佳節點集合不一定一致，自動組也可能在下載中途換線。至少在排查階段改用 select 固定出口對照。
合規與使用條款提醒
透過代理存取 Hugging Face、GitHub 或其他 registry 時，仍須遵守各平台服務條款、授權與所在地法規；部分模型與資料集亦有使用限制與出口規範。本文僅從網路工程角度說明 Clash 規則與流量路徑協同思路，請讀者自行確認是否允許以代理方式下載目標資源。
結語：把「拉模型」當成獨立產線，而不是多寫一條寬鬆規則
Ollama 與 Hugging Face 的組合在本機 AI 熱潮裡依然高頻，但「HF 主站能開」並不保證「CDN 下載在同一條健康路由上」。透過獨立的 HF／CDN 策略組、靠前的網域規則，以及對終端機是否真的經過 Clash 的驗證，你能把逾時、斷流與進度卡住收斂成可操作的工程問題；同時避免全域代理或過度寬鬆的 MATCH 讓其他業務流量一起承擔副作用。相比把節點列表換來換去卻不對照主機名分裂，建立一套你能解釋、能對照的下載管線，長期維護會省力得多。
部分工具仰賴僵化的全域開關或單一規則模板，遇到多 CDN、多 registry 的開發場景時，往往只能「整台電腦一起換線」，既難排查也容易拖慢無關流量。Clash 的分流模型把決策拆回規則順序與策略組，讓你能精準對準 HF、CDN、ghcr 等不同目的地分別選路，並用連線預覽自我驗證；這正是處理模型下載逾時這類問題時最需要的可控性。若你尚未安裝合適用戶端，可先從本站用戶端下載頁取得對應平台版本，再依本文思路將 Hugging Face 相關主機名納入獨立策略組並撰寫對應規則。