📖 教學 ⏱ 約 19 分鐘閱讀

Docker Desktop 拉取映像失敗？與 Windows 11 主機 Clash 對齊代理與 DNS 分步操作（2026）

在 Windows 11 上開著 Clash（常見為 Clash Verge Rev 搭配 Mihomo／Clash Meta），瀏覽器與系統代理看起來正常，但 Docker Desktop 執行 docker pull、docker compose build 仍逾時，或容器裡 apt／apk 像完全沒走代理——這通常不是「節點突然全滅」，而是Docker 使用另一套網路與守護行程設定：它不會自動把 Windows「系統 Proxy」完整套到 Linux 後端的所有行為上。本篇與 WSL2 內 Git／npm 對齊 Clash 互補（那裡是終端機命名空間；這裡是 容器引擎），並銜接 Windows 11 首次安裝與斷網排查，專攻daemon.json、HTTP／HTTPS 代理、DNS 與建置參數該怎麼和主機上的 Clash 對齊。

先懂心智模型：Docker Desktop 不是「同一個 Windows 網路」

Docker Desktop在 Windows 上會透過虛擬化或 WSL2 後端跑一套 Linux 環境，映像拉取、容器建置與 registry 連線，多半由守護行程（daemon）處理；你在 Windows 裡勾了「使用 Proxy」，只代表願意遵循系統 Proxy 的 Win32 程式有機會吃到；Docker CLI 與 dockerd 是否走代理，要看 Docker Desktop 自己的設定、環境變數與 daemon.json，而不是假設「開了 Clash 系統代理就全機生效」。

另一方面，容器內執行的 apt update 或 curl，走的是容器自己的網路命名空間；若你只在 Dockerfile 裡寫了「要裝套件」，卻沒在建置階段傳入 HTTP_PROXY 或等效設定，常見現象就是「同一台主機，瀏覽器能開，Dockerfile 裡卻連不上」——這不是 Clash 突然失效，而是哪一層（daemon／build／runtime）該吃代理沒對齊。

步驟一：先確認 Windows 端 Clash 埠、allow-lan 與防火牆

在動 Docker 之前，請先在 Windows 上確認：① 核心已啟動且節點可用；② 你知道實際的 HTTP／SOCKS／mixed 埠（常見例如 7890，但請以介面為準）；③ 若你只允許本機連線，來自 Docker 後端虛擬網路的連線可能進不來——需要讓代理能接受來自區域網路／虛擬介面的連入，概念上等同於開 allow-lan 並注意綁定位址不是鎖死在 127.0.0.1。若你曾照區網共用 Clash調過防火牆，這裡的道理類似，只是請求來源變成 Docker 後端。

若你使用圖形客戶端，請在狀態列或設定中確認「系統 Proxy／TUN」哪一種是你主要依賴；對 Docker 而言，最穩的仍是明確把流量送進 Clash 的代理埠（或讓 Docker 設定指向該埠），並用連線日誌驗證實際命中的網域與規則。想先建立整體圖像，可搭配Clash 使用教學對照自己的模式。

步驟二：在 Docker Desktop 圖形介面設定 HTTP／HTTPS 代理

開啟 Docker Desktop → Settings（設定），依版本找到 Resources → Proxies 或類似名稱的「手動代理」區塊。通常需要填：

  • Web Server ／ HTTP：http://127.0.0.1:PORT 或 http://host.docker.internal:PORT（視版本與你對「宿主」的解析方式而定；重點是從 Docker 後端能連到 Windows 的 Clash 監聽埠）。
  • Secure Web Server ／ HTTPS：多數情境下與 HTTP 相同，指向同一組 Clash 埠；若你的代理對 HTTPS 另有獨立埠，請以實際客戶端顯示為準。

填完後套用並重啟 Docker（或依介面提示重啟後端）。若仍失敗，請不要立刻改訂閱；先在 Clash 的連線日誌看是否有來自 Docker 相關程序的連線嘗試，否則問題可能還在「Docker 根本沒把流量送到代理」。

步驟三：用 daemon.json 對齊 daemon 層（映像拉取、登入 registry）

圖形介面設定有時會同步到守護行程，但可重現、可版本控管的做法仍建議理解 daemon.json，其中與代理相關的常見結構是根鍵 "proxies" 底下的 "default"（實際鍵名與巢狀結構請以 Docker 官方文件與你的引擎版本為準）。概念上你要表達的是：daemon 在拉取映像、與 registry 通訊時，HTTP／HTTPS 流量要經過哪個上游代理。

{
  "proxies": {
    "default": {
      "httpProxy": "http://127.0.0.1:7890",
      "httpsProxy": "http://127.0.0.1:7890",
      "noProxy": "localhost,127.0.0.1,::1"
    }
  }
}

上例埠號請替換成你的 Clash 實際埠；noProxy 請依內網與 registry 需求補齊，避免私有倉庫被硬送去出口節點。修改後請重啟 Docker使設定生效。若你同時使用registry mirror（鏡像），請注意它與「代理」是不同層：鏡像解決的是從哪個 registry 端點拉取；代理解決的是到該端點的連線路徑。

