為什麼「拉映像」特別容易跟代理打架？

在雲原生、本機開發與 CI 流水線裡，Docker 與 containerd 幾乎無所不在；相對地，「docker pull 很慢」「連不上 registry」「TLS handshake timeout」也長期是熱門搜尋詞。這類問題表面上是網路品質，實務上卻常與流量怎麼走代理有關：你把 Clash 開成全域或寬鬆規則時，映像倉庫（registry）相關連線可能同時混進一般上網、串流或辦公軟體的流量決策裡；一旦命中錯誤的策略組、或被迫繞路到你不需要的節點，就會出現下載進度卡住、重試耗盡、或 mirror 反而更慢的症狀。

另一個常見痛點是「內外網混在一起」：企業內網私有倉庫、測試環境的 registry.example.local、或公司 VPN 內的服務，理論上應該直連；但若規則過於粗糙，這些連線也被送去海外節點，結果不是逾時就是 DNS／路由完全對不上。本文從 Clash 的分流規則角度，說明如何把「映像倉庫」當成一條獨立管線來維護，並與本站AI 網站獨立分流這類開發者向主題互補：那篇聚焦生成式 AI 的子網域與長連線；本篇則聚焦容器映像、registry 網域與守護行程行為，關鍵詞與落地步驟並不相同。

先把現象分桶：逾時、鏡像與「只有 CI 出事」

在改規則前，建議先把問題分類，避免把「上游 registry 限流」誤判成「規則沒寫好」。第一類是公有雲 registry 連線品質：例如 Docker Hub 或海外廠商託管倉庫，症狀多為握手慢、下載斷續、或特定時間段特別差。第二類是國內／第三方鏡像：你為了加速而改 registry-mirrors，但若鏡像本身調度不佳，或與代理路徑疊加後產生額外延遲，反而比直連官方更慢。第三類是企業內網或私有倉庫：這類主機名往往落在內部 DNS，必須直連；一旦被規則送去代理，最常見的就是「解析看起來對、連線卻永遠等不到」。第四類是守護行程沒吃到系統代理：在 Linux 伺服器或某些 CI Runner 上，Docker daemon 本身未必繼承你桌面版 Clash 的「系統代理」，這時你以為開了代理，實際 pull 仍走預設路由，症狀會與第三類混淆。

分桶後，你在 Clash 連線紀錄裡會更容易對照：若顯示某個 registry 主機名命中了預期的策略組，但下載仍失敗，下一步就偏向節點品質或上游服務狀態；若顯示直連但你預期要走代理，則優先檢查規則順序與守護行程是否真的經過 Clash。

分流思路：為「映像倉庫」單獨開一組策略

實務上最穩的做法，是在 proxy-groups 裡新增一個專用條目，例如命名為 REGISTRY 或 CONTAINER，類型常用 select，讓你能把出口手動鎖定在少數經過實測的節點上。映像拉取屬於大檔案、長連線、可重試的工作負載，對「頻繁切換出口」特別敏感：若自動測速在不同區塊下載之間把節點換來換去，可能出現 checksum 或層級下載不一致的錯誤，或單純讓重試次數暴增。

接著在 rules 區段中，為相關網域加上明確且靠前的規則，把它們指向上面的策略組。你可以使用網域後綴匹配、完整網域匹配，或引用規則集（rule-providers）中已分類的開發者／雲端服務條目。重點是：規則順序必須讓 registry 相關網域在落入泛用 GEOIP 或寬鬆的 MATCH 之前就先命中。若你尚未熟悉 proxy-groups 與 rules 的優先級，可先讀Clash YAML 配置深度解析，再回到本文把「容器映像」視為獨立產線。

網域層：別只記「Docker Hub」一個名字

實際拉映像時，客戶端往往會接觸多個主機名：除了映像倉庫本身，還可能包含認證、重定向、CDN 與廠商各自的 API 端點。不同雲廠商的 registry（例如容器映像服務的網域）也各自不同。本文不提供會隨時間快速變動的硬編碼清單，而是建議你用連線日誌與一次真實 pull對照：在測試環境執行目標映像的拉取，觀察實際命中的主機名，再把缺的網域補進規則。這比從論壇複製一大段過期網域更可靠。

若你使用第三方規則集，請確認其中策略組名稱與你的設定檔一致；也要留意規則集是否把「開發者工具」與「一般網站」混在同一桶，導致你想細分的 registry 流量無法獨立調整。當你需要同時覆蓋多個公有 registry 時，可優先使用後綴匹配與規則集維護，避免在設定檔裡無限堆疊單行規則卻難以版本化。

國內鏡像、內網倉庫與「該不該走節點」

許多團隊會在守護行程設定檔裡加入 registry-mirrors 以改善 Docker Hub 存取體驗。從 Clash 的角度，你要問的不是「mirror 好不好」，而是這些 mirror 網域在你的網路環境下，直連比較快還是經過特定節點比較快。若 mirror 位於同一地理區域且頻寬充足，強制走海外節點反而可能增加 RTT；若 mirror 仍需跨境訪問上游，則可能適合與公有 registry 同一策略組處理。關鍵仍是：把 mirror 網域明確寫進規則，不要讓它們默默落入你為「一般瀏覽」準備的自動選擇策略。

