📖 教學 ⏱ 約 17 分鐘閱讀

WSL2 裡 Git 和 npm 不走代理？與 Windows 共用 Clash 的分步設定（2026）

在 Windows 上開著 Clash（常見為 Clash Verge Rev 搭配 Mihomo／Clash Meta），瀏覽器很順，但一進 WSL2 執行 git clone 或 npm install 卻像完全沒開代理——這通常不是「節點壞了」，而是混合網路下兩套環境沒對齊：localhost 各指各的、系統 Proxy 不會自動餵進 bash、DNS 也可能和 Clash 內建的解析策略各說各話。這篇與偏重圖形介面首次安裝的Windows 11 首次設定、以及偏重「網域規則怎麼寫」的Cursor／GitHub 分流文互補，專攻命令列工具在 WSL2 內如何指到 Windows 側同一套 Clash，並給可複現的檢查順序。

先懂心智模型：WSL2 不是「同一台電腦的同一張網卡」

WSL2 跑在輕量虛擬機器裡，對 Linux 來說，Windows 是另一個網路端點。你在 Windows 設定裡勾了「使用 Proxy」，只代表願意遵循系統 Proxy 的 Win32 程式有機會吃到；大多數在 WSL 裡跑的 git、node、npm 不會因此自動變成走代理。另一方面，127.0.0.1 在 WSL 裡指向Linux 自己，不是 Windows；若你把代理填成 http://127.0.0.1:7890，等於要 Linux 本機開著監聽埠，當然連不上 Windows 上的 Clash。

近版 WSL 有「localhost 轉發」相關能力，讓部分情境下從 WSL 存取 Windows 的 localhost 變得較直覺，但實務上仍建議明確使用 Windows 主機在虛擬區網中的位址（下文稱「宿主 IP」），並用同一組埠號對齊客戶端顯示的 mixed-port 或 HTTP／SOCKS 設定。這樣最不容易在更新 WSL 或切換網路後「昨天能用、今天又失效」。

步驟一：確認 Windows 端 Clash 真的在聽、且埠位正確

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

若你使用圖形客戶端，請在設定或狀態列確認「系統 Proxy／TUN」哪一種是你主要依賴；對 WSL 內的 CLI 來說，最穩的仍是明確把流量送進 Clash 的代理埠，而不是假設 TUN 會幫你把 Linux 流量一併接管——後者是否成立，取決於產品與版本，排查成本通常更高。想先建立「本機怎麼接到 Clash」的整體圖像，可搭配Clash 使用教學對照自己的模式。

步驟二：在 WSL2 取得「Windows 宿主 IP」

你需要一個從 WSL 連得到 Windows 代理埠的位址。常見做法有兩類，請擇一固定寫進設定，並在更新或換網後重查一次：

  • 預設路由閘道：在不少預設 NAT 組態下，Windows 主機會出現在 Linux 的預設路由下一跳。可在 WSL 內用 ip route show default 觀察，或以一行指令取出閘道 IP（不同發行版工具略有差異，重點是「default via 後面那個位址」）。
  • 傳統 resolv 技巧：早期教學常請你讀 /etc/resolv.conf 裡的 nameserver，把它當成「宿主」。在部分新組態下這個檔案可能是自動產生且語意有變，若你發現內容不像預期，請回到上一條用路由查閘道，或查官方文件對應你目前的 WSL 版本。

取得 IP 後，建議在 WSL 內用 curl 對 http://該IP:你的埠 做最小連線測試（先確認 Windows 防火牆沒有擋掉來自 WSL 網段的 TCP）。若這裡就不通，先不要怪 Git 或 npm，而是先把「Linux → Windows 代理埠」這條路打通。

💡 小提示 把宿主 IP 寫死成「某次抄到的數字」很容易在 DHCP 變更後失效。可將取得 IP 的指令包進你的 shell 設定檔，或改用腳本每次開機計算一次，再匯出環境變數。

步驟三：用環境變數讓大多數 CLI「預設走代理」

許多工具會讀 http_proxy、https_proxy、all_proxy（大小寫變體亦常見）。典型寫法是把代理指到「宿主 IP + Clash 的 HTTP 或 SOCKS 埠」。若你的 Clash 使用 mixed-port，通常可以同時用 HTTP 形式填寫；若你拆成獨立埠，請勿把 HTTP 流量誤填到純 SOCKS 埠，反之亦然。

同時建議設定 no_proxy，把 localhost、127.0.0.1、內網網段與公司內部網域放進例外，避免內部 registry 或私有 Git 被硬送去出口節點。這一步對「混合網路」特別重要：開發者往往同時要連公雲與內網，全機硬代理最常踩的雷就是內部服務突然連不上。

# Example — replace HOST and PORT with your Windows host IP and Clash port
export http_proxy="http://HOST:PORT"
export https_proxy="http://HOST:PORT"
export all_proxy="socks5://HOST:PORT"
export no_proxy="localhost,127.0.0.1,::1"

上述 all_proxy 是否必要、要用 SOCKS5 還是只用 HTTP，取決於你實際要跑的工具與目標協定。原則是：先最小可行（只設 http_proxy／https_proxy）測通，再視需要補齊。

