docker pull 一直停在 Pulling fs layer 是 Clash 規則問題嗎？

不一定是。該訊息後面通常還會接上多個 CDN／blob 連線；若規則把其中一段 Hub 網域走到錯誤出口、或 Fake-IP 與真實路由不一致，就可能表現為長時間無進度。應先看 Engine 日誌與 Clash 連線紀錄是否在同一時間點對得上。

registry mirror（映像加速器）與 HTTP 代理可以一起開嗎？

可以並存，但要分清層次：daemon.json 的 mirror 決定映像 Metadata 與層資料向哪個 Registry 網域請求；HTTP_PROXY 只影響「支援代理」的客戶端。若鏡像網域解析被 DNS 劫持到不一致的路由，仍會拉取失敗。

TLS handshake timeout 最常見的原因是什麼？

常見包含：經過錯誤出口導致握手 round-trip 過長或被重置、企業網路中介設備（middlebox）檢查 HTTPS、MTU／PPPoE 分段問題、以及 SNI 被錯誤規則導向不符預期的節點。可用 openssl s_client 或 curl -v 先做最小重現。

Docker pull Clash 鏡像分流（2026）

1. 先別急著怪節點：docker pull 失敗有哪些「型態」

真實世界裡，docker pull顯示的往往只是一句表面症狀：可能是連線逾時、TLS handshake timeout、unexpected EOF，或被403、429拒於門外。對開發者來說，第一步該做的是把問題映射到鏈路中的位置：是DNS解析本身卡住，還是解析得到 IP 後TCP 連線建立不起來？TCP 通了之後，是否在TLS憑證交換階段停住？若前面都順利，是否換成HTTP 層回錯誤碼？

Clash 分流與mihomo能幫助你的，主要集中在「IP 之後怎麼出去」：同一個網域在不同規則下可能落到直連或代理策略組；若Fake-IP回給應用程式的地址與後續嗅探（Sniffer）還原網域不一致，規則命中也可能反覆錯置，於終端機看起來就像「mirroring 很慢但其實一直在重試」。因此本篇會一再強調：先用最小工具確認是哪一段逾時，再把對應Docker Hub或registry mirror網域放回規則清單裡調整。

企業環境若有HTTPS 檢查或透明閘道，TLS 症狀可能與家用跨境路由完全不同；請在你公司資安政策允許範圍內排查，不要把公開部落格的實測技巧硬搬到受管制網段。

2. Docker Hub 為什麼不是單一網域了事

OCI Registry在協定層看起來只是對著某個 HTTPS 端點做GET /v2/與blob下載；但Docker Hub實際會把你引導到多組前端與發行網域：包含映像索引／manifest與層資料 blob可能來自不同的 CDN 或合作網域。你在規則裡如果只寫了一個字面docker.com或過窄的主機名，極容易留下「某一張子網域仍走錯策略」的洞口。

實務上會一再遇到的後綴包含（關鍵詞示意，實際清單請以當期解析與日誌為準）：docker.io、registry-1.docker.io與auth.docker.io這類registry／OAuth鏈路；另可能有發行／CDN用的主機名出現在連線紀錄裡。鏡像拉取時最常見的痛點，就是manifest 很快但blob 很慢或握手卡住——這通常代表規則或DNS並沒有一致涵蓋整個Hub交付鏈。

也因為這個結構，單純在瀏覽器開得了hub.docker.com，並不保證docker pull會成功：桌面瀏覽器與dockerd走的是不同進程／不同 DNS 設定／也可能不同系統代理。這也是為什麼要用客戶端日誌對齊mihomo連線紀錄，而不是只看瀏覽器能不能開網頁。

3. 跟「容器走主機代理」差在哪裡

站上Docker 容器走主機 Clash一文處理的主軸，是如何把容器裡的流量接到宿主機上的 mixed-port／閘道路徑：著重在HTTP_PROXY、HTTPS_PROXY與NO_PROXY是否放對，以及Linux bridge能否連回宿主機監聽位址。這些設定解決不了的另一類問題，是dockerd 自己在宿主機命名空間拉映像時，已經直接向Docker Hub發起連線，而這條連線在Clash TUN／系統路由或規則順序下被導向錯誤出口。

