問題形狀：為什麼 WSL2 裡打 127.0.0.1 常常不是 Clash

在純 Linux 或 macOS 上，許多教學會直接寫「把代理指到 127.0.0.1:7890」，因為 Clash 與終端機在同一個網路命名空間。但在 WSL2 裡，子系統跑在輕量虛擬機器後方：127.0.0.1 指的是Linux 這一側的 loopback，而不是你 Windows 主機上正在監聽的 Clash。於是你會看到一種很典型的割裂感：Edge 或 Chrome 已經能順暢走代理，回到 WSL 裡的 curl、apt、git 卻仍然逾時或連線被拒。

因此，WSL2 Clash 代理的正確心智模型是：把 WSL 當成「另一台在同一內網的機器」，代理伺服器位在 Windows 主機上，你需要的是主機在 WSL 虛擬網路內可達的 IP，再加上 Clash 實際對外開放的Windows 主機連接埠（常見為設定檔中的 mixed-port，或分開的 port／socks-port）。本篇與本站 原生 Ubuntu 上自行部署 Clash Meta 的路線不同：後者是在 Linux 內直接跑核心；前者則是「Linux 只當客戶端，出口全交給 Windows 上既有的圖形用戶端」。

ℹ️
與「區網共享」「TUN 全應用」的差異 若你想讓手機或遊戲機透過同一 Wi‑Fi 使用電腦上的 Clash，請改參考 區網代理與 Wi‑Fi 共享；若你希望「整台 Windows 幾乎所有程式都進 Clash」，則可延伸閱讀 Clash TUN 模式詳解。本文聚焦在 WSL2 與主機 loopback 不相通這條高頻踩坑，以及 apt git 走代理時最穩定的變數與設定檔寫法。

取得 Windows 主機在 WSL2 內的 IP：nameserver 與預設閘道

最穩定的做法之一，是讀取 WSL2 內建解析檔中的上游位址。多數發行版在 /etc/resolv.conf 會有一行 nameserver，其值通常就是目前這個 WSL 網路命名空間看得到的 Windows 主機 IP。你可以用下列指令快速檢視（輸出請以你機器為準）：

grep -m1 '^nameserver' /etc/resolv.conf | awk '{print $2}'

另一種常見寫法是從預設路由抓預設閘道，概念上同樣指向主機端：

ip route show default | awk '{print $3}'

兩者理論上應一致或至少同屬同一內網段；若你曾手動覆寫過 /etc/resolv.conf、或企業環境有自訂 DNS 轉送，請以「實際能從 WSL ping 通、且 Clash 有監聽在對應介面」為準。取得 IP 後，請先記下，例如下文以 172.x.x.1 代表「你的主機 IP」，實務請替換成真實數值。

Windows 端 Clash：確認 mixed-port、允許區網、以及防火牆

在 Windows 上，不論你使用 Clash Verge Rev 或其他基於 Clash Meta 核心的用戶端，請先完成三件事。第一，在設定檔或圖形介面中確認本機代理埠：多數範例會使用 mixed-port: 7890，代表同一個埠同時接受 HTTP CONNECT 與 SOCKS5（實際鍵名與預設值請以你的訂閱與用戶端為準）。若你改成分開的 port 與 socks-port，後續環境變數也要對應調整。

第二，務必開啟「允許區網連線」（Allow LAN／類似選項）。否則 Clash 可能只綁在 127.0.0.1，WSL2 從另一個網路介面連過來時會直接被拒絕。第三，檢查 Windows Defender 防火牆是否允許該埠的連入規則；僅有 Clash 行程在跑、但防火牆擋住連入，仍會讓 WSL 端看起來像「代理壞掉」。若你尚未完成 Windows 用戶端安裝，可先對照 Clash Verge Rev Windows 教學 把基礎環境跑通，再回到本文補 WSL 面向。

驗證方式建議分兩段：先在 Windows 本機用瀏覽器或 curl.exe 確認代理正常；再在 WSL 內對「主機 IP＋埠」下指令，例如（請替換 IP 與埠號）：

curl -v --proxy http://172.x.x.1:7890 https://www.example.com

若這裡仍失敗，請不要急著改 apt 或 git；先把「WSL → Windows 主機埠」這條路打通，後面所有工具都會跟著穩定。

bash／zsh：ALL_PROXY 與常見變數組合

多數命令列工具會讀取小寫或大寫的代理環境變數。實務上常見的組合是：http_proxy／https_proxy 指向 HTTP 代理（Clash 的 mixed-port 通常可用），以及 all_proxy 指向 SOCKS5（若你使用獨立 SOCKS 埠，請改成對應埠號）。在繁體中文社群討論裡，ALL_PROXY 配置常被當成「一次讓所有支援的程式走同一出口」的捷徑，但要注意：各程式對變數名大小寫與協定的支援度並不一致。

以下為示意（請替換 IP 與埠號；註解為英文以符合專案規範）：

# HTTP/HTTPS via Clash mixed-port on Windows host
export HOST_IP="$(grep -m1 '^nameserver' /etc/resolv.conf | awk '{print $2}')"
export http_proxy="http://${HOST_IP}:7890"
export https_proxy="http://${HOST_IP}:7890"
export HTTP_PROXY="$http_proxy"
export HTTPS_PROXY="$https_proxy"