步驟四：Git 仍不走？請用 git config 對齊代理語意

有些環境下 Git 對代理的讀取順序與其他工具不同，或你只想讓 Git 走代理、不想影響整個 shell。可以用：

# Example — use your real Windows host IP and Clash port
git config --global http.proxy http://HOST:PORT
git config --global https.proxy http://HOST:PORT

若你使用 SSH 連線（例如 [email protected]:），HTTP 代理設定不會幫到 SSH；要嘛改走 HTTPS，要嘛為 SSH 另外處理（例如 ProxyJump 或 nc 代理指令），這已超出「與 Clash 同一個 HTTP 埠」的最小範例，但請先在腦中分清楚你實際用的是哪一條協定，避免改半天以為是 Clash 壞掉。

另外，Git 的憑證助手與大型檔案下載可能觸發不同主機名稱；若你已能 clone 小 repo，却在抓 LFS 或大包時失敗，請回到 Clash 連線日誌看實際命中的網域與規則，與GitHub 分流文裡提到的物件儲存網域是否一致。

步驟五：npm／pnpm／yarn 與 registry 的代理欄位

npm 常見設定方式包括環境變數（延續上一節）以及 npm config set proxy／npm config set https-proxy。使用公司內部 registry 或自建 Verdaccio 時，也要同步檢查 registry 本身是否必須直連；必要時用 npm config delete 清掉過期欄位，避免舊值覆蓋新環境。

實務上很容易遇到「npm 顯示在用代理，但某個 tarball 仍從被牆或很慢的 CDN 拉」——這其實已進入規則與節點品質層次。請在 Clash 日誌確認該 tarball 主機名稱命中哪條規則，是否需要為該 DOMAIN-SUFFIX 調整群組，而不是一再改埠號。若你懷疑是 DNS 解析到不理想的目標，請一併閱讀下一節。

步驟六：DNS 與「解析看起來正常卻連不上」

WSL2 內的解析路徑可能與 Windows 不同步：Clash 若採 fake-ip 或自訂 DoH，而 Linux 仍用另一套解析結果，就會出現「同一個網址，瀏覽器 OK、CLI 不 OK」的錯位。處理策略通常是二選一：① 讓需要走代理的流量把 DNS 也交給 Clash 處理語意（依核心與模式而定）；② 至少在除錯時固定變因，先確認「WSL 解析到的 IP」與「Clash 日誌看到的連線目標」是否在同一條故事線上。

若你正在使用 TUN 或更進階的透明轉發，請注意與 WSL 的互動可能因版本而異；可延伸對照Clash TUN 模式深度解析，但本篇刻意把主路徑放在「CLI → 明確 HTTP／SOCKS 代理埠」，因為它在 WSL2 上通常最好講清楚、也最好教同事複製。

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

當 git 或 npm 仍然失敗，建議依序只動一個變因：

  1. Windows 本機瀏覽器先確認 Clash 與規則正常，避免其實是訂閱或 MATCH 兜底問題。
  2. WSL → 宿主 IP:PORT 用最小連線測試確認「代理埠對 Linux 可達」。
  3. 環境變數是否在目前 shell 生效（開新終端機、非互動 shell 是否載入設定檔）。
  4. Git／npm 是否有自己的 proxy 設定覆蓋環境（git config --list、npm config list）。
  5. DNS 與目標主機：用日誌比對實際連線名稱，必要時調整規則或 DNS 模式。

安全與法遵提醒

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

常見問題

為什麼我設了 http_proxy，只有 curl 有效、Git 還是不走？

可能是另一個 shell 沒載入設定、或被 git config 的舊代理值覆蓋；也可能是你實際使用 SSH URL，與 HTTP 代理無關。請用 git config --global --get http.proxy 與實際 clone URL 協定交叉確認。

可以把代理寫成 127.0.0.1 嗎？

在 WSL2 內，127.0.0.1 通常指向 Linux 自己；除非你能確認目前版本下 localhost 轉發行為與你的 Clash 監聽方式完全一致，否則請改用宿主 IP，減少更新後行為改變的風險。

npm 連上了但速度仍慢，是 WSL 的問題嗎？

不一定。請先在 Clash 日誌確認慢在 DNS、規則命中、還是節點路徑；有些套件下載會打到不同 CDN 主機名稱，規則沒覆蓋時會看起來像「隨機很慢」。

總結來說，WSL2 與 Windows 並用時，最穩的做法是先把「Linux 怎麼找到宿主上的 Clash 埠」寫清楚，再用環境變數與 Git／npm 各自的設定補齊語意，最後才處理 DNS 與規則細節。相較於在社群帖子裡拼片段指令，一次把混合網路的邏輯對齊，長期維護成本會低很多。若你希望先在 Windows 桌面把客戶端跑穩，再接到 WSL，建議從本站下載頁取得對應版本後，依首次設定完成本機驗證；實際上手後往往比純看設定截圖更能確認節點與規則是否合用——→ 立即免費下載 Clash，開啟流暢上網新體驗。