換句話說：環境變數比較像「行程懂不懂得把請求交給代理」；而本篇談的是「當請求已經進入你的網路堆疊時，網域／SNI／IP會被哪條規則接住」。兩者在流水線上是先後銜接而非互相取代——你可以在宿主機先把Hub路由調順，再在 Compose／CI 裡補HTTP_PROXY策略給特定 builder。

快速自我檢查

若只有容器內apk add失敗、宿主機docker pull正常，優先回去查容器代理與NO_PROXY。
若宿主機docker pull本身很慢／握手逾時，優先查TUN／規則／DNS與本篇Hub 網域命中。
若公司強制 PAC／系統代理，留意dockerd未必繼承瀏覽器 PAC 邏輯。

4. DNS、Fake-IP 與 dockerd：Registry 最容易踩雷的組合

Clash／mihomo的DNS模組若啟用Fake-IP，理念是把網域先在本地映射成一個虛擬 IPv4位址，再在資料連線時透過嗅探把規則匹配拉回網域層級。對瀏覽器這類長連線場景通常很好用；但對docker pull這種大量並發 HTTPS、且進程對DNS TTL／快取極敏感的場景，一旦fake-ip-filter漏掉某些registry mirror主機名，或nameserver-policy分流不完全，就可能出現「解析看似成功，但後續握手對不上預期路由」的碎片化問題。

建議你把dockerd綁定的DNS來源弄清楚：Docker Desktop與Linux原生服務在這點時常不同；有些人會在daemon.json設定"dns"指向區網 DNS，這又會繞過你在Clash裡配置的DNS over HTTPS上游。若你看到TLS握手時間異常長，請同步檢查MTU或衛星／微波鏈路這類物理層因素——但它們通常會連帶影響所有 HTTPS，而非只有 Registry。

若要系統性調整Fake-IP與fallback，建議延伸閱讀Fake-IP／redir-host 分流與HTTPS SNI Sniffer兩篇，對照你自己的規則優先序是否在嗅探生效前就把流量送去錯誤的策略組。

5. mihomo／Clash 規則怎麼排，才不至於被粗條款截走

規則順序的基本精神只有一句：愈具體、愈攸關本次連線主機名的條款要愈前面。許多訂閱自帶的GEOIP,CN,DIRECT或過大的DOMAIN-KEYWORD「賭運氣」式匹配，會在你不知情時把某些CDN IP判進直連，結果對岸出口反而繞了一大圈或被重置；反过来，也有可能錯誤把海外 Registry塞進不快或不穩定的總分流裡。

下方 YAML 片段僅示範結構與順序意圖：請把PROXY-HUB換成你實際的策略組（可能是relay、url-test自動選組或某一個穩定節點），並注意不要與既有RULE-SET打架。registry mirror網域若由你和雲端廠商約定，請把對應主機名獨立列出，避免只用一個泛泛的DOMAIN-KEYWORD,mirror。

規則片段示意（請務必個案化）

# Place BEFORE overly broad GEOIP / DIRECT rules
rules:
  - DOMAIN-SUFFIX,docker.io,PROXY-HUB
  - DOMAIN-SUFFIX,docker.com,PROXY-HUB
  - # mirror hostnames you actually use:
  - DOMAIN-SUFFIX,example-mirror.example.com,DIRECT
  - MATCH,🐟 FINAL

如果你在調整自動選節點或fallback，可把Docker Hub綁定在一個RTT 較低且握手失敗率低的組別；這比起盲目全局切換節點更能維持開發機的日常穩定。細節可交叉閱讀url-test／fallback一文。

Snippet philosophy：規則不在於複製別人的長清單，而在於能用日誌證明命中正確；請務必在你的環境開啟連線紀錄後再裁剪。

6. daemon.json registry mirror 與分流並行時的對齊方式

Linux／伺服器場景裡，官方文件長期推薦透過/etc/docker/daemon.json設定"registry-mirrors"來縮短docker pull延遲：概念是把對Docker Hub的請求改送到離你更近的中繼 Registry。這與HTTP_PROXY並存時並不衝突——但要記住：mirror仍然是HTTPS Registry，也要經過TLS驗證；若你把鏡像網域規則設成直連但實際 ISP 對該 CDN 路由很差，表面上「走了就近鏡像」，仍會表現為握手逾時。