# Optional: SOCKS if you expose a separate socks-port
# export ALL_PROXY="socks5://${HOST_IP}:7891"
# export all_proxy="$ALL_PROXY"

export NO_PROXY="localhost,127.0.0.1,::1"
export no_proxy="$NO_PROXY"

建議把上述段落寫進 ~/.bashrc 或 ~/.zshrc，並用 source ~/.bashrc 重新載入。若你使用多個 WSL 發行版，請各自維護一份，避免互相覆蓋。另可補上公司內網或容器 registry 的網段到 NO_PROXY，以免內部服務被誤送進公開節點。

使用 sudo apt update 時，預設可能不繼承你使用者的環境變數。解法包括：用 sudo -E（需謹慎）、或在 /etc/sudoers 設定 env_keep 保留代理相關變數、或乾脆改用下一節的 apt 專用設定檔，通常最乾淨。

讓 apt 穩定走代理：Acquire::http::Proxy 與 HTTPS

Debian／Ubuntu 系列的 apt 對環境變數的依賴不如 curl 直觀，因此實務上更推薦寫入 /etc/apt/apt.conf.d/ 下的片段檔。範例檔名可自取，例如 95proxy，內容如下（同樣請替換 IP 與埠）：

Acquire::http::Proxy "http://172.x.x.1:7890/";
Acquire::https::Proxy "http://172.x.x.1:7890/";

說明：apt 的套件索引與套件檔可能走 HTTP 或 HTTPS；兩行都寫可降低「只設一半導致部分鏡像仍直連」的機率。若你的環境使用自簽憑證或 HTTPS 攔截，請另外處理憑證鏈問題，本文不展開。完成後以 sudo apt update 測試；若仍失敗，請回到 Clash 連線紀錄觀察是否有來自 WSL 網段的命中紀錄，並比對規則是否把套件鏡像誤判為直連。

git：HTTPS 遠端與 SSH 遠端的差異

對於 https:// 形式的 Git 遠端，最常見做法是設定 Git 內建的 HTTP 代理：

git config --global http.proxy http://172.x.x.1:7890
git config --global https.proxy http://172.x.x.1:7890

若僅有特定主機要走代理，可使用針對網址的設定鍵，避免把公司內部 Git 也送進公開節點。相對地，[email protected]:... 這類 SSH 協定預設不會讀 HTTP_PROXY；要讓 SSH 走 HTTP CONNECT 或 SOCKS，需要額外的 ProxyCommand 或工具鏈，複雜度比 HTTPS 高一截。若你主要卡在 GitHub 大型倉庫的 clone／fetch，可優先改用 HTTPS 遠端，或延伸閱讀 開發者向的 GitHub 流量與規則對齊 以補齊多網域情境。

IPv6、DNS 與「雙堆疊」下的額外變數

部分網路環境會同時啟用 IPv4 與 IPv6。若你的 WSL 或上游鏡像優先走 IPv6，但代理或規則只涵蓋 IPv4，可能出現「偶爾極慢、偶爾斷線」的體感。排查時可觀察 Clash 日誌中的目標位址家族，並在測試指令加上 -4 或 -6 做對照。另請注意：WSL2 內的 DNS 解析行為與 Windows 不完全相同；若你遇到「解析得到、連線卻走錯策略」的狀況，請同步檢視 Clash 的 DNS 與 fake-ip 相關設定，避免把問題誤判成單純代理埠不通。

建議排查順序（濃縮版）

  1. 確認 Windows 端 Clash 正常、mixed-port（或分開埠）數值正確，且已允許區網連線。
  2. 在 WSL 取得主機 IP，並以 curl --proxy 對主機 IP 測試連線。
  3. 放通 Windows 防火牆連入規則後再重測。
  4. 寫入 shell 的 HTTP_PROXY／HTTPS_PROXY／ALL_PROXY（視工具需求），必要時補 NO_PROXY。
  5. 為 apt 使用 Acquire::http::Proxy 片段；為 git 使用 http.proxy／https.proxy。
  6. 若仍異常，回到 Clash 規則與日誌，確認套件鏡像或 Git 網域沒有被更早的直連規則命中。
⚠️
合規與風險提醒 請在所在地法令允許的範圍內使用代理與相關服務；本文僅說明 WSL2 與 Windows 主機之間的網路互通與常見設定位置，不提供任何違法用途的指引。請妥善保管訂閱與設定檔，並留意勿對外開放未授權的可連入代理埠。

結語：把 WSL2 納入同一套「主機側」Clash 策略

相較於在 WSL 裡再裝一套 Linux 版核心與 systemd，單純把 WSL2 當成「會打命令的開發容器」、出口統一走 Windows 上已驗證過的 Clash，通常更省維護成本：你只需要記住主機 IP 會變動的可能性、以及代理埠必須對 WSL 網段開放這兩個前提，就能把 apt git 走代理 的行為收斂到可預期的設定。與本站其他主題並列時，本文刻意補上「loopback 不相通」這塊與原生 Linux 教學的落差，讓讀者在選擇架構時更不容易走冤枉路。

若你希望先取得整理好的多平台用戶端與核心釋出連結，建議優先造訪本站下載頁選擇 Windows 與其他系統版本，再依 Clash 說明與教學文件 補齊概念；相較於四處搜尋來路不明的安裝包，這條路徑通常更利於長期更新與安全檢核。→ 立即免費下載 Clash，開啟流暢上網新體驗