對企業內網或實驗室環境，請務必為私有倉庫主機名、內部 DNS 後綴或 RFC1918 目標加上直連（DIRECT）規則，並放在靠前位置。這能避免 TUN 或全域模式把內網流量誤送代理，也能降低與公司 VPN、零信任客戶端之間的路由衝突。若你在 Linux 上同時使用 systemd 與容器堆疊，可一併參考本站Linux 上部署 Clash Meta 與 systemd一文，理解服務重啟與路由疊加時的常見變因。

守護行程、開發者代理與 Clash 的邊界

桌面環境（例如 Docker Desktop）常見做法是設定「開發者代理」或讓系統流量經過 Clash；但在 Linux 伺服器或無介面 Runner 上，dockerd 可能完全不理會桌面客戶端的系統代理。此時你有幾條典型路徑：在守護行程環境變數層設定 HTTP_PROXY／HTTPS_PROXY（需符合你的發行版與服務管理方式）、讓主機層路由以 TUN 模式統一走 Clash、或在企業網路邊界做透明轉發。這些做法與「只在 YAML 裡加規則」是不同層次：Clash 規則決定的是「一旦流量進入 Clash，要如何分流」；若流量根本沒進來，規則再漂亮也不會生效。

因此，建議你把設定拆成兩步驟驗證：先確認 pull 時相關 TCP 連線是否出現在 Clash 連線列表或日誌中；若完全沒有，先解決守護行程／路由／TUN 的接入問題，再回頭微調 registry 規則。這能避免你在 YAML 裡反覆試錯，卻始終改到錯的層級。

DNS、TUN 與規則一致性

本站文件頁的 DNS 與 Fake-IP 說明已從機制面解釋為何建議讓解析與連線決策走同一套邏輯。對容器映像場景，你同樣需要確認：主機名解析結果與後續連線是否仍由同一套規則接管。若系統或容器內仍向不相干的 DNS 查詢，可能出現「看起來連對主機、實際策略卻不一致」的分裂情況。若你使用 Fake-IP，也要留意是否有特定主機名需要列入 fake-ip-filter 才能與某些 TLS 或憑證驗證行為相容；這類問題在映像倉庫與企業內部 CA 並存時較常出現。

啟用 TUN／虛擬網卡模式時，請同步檢查是否與其他 VPN、過濾軟體或公司安全代理競爭路由表；這與本站Windows TUN 排查裡提到的「多代理疊加」是同一類風險。映像拉取屬於長時間佔用頻寬的工作，任何路由抖動都會被放大成「pull 失敗」。

設定檔示意：獨立策略組與靠前規則（概念範例）

下列為概念示意，實際策略組名稱、節點清單與網域請以你的訂閱與環境為準；合併進正式設定檔前請先備份。

proxy-groups:
  - name: REGISTRY
    type: select
    proxies:
      - YOUR_PROXY_NODE
      - DIRECT

rules:
  # Put internal registries first (example patterns)
  - DOMAIN-SUFFIX,corp.local,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  # Public registry traffic
  - DOMAIN-SUFFIX,docker.io,REGISTRY
  - DOMAIN-SUFFIX,docker.com,REGISTRY
  # ...add domains observed in your logs

實務上你通常還會在更前面加入 GEOIP 或細部 DIRECT 規則，以避免內網與區域流量被誤送；重點是維持可讀的順序與註解習慣，讓半年後的你自己仍能看懂「為何這條要放在這裡」。

驗證流程：用一次可重現的 pull 當驗收標準

完成調整後，請用固定順序驗證：第一步，在 Clash 連線預覽中確認目標 registry 主機名命中 REGISTRY（或你命名的策略組），而不是落入直連或其他預設組。第二步，用同一個映像與標籤重複拉取數次，觀察是否仍會在特定層級失敗；若失敗點固定，往往還有子網域或重定向未被覆蓋。第三步，切換到內網私有倉庫測試，確認仍維持直連且延遲符合內網預期。第四步，若你使用規則集自動更新，確認更新後沒有改變策略組名稱或規則優先級。

在 CI 場景，建議把「可重現的映像拉取」納入流水線的健康檢查：同一 Runner 上固定節點與固定 DNS 設定，能顯著降低「昨天成功、今天失敗」的雜訊，也讓 Clash 規則調整更有對照組。

對照表：常見現象與優先處理方向

下列整理方便你快速縮小範圍。

合規與使用條款提醒

透過代理或節點存取映像倉庫時，仍須遵守映像提供者、雲端供應商與你所在地之法規與服務條款；部分 registry 亦可能對匿名拉取、頻寬或 API 呼叫設有限制。本文僅從網路工程角度說明 Clash 規則與流量路徑的協同思路，請讀者自行確認相關合約與適用規範。

結語：把映像流量當成獨立產線，而不是多一條 MATCH

Docker 拉映像慢或失敗，往往不是因為你「少勾一個開關」，而是大檔案下載、長連線與多網域重定向對路由一致性特別敏感。透過獨立的映像倉庫策略組、靠前的網域規則，以及對守護行程是否真正接入 Clash 的驗證，你可以把「pull 一直逾時」從玄學問題，收斂成可逐步排除的工程問題；同時避免全域代理讓內網與其他業務流量一起承擔副作用。相比在訂閱裡堆疊模糊關鍵字，建立一套你能解釋、能對照的 registry 管線，長期維護會輕鬆得多。

若你尚未安裝合適的用戶端，可先從本站用戶端下載頁取得對應平台版本，再依本文思路為映像倉庫單獨配置策略組與規則。→ 立即免費下載 Clash，開啟流暢上網新體驗