正確做法是：先在無代理乾淨環境確認鏡像網域解析與路由合理，再把對應DOMAIN／PROCESS（dockerd）規則套進Clash；而不是反向先用規則「強迫鏡像必須直連」。某些大型雲廠商的加速器網域會定期調整，請以服務商最新公告為準，並在你的連線紀錄裡確認真有命中。

daemon.json 結構示意（鏡像網址請替換）

{
  "registry-mirrors": ["https://mirror.example.com"],
  "dns": ["198.18.0.2"]
}

上面dns欄位只是展示「有些人會硬指向本機 DNS 出口」這件事在設定上會如何出現——值必須依你環境調整，錯誤指向只會讓一切映像拉取更慘。若你同時啟用BuildKit外出抓依賴，也記得區分build 階段與daemon 拉層是不同行程脈絡。

7. 實測工具箱：openssl、curl、日誌對時間軸

① 先用系統級dig或nslookup看registry-1.docker.io在你當前 DNS 出口下回什麼；再與Clash控制面板的 DNS 紀錄交叉比對。② 用openssl s_client -connect host:443 -servername host量測TLS是否在可接受時間內完成；若在此就卡住，多半還輪不到抱怨 Docker 映像快取。③ 用curl -v https://registry-1.docker.io/v2/觀察HTTP 401是否正常出現（代表層級已通、只是未帶 Token；與握手層問題不同）。

④ 針對dockerd，可啟用 debug 級別日誌（實際旗標依版本文件為準）觀察每一層 blob 連線到哪個主機名。⑤ 在mihomo連線紀錄中依時間戳排序，檢查是否有某個SNI一直被送去不一致的策略組。⑥ 若懷疑MTU問題，可用ping -M do -s …或路由器工具逐步縮包；這類問題往往會讓大檔下載階段才爆炸。

如果你在調校開發者網域分流時已熟悉Cursor／套件註冊表場景，可以把本篇視為同一套方法論延伸到Docker Registry：差別只在主機名集合與daemon.json mirror是否介入。

8. 常見情境快速對照

情境 A：只有 Hub 映像慢，GCP／GHCR 正常。優先檢視Docker Hub相關DOMAIN-SUFFIX是否落在較差的自動選組；這種「服務級」差異多半可由規則修正。情境 B：換了 mirror 反而更慢。多半是鏡像網域被錯誤直連或DNS 指向過期 IP。情境 C：同一 Wi‑Fi 下手機瀏覽器都快，唯有筆電 docker pull 爆炸。通常指向本機 Clash／TUN／路由表而非電信業者問題。

情境 D：在公司 VPN 開啟時才 handshake timeout。代表split tunnel可能把Registry IP導向錯誤隧道；需在 VPN 政策允許範圍內調整，而不是強行關閉公司安全機制。情境 E：間歇性 429／速率限制。這屬於Registry 官方管控，請放慢並發或改用身分驗證／私有鏡像策略；代理並不能無限規避合理使用限制。

訂閱基線仍為首要

若節點本身不可用或規則檔過舊，再多Docker Hub微調也是徒勞；請先到訂閱匯入教學確認基底可用，再回到本篇精修registry mirror與分流。

寫在最後

docker pull表面上只是終端機一行指令，背後卻同時經過DNS、TLS、可能有registry mirror介入的多段Docker Hub交付鏈——這正是為什麼「把所有 HTTPS 粗暴塞進同一個策略組」常常奏效卻不耐久：一旦某一 CDN 網域在你所在 ISP 的方向性惡化，你就會誤判成節點壞了。把網域級規則與連線紀錄對齊，才是開發者長期維運桌面環境時比較不累的做法。

相較於介面停滯、除錯資訊零散的老舊代理工具，成熟的Clash／mihomo生態能把docker pull這種大量連線場景拆解成可觀測的SNI／規則命中／DNS 決策三個維度；當你需要同時調Hub與鏡像加速器兩條出口時，這種透明度會直接反映在逾時是否消失上，而不是只能靠運氣重試。

若你希望用同一個安裝包完成訂閱匯入、系統代理或 TUN、DNS 與規則覆寫，並在終端機長時間拉映像時仍能對照連線紀錄定位問題，建議自本站下載頁取得最新用戶端，先把基底調順再回到registry mirror細節。完成校正後，CI 與本機建置鏈通常會立刻反映出差異——現在即可開始：→ 立即免費下載 Clash，開啟流暢上網新體驗。