WSL2 終端走 Windows Clash：鏡像網路與 localhost 代理實測（2026）

1. 為什麼 WSL2 裡的 127.0.0.1 多半不是 Windows 上的 Clash

WSL2 是以輕量虛擬機方式運行 Linux 核心，對使用者來說雖然「好像就在同一台電腦上」，但在網路堆疊上，WSL 裡的 127.0.0.1 指的是這個 Linux 環境自己的迴環介面，而不是你在 Windows 工作階段裡開啟的 Clash 監聽埠。也因此，常見的錯誤直覺是：「我在 Windows 上看到 Clash 聽在 127.0.0.1:7890，那我在 WSL 裡也打同一個位址不就好了？」——在預設網路模式下，這通常不會接到你以為的那個服務。

要把 WSL 裡的終端代理流量送到 Windows 上已運行的 Clash，核心問題其實只有一句話：從 WSL 發出的 TCP 連線，要送到「Windows 宿主機在該路由環境下可達的那個 IP」上的 mixed-port（或你設定的 HTTP／SOCKS 埠）。接下來的章節會說明如何穩定取得這個位址，以及微軟較新的鏡像網路選項如何改變這個故事。

2. 取得 Windows 宿主機 IP：預設 WSL2 最常用的兩種查法

在傳統／預設的 WSL2 網路模型下，實務上最常見的做法是先找出「WSL 視角下，通往 Windows 的那個下一跳」。許多教學會請你查看 /etc/resolv.conf 裡的 nameserver，在不少組態中它會落在私有網段（例如 172.x.x.x），並且可當成 Windows 宿主機位址來連線測試。另一個常見做法是看預設路由：ip route show default 顯示的 default via 位址，往往與你需要的宿主機位址一致或高度相關。

為什麼這裡要強調「實測」？因為 WSL 版本、Windows 版本、是否安裝過第三方虛擬網卡或 VPN、以及公司網路政策，都會讓檔案內容與路由表長得不一樣。最穩健的習慣是：每次懷疑位址過期，就用同一套指令重新確認，再用 curl -v 對你的代理埠做一次最小連線測試。

# default gateway (often the Windows host from WSL's perspective)
ip route show default

# resolver file (nameserver line is a common hint on many setups)
grep -E '^nameserver' /etc/resolv.conf

取得位址後，把代理 URL 寫成類似 http://<HOST_IP>:<MIXED_PORT>（實際埠號以你的 Clash 設定為準）。若你接下來要開啟 allow-lan 讓 WSL 能連進來，請同步閱讀站內 allow-lan 與區網暴露相關說明，避免為了開發方便而把監聽範圍擴大到不必要的網段。

3. 鏡像網路模式：什麼時候 localhost 變得「比較像同一台」

微軟在較新的 Windows／WSL 版本上推進鏡像網路（Mirrored networking）等能力，目標之一是讓 WSL 與 Windows 的網路視角更一致。在啟用並符合條件的情況下，使用者會感覺到：localhost／埠轉發相關行為更接近「同一台機器上互連」的直覺，對開發者來說可減少一些手動查 IP 的心智負擔。

但實務上仍建議你把鏡像模式當成加速器與可選優化，而不是萬靈丹：不同版本文件與實際行為可能演進，且你的環境可能還有 VPN、Hyper-V、其他虛擬網卡參與路由決策。最穩的落地方式是：先能用「宿主機 IP + mixed-port」走通，再視需要研究鏡像模式是否能簡化你的團隊工作流程。

4. Windows 端 Clash：mixed-port、綁定位址與 allow-lan

無論你用哪種方式從 WSL 連到 Windows，Windows 上的 Clash 必須在「WSL 連得到的那個介面」上開放埠。多數圖形客戶端會提供 mixed-port（同時承載 HTTP 與 SOCKS 的常見做法之一），但你仍要確認兩件事：第一，埠號沒有和其他軟體衝突；第二，若你只綁 127.0.0.1，則只有 Windows 本機迴環可連，WSL 這類跨命名空間的來源常常會被拒於門外。

因此實測時常會看到需要開啟允許區域網路／LAN 存取（常見設定名稱如 allow-lan），讓監聽不只侷限在迴環。這會連帶帶來安全邊界問題：你的代理埠在信任網域之外是否可被接觸，應搭配防火牆與使用情境評估。這與「把服務暴露給整個區網」是同一枚硬幣的兩面，請不要只在開發機上複製貼上關鍵字而忽略風險。

