文章目錄
docker pull 實際做了哪些步驟
對多數使用者而言，拉映像只是「下載一個大檔案」；但對 Docker Engine 來說，它至少包含三段常見延遲來源。第一是名稱解析：客戶端要把 registry-1.docker.io、auth.docker.io 這類主機名轉成位址；若本機或 daemon 指到的解析器回應慢、回 NXDOMAIN、或被導向內部黑洞 IP，後面步驟根本不會開始，終端機卻可能只顯示一行靜止的 pulling。第二是控制平面連線：向 Registry API 取 manifest、處理認證挑戰（challenge）、協商要拉哪些層；這層通常走 HTTPS，會吃滿 MTU、需要穩定的 TLS 往返。第三是資料平面下載：實際抓 blob／layers，頻寬與 RTT 在這裡最敏感，也最容易被限速或中途斷線。
因此，排查時請刻意把「解析很慢」與「下載很慢」分開記錄：前者多半是 DNS 或本機解析鏈的問題；後者才比較像跨國頻寬、機房壅塞、或特定出口被限速。若你把兩者揉成一句「網路不好」，很容易在半小時內試了十種設定卻沒有累積任何可對照的觀察。接下來的段落會用最少工具完成這種分層。
pending、逾時與錯誤訊息怎麼對應到層級
實務上最常見的症狀有三類。第一類是畫面長時間停在 Pulling fs layer 或 manifest 相關字樣，進度條幾乎不動：這時不要急著怪頻寬，先假設「控制平面尚未順利完成」，把 DNS 與到 443 埠的 TLS 握手放進優先檢查。第二類是層下載到一半反覆失敗、顯示 timeout 或 connection reset：這比較像路徑品質、mirror 不可用、或中途有中間設備拆掉長連線。第三類是認證相關訊息（例如需登入、token 取得失敗）：這與 VPN 無直接關係時，請先確認 docker login 狀態與時鐘是否準確；時鐘漂移會讓憑證與 token 流程看起來像「偶發網路問題」。
寫下你看到的完整錯誤字串與發生時間點（卡在第一步還是某個 layer id），下一輪對照會省很多時間。若同時在測多個映像，請先固定一個體積小的公開映像當探針，避免把「層太多」誤判成網路不穩。
基線：同一台機器、同一條指令、開關 VPN 對照
在動任何進階設定前，用同一個 shell、同一條 docker pull，連續做兩輪：VPN 關閉與VPN 連到你打算長期使用的節點。若兩輪現象完全一樣，問題比較不在「有沒有穿隧道」，而是在本機 DNS、daemon 設定、或公司網路政策；若只有在某一邊會好，才把重心放到出口地理位置、分流規則、或特定節點對 registry 邊界的相容性。
對照時盡量關掉其它會攔流量的本機工具（第二套 VPN、透明代理、抓包軟體），否則你以為在測 VPN，實際上是多層套娃。若你主要在 Linux 桌面開發，完成 Linux VPN（Ubuntu）下載安裝與首次設定完整教程（2026） 後再做這組實驗，可避免「客戶端尚未正確授權系統 VPN」造成假陰性——系統層隧道與容器 daemon 看到的介面狀態必須一致，對照才有意義。
優先排除 DNS：解析結果是否可信、是否一致
在宿主機上用系統解析工具查 registry-1.docker.io 與 auth.docker.io，記錄回應時間與位址清單。接著（若環境允許）用另一組公用解析器做一次對照，重點不是「哪組絕對正確」，而是你的 daemon 是否與宿主機看到同一個世界。若宿主機能解析且連線正常，但容器內或 daemon log 顯示解析失敗，幾乎可以鎖定 Docker 的 DNS 設定與系統脫鉤。
常見的地雷包含：公司內部 DNS 對特定公開域名回應過濾、路由器挿入攔截頁、或 VPN 連上後套用了只從隧道內可用的「私人 DNS」，導致在未調整daemon 的情況下，引擎仍去拿舊的或錯的解析器。此時不是換映像版本能解套，而是要把「誰在回答 A 記錄」先講清楚。若你懷疑 DNS 被污染或劫持，可短暫改用已知可信的上游做對照測試（僅限你有權限的環境），並在筆記中註明測試時間與還原步驟，避免把臨時設定變成半年後的未爆彈。
再查路徑：連線從哪個介面出去、是否被代理或攔截
當解析正常時，用輕量 HTTPS 探測確認「到 Registry 邊界的 TLS 是否可在合理時間內完成」。重點觀察：建立連線的耗時是否偶發飄到數十秒、是否固定在某個 Wi‑Fi 或某個國家節點才惡化。若只有特定節點差，與其在本機反复重裝 Docker，不如先換一個地理區位或線路級別，再把樣本數拉高到統計上可置信。
同時確認系統層沒有強制把 Docker 相關程式流量送去 HTTP 代理，卻未正確配置 HTTPS 隧道閘道；這類設定錯誤常讓症狀看起來像「pull 偶發永遠轉圈」。若你必須在受限網路環境開發，請依公司規範使用核准的代理設定，並確保 daemon 與 CLI 走同一策略，否則會出現 CLI 能登入但 daemon 拉不下來的矛盾現象。
Docker daemon 的 DNS 與系統 DNS 脫節時
Docker Desktop 與 Linux 上的 daemon 都能指定自己的 DNS 伺服器清單；當 VPN 修改了系統解析路由，但 daemon 仍指向舊的內網 IP，就會出現「瀏覽器能上網、pull 卻卡住」。排查方向是對齊兩邊：讓 daemon 使用與當前隧道相容的解析路徑，或在分流情境下明確指定會回應公開域名的一組伺服器。調整後通常需要重啟 daemon 才會貫穿所有背景連線。
另一方面，不要在未理解影響面的前提下，長期把 daemon 鎖死在某個硬編碼 DNS；一旦換工作或換 ISP，又會變成新的謎團。比較健康的做法是：把「宿主機解析／VPN 帶入的解析／daemon 設定」三欄寫進你的 runbook，未來同事接手只要照表抄一次就能重現環境。
分流與 VPN：什麼情況該讓 registry 走隧道、什麼情況不要
在「跨區頻寬很差但本地解析又不可靠」時，開 VPN 讓到 Docker Hub 邊界的整段 TLS走較乾淨的出口，常常能立刻改善；但若你的 VPN 預設是全隧道，且隧道內 MTU 偏小或對長連線不友善，也可能讓大層下載變得更不穩。此時值得評估分流：維持一般上網走原生路徑，只把特定目的地（或只把 Docker 相關程式／網域）送進隧道——實作細節依客戶端能力而異，觀念可對照 Windows VPN 分流怎麼設定？指定程式走隧道或直連步驟詳解（2026） 裡「預設策略＋例外規則」的敘事，再在 macOS 或 Linux 上找對應的介面。
分流不是偷懶，而是讓問題與觀察對齊：當你可以清楚描述「registry 相關連線走哪個介面」時，才適合去談要換節點還是改 DNS。若只靠感覺開關 VPN，往往會在同一個坑裡來回打轉。
MTU、公司網與鏡像站（簡短備忘）
某些 PPPoE、行動熱點或校園網環境在加掛 VPN 後，路徑 MTU 會比你想像更小；TLS 大封包被悄悄丟棄時，現象很像「無限 pending」。若你已經高度確定 DNS 沒問題，可將 MTU 疑難列為下一個實驗批次，並用小封包 ping 或大略調降介面 MTU 做二分搜尋——務必記錄原值以便還原。若組織提供內部 Registry mirror，優先確認 mirror 本身的憑證與路由，不要假設 mirror 永遠比公網 Hub 可靠。
傳輸協議層面若你需要在 UDP 受限環境找退路，可延伸閱讀 VPN 協議對比：WireGuard、OpenVPN 與私有協議各適合什麼場景，先確立隧道承載本身夠穩，再回頭優化 pull；否則只是在抖動的 pipe 上疊更多重試。
收斂結論與可長期維護的習慣
相較於泛泛地搜尋「Docker 下載慢」，把問題拆成解析、控制平面、資料平面三層，並用「開關 VPN 的對照實驗」當軸心，通常最快把原因從十種縮到兩種。市面上也有不少工具主打「一鍵加速」或含糊的節點行銷，卻不交代 DNS 與路由細節；長期維護上，你會更需要一個能講清楚出口與分流、且在桌面環境與行動環境之間設定邏輯一致的 VPN，而不是每次 pull 失敗就把鍋丟給映像尺寸。
DVDVPN 在 Windows、macOS、Linux、Android、iOS 上提供一致的帳號與節點體驗，新使用者註冊即可取得免費流量額度試用、無需綁卡；當你需要穩定的跨境 TLS、又希望必要時用分流保留內網或本機直連，可從本站 下載頁 取得對應平台的官方客戶端，並在 帳戶頁 檢視流量與連線狀態，再把同一套對照流程寫進團隊的容器開發 runbook。