步驟四：docker compose 與環境變數（建置／執行分開看）

docker compose 拉取映像時，通常仍走 daemon 的代理設定；若你在 compose.yaml 裡建置映像，則建置階段的 RUN apt-get 是否走代理，取決於 BUILDKIT 與 --build-arg 或 compose 的 args 是否傳入 HTTP_PROXY／HTTPS_PROXY。實務上常見寫法是在 compose 裡為 build 區塊加上：

build:
  context: .
  args:
    HTTP_PROXY: http://host.docker.internal:7890
    HTTPS_PROXY: http://host.docker.internal:7890

再在 Dockerfile 裡用 ARG HTTP_PROXY 搭配 ENV（依你需求決定是否只在建置期生效）。host.docker.internal 是 Docker 提供的主機位址語意，讓容器或建置環境能連回 Windows；若你的環境無法解析，請改回你在該網路下實測可用的宿主位址，並同步修正 Windows 防火牆規則。

步驟五：容器執行時 apt／npm 仍不走代理？

若映像已拉下來，但進入容器後才執行 apt／npm，此時走的是執行期環境變數與工具設定，不是「daemon 拉映像」那條路。請在容器內檢查 env | grep -i proxy，並在需要時用 docker run -e HTTP_PROXY=... 或 compose 的 environment 區塊注入。若你使用 CI 或腳本建置，也請確認非互動 shell是否載入相同的代理變數。

這一點與 WSL2 裡 bash 環境變數 的邏輯類似，但發生位置換成容器；請避免把「宿主已設好系統代理」當成「容器內一定自動繼承」。

步驟六：DNS 與 fake-ip、DoH 的對齊

Clash若採 fake-ip 或自訂 DoH，而 Docker 後端或容器仍用另一套解析結果，就會出現「同一個 registry 名稱，瀏覽器 OK、docker pull 不 OK」的錯位。處理策略通常是：

  • 在除錯階段先固定變因：對照 Clash 日誌裡實際連線名稱與目標主機，確認規則命中是否與預期一致。
  • 在 Docker Desktop 的 DNS 設定中（依版本在「Network」或類似頁），可選擇使用固定 DNS 或讓系統決定；若你懷疑解析被污染或與 fake-ip 衝突，請依官方文件嘗試對齊或在規則層讓該流量語意一致。

延伸可對照Clash TUN 模式深度解析，但本篇刻意把主路徑放在「daemon／建置／執行」三層的代理與 DNS 對齊，因為在 Windows 上通常最好講清楚、也最好教同事複製。

步驟七：建議的除錯順序（不要同時改三個地方）

當 docker pull 或 compose build 仍失敗，建議依序只動一個變因：

  1. Windows 瀏覽器先確認 Clash 與規則正常，避免其實是訂閱或 MATCH 兜底問題。
  2. Docker Desktop 代理設定是否已套用並重啟；daemon.json 是否與圖形介面一致。
  3. Clash 日誌是否出現 Docker 相關連線；若完全沒有，先回到「代理埠是否對 Docker 後端可達」。
  4. 建置階段：檢查 HTTP_PROXY 是否傳入 docker build／compose build。
  5. DNS 與目標主機：比對解析結果與規則命中，必要時調整規則或 DNS 模式。

安全與法遵提醒

開放代理給虛擬網路或區域網路，等同讓更多來源能把流量送進你的出口；請只在信任的機器與網路環境使用，並遵守所在地與服務條款。本文僅說明技術對齊與除錯思路。若需查核開源授權或原始碼，可自行前往專案頁；一般使用者取得安裝檔，建議優先遵循本站下載頁所整理的方式。

常見問題

為什麼我設了系統代理，docker pull 還是沒走 Clash？

因為 Docker 映像拉取主要由 daemon 處理，不一定讀 Windows 系統代理；請改用 Docker Desktop 的代理設定或 daemon.json，並重啟後再測。

容器裡 apt 能跑，但套件下載很慢或失敗，是 DNS 嗎？

可能是執行期沒走代理、或規則命中到不同出口；請在 Clash 日誌確認實際連線主機名稱，並對照 DNS 與 fake-ip 是否一致。

daemon.json 和圖形介面代理會衝突嗎？

不同版本合併策略不同；若你改完仍異常，請以官方文件為準，並盡量只保留一套可驗證的來源，避免兩邊各寫一半導致難以排查。

總結來說，Windows 11 上開著 Clash 卻無法映像拉取或容器建置卡在下載，最穩的做法是先把「Docker 守護行程、建置階段、執行期」三層的代理語意分開，再對齊 DNS 與規則日誌，而不是反覆只換節點。若你希望先在桌面把客戶端跑穩，再接到 Docker，建議從本站下載頁取得對應版本後，依首次設定完成本機驗證；實際上手後往往比純看設定截圖更能確認節點與規則是否合用——→ 立即免費下載 Clash，開啟流暢上網新體驗。