5. WSL 內設定終端代理：環境變數與工具鏈差異

當 Windows 端的埠與監聽範圍確認無誤後，WSL 內最常見的做法是設定 HTTP_PROXY、HTTPS_PROXY，必要時再加上 ALL_PROXY（視工具是否讀取）。許多使用者會把這些變數寫進 ~/.bashrc、~/.zshrc 或 fish 的設定檔，並用一段可切換的函式包起來，避免永遠強制走代理導致內網或本機服務被誤送。

apt 在部分發行版上會遵循環境變數，但也可能受 Acquire::http::Proxy 等設定影響；git 除了環境變數，也可能使用 http.proxy 設定；npm／pnpm／yarn 各有自己的設定入口與快取行為。換句話說：「我在 shell 裡 export 了」只解決了一部分工具，遇到頑固案例時要回頭確認該工具到底讀哪一層設定。

export HTTP_PROXY=http://172.24.160.1:7890
export HTTPS_PROXY=http://172.24.160.1:7890
export ALL_PROXY=socks5://172.24.160.1:7890
# 172.24.160.1 is a placeholder; use your measured host IP

也請保留合理的 NO_PROXY：例如本機開發站、公司內部網域、容器 registry 等，避免「外網走代理沒問題，內網反而全炸」的體感。若你同時在 Windows 上用 Docker Desktop，並且需要容器內連宿主機代理，請改參考站內 Docker 容器走主機 Clash：那篇文章的閘道與 bridge 視角與 WSL2 終端不完全相同，混用時最忌「把同一個位址硬套到兩種環境」。

6. resolv.conf、DNS 與 Fake-IP：別把「能 ping」當成「規則有命中」

另一個高頻混淆點是：DNS 解析發生在哪裡。WSL 內的 /etc/resolv.conf 可能由系統自動生成，顯示的名稱伺服器位址常被拿來當「宿主機提示」，但它不等於告訴你「所有應用程式的 DNS 都一定會經過 Clash 的 DNS 模組」。當你在 Clash／mihomo 裡啟用 Fake-IP 或自訂上游 DNS 時，Windows 與 WSL 兩邊的解析路徑如果不一致，會出現典型症狀：瀏覽器看起來正常，終端機裡某個工具卻一直連到「不像你想像的那個網域／IP」。

這類問題的處理原則是：先確認TCP 連代理埠是否成功（網路層是否到達 Windows），再分開處理名稱解析與規則命中。把兩件事混成同一個「我猜是 DNS」會大幅拉長除錯時間。

7. 連不通時的排查順序（建議照順序做）

下面這份順序是實務上最省時間的路徑：① 先確認 Windows 上 Clash 正在運行，且 mixed-port 的埠號與你 WSL 內使用的相同；② 確認監聽不是只綁 127.0.0.1（必要時調整 allow-lan／綁定位址策略）；③ 在 WSL 內重新量測宿主機 IP（不要沿用幾天前的舊值）；④ 用 curl -v 對 http://<HOST_IP>:<PORT> 做最小化連線，觀察是 Connection refused、逾時、還是代理握手錯誤；⑤ 再看工具是否真的讀了 HTTP_PROXY；⑥ 最後才進入 DNS／Fake-IP／規則命中的交叉比對。

其中 Connection refused 多半代表位址對了但服務沒聽或被本機防火牆擋；長時間逾時則更像路由不可達或錯誤的 IP。把錯誤訊息分桶後再對症下藥，會比一次改十個設定更有效。

8. 與 Docker 宿主機代理文的差異（何時改看另一篇）

若你的主要痛點是 Docker 容器內連線、host.docker.internal、或 Linux bridge 上的閘道路由，請優先閱讀 Docker 容器走主機 Clash。該文處理的是容器網路命名空間與映像建置／Compose的脈絡；本篇則處理 WSL2 Linux 使用者空間如何把 CLI 流量送到 Windows。兩者都可能用到 HTTP_PROXY，但「宿主機」在路由表裡指到的物件常常不是同一個位址，這也是實務上最容易複製貼上失敗的原因。