WSL2 走不通 Windows 上的 Clash？鏡像網路與連接埠轉發逐步修復
許多人在 Windows 裡用瀏覽器上網正常，一進 WSL2（例如 Ubuntu）執行 apt update、curl、git clone 或 Docker 拉映像卻卡住——常見原因不是「Clash 壞了」，而是子系統與宿主機之間的網路邊界沒對齊：localhost 指到不同命名空間、代理只綁在 127.0.0.1、或防火牆擋掉從虛擬網卡來的連線。本篇在假設您已依 Windows 端 Clash 安裝教學 完成訂閱與模式切換的前提下，用可重現的順序整理：鏡像網路模式、如何取得正確的宿主 IP、Allow LAN／mixed-port、代理環境變數，以及必要時的 netsh 連接埠轉發，讓終端與容器儘量與 Windows 使用同一套 Clash 出口。
為什麼「Windows 能上、WSL2 不能」這麼常見
WSL2 的核心是輕量虛擬機器與虛擬網路。預設情況下，子系統裡的 127.0.0.1 指向Linux 網路命名空間自己，而不是您正在執行 Clash 的那個 Windows 使用者空間。於是您在 PowerShell 裡測 127.0.0.1:7890 成功，在 WSL 裡同樣指令卻失敗——這不是魔術，而是兩套回環介面。
另一條常見斷點是「Clash 只聽本機」。若 HTTP／SOCKS 入站綁在 127.0.0.1，從 WSL 虛擬網卡送過來的封包目的位址是宿主在虛擬區網上的 IP，而不是回環位址；此時需要讓 Clash 對區網介面開放入站（常見選項名稱如 Allow LAN），或改走鏡像網路讓 localhost 語意對齊。還有一類是防火牆規則：Windows Defender Firewall 可能允許本機程式連線，但對「從 WSL 子網進來」的連線仍要明確放行。
排查心法
一次只改一個變因：先確認「WSL 能 ping／連到宿主 IP 與代理埠」，再談規則分流、DNS 或 TUN。把鏈路拆成可達性 → 代理握手 → 策略命中三段，會比同時改三處設定快很多。
鏡像網路模式與傳統 NAT 有什麼差
在較新的 Windows 11 與 WSL 版本中，可啟用鏡像網路（mirrored networking）：讓子系統與宿主共享更接近「同一張網路視角」的行為，包含對 localhost 的互通支援。對「只想讓 WSL 裡的 CLI 指到 127.0.0.1:埠 就能打到 Windows 上的 Clash」這種需求，鏡像模式往往是最省心的底座。
若您仍使用傳統 NAT 模型，則要把代理位址寫成Windows 在虛擬區網上的 IP（常見作法是讀取 /etc/resolv.conf 裡的 nameserver 欄位，它多半指向宿主；仍以您機器上實際輸出為準），或使用 ip route 觀察預設閘道。不同組建與自訂 .wslconfig 會改變細節，請以當前 WSL 發行說明為準，不要硬抄過期截圖。
在您的使用者目錄建立或編輯 .wslconfig（與 Linux 家目錄無關，位於 Windows 使用者資料夾下），可加入下列片段以啟用鏡像模式（實際鍵名與可用性請對照您安裝的 WSL 版本文件）：
# ~/.wslconfig on Windows (merge with your existing file)
[wsl2]
networkingMode=mirrored
存檔後請在 Windows 端執行 wsl --shutdown，再重新開啟發行版，讓設定生效。若鏡像模式與公司 VPN 或第三方虛擬網卡衝突，可暫時還原並改走下文「宿主 IP + Allow LAN」路線。
Windows 端 Clash：mixed-port、Allow LAN 與綁定位址
無論使用哪種圖形前端，核心概念一致：WSL 要連進來，Clash 的入站必須在可從虛擬區網抵達的位址上聆聽。多數使用者會使用 mixed-port（同埠提供 HTTP 與 SOCKS）或分開的 port／socks-port。
- 若僅綁
127.0.0.1，在 NAT 模式下 WSL 通常打不進來。 - 啟用 Allow LAN（或同等選項）後，常見於綁
0.0.0.0，讓區網與虛擬網卡可連線。 - 開放區網入站代表同一區網其他裝置也可能連到您的代理埠；請只在信任的網路環境使用，並考慮防火牆限制來源 IP。與「刻意讓手機走電腦代理」不同情境可參考 區網 mixed-port 與 Allow LAN 專文。
安全提醒
Allow LAN 屬於擴大攻擊面的設定。若您會帶筆電到公共網路，請在離開前關閉，或搭配防火牆僅允許虛擬交換器子網，而非整個公共區網。
代理環境變數：http_proxy、ALL_PROXY 與 no_proxy
對 apt、curl、wget、許多語言套件管理器而言，最通用的接軌方式是標準環境變數。假設 mixed-port 為 7890，而您已確認從 WSL 可連到宿主（鏡像模式下可用 127.0.0.1；NAT 模式下請替換成實際宿主 IP）：
# Replace host if not using mirrored localhost
export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export ALL_PROXY="socks5://127.0.0.1:7890"
export no_proxy="localhost,127.0.0.1,::1"
說明：http_proxy／https_proxy 讓多數 HTTP 用戶端走 Clash 的 HTTP 入站；需要 SOCKS 的程式則看 ALL_PROXY。若您的核心將兩者拆在不同埠，請改成實際埠號。no_proxy 用於排除內部 registry、公司 Git、區網資產，避免無謂繞路。
將上述寫入 ~/.bashrc 或 ~/.zshrc 可登入自動生效；團隊腳本可改以 direnv 等方式隔離，避免把敏感出口設定擴散到不需要代理的專案。
apt 與 Docker：誰讀環境變數、誰要自己設定
APT
apt 有時不繼承互動式 shell 的環境變數。較穩的做法是在 /etc/apt/apt.conf.d/ 新增設定檔（需 sudo）：
# /etc/apt/apt.conf.d/95proxy — adjust host:port
Acquire::http::Proxy "http://127.0.0.1:7890/";
Acquire::https::Proxy "http://127.0.0.1:7890/";
NAT 模式下請把 127.0.0.1 換成宿主 IP。更新完執行 sudo apt update 驗證。
Docker Engine 與 docker pull
Docker Desktop 的 WSL2 後端裡，守護行程跑在獨立脈絡；僅在您的互動 shell 匯出 http_proxy，不一定會讓 docker pull 走代理。常見作法包括：為 Docker 服務設定 systemd drop-in（在 Linux 原生機）或使用 Docker Desktop 提供的 代理／資源介面；核心仍是讓拉映像的那個守護行程看見代理，而不是只有您的 bash。
建置映像時的 docker build 可透過 --build-arg 傳入 HTTP_PROXY 等變數；與「系統守護行程拉映像」是分開課題。若您改在 Linux 伺服器無圖形環境跑 Clash，可銜接 Linux 無頭環境 Meta 核心一文的路徑，但與「Windows 宿主 + WSL2」組合的邊界不同，請勿混用設定檔路徑。
仍連不上時：netsh 連接埠轉發作為橋接
少數環境下，即使 Allow LAN 已開，從 WSL 連宿主 IP 埠仍逾時。可在以系統管理員身分執行的 PowerShell 使用連接埠轉發，把對外介面上的埠轉到本機 Clash 實際聆聽處（以下為示意，埠號請替換）：
# Run in elevated PowerShell — example only
netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=7890 connectaddress=127.0.0.1 connectport=7890
netsh advfirewall firewall add rule name="WSL Clash forward" dir=in action=allow protocol=TCP localport=7890
完成測試後，若不再需要請刪除對應 portproxy 與防火牆規則，避免長期暴露。此段屬於進階排錯，請先完成基本連通性檢查再使用。
DNS 與 fake-ip：別讓最後一哩掉進解析坑
當 TCP 連代理已通，但特定域名仍怪異，請回頭查 Clash 的 DNS 模式與 fake-ip 行為；與 WSL 無關的類似症狀可對照 DNS 與 fake-ip 排查。WSL 內 /etc/resolv.conf 若被自動產生，請勿在不明原因下硬改為公網 DNS 而繞過內網解析需求。
實務檢查清單
- Windows 瀏覽器可上網且 Clash 日誌有流量——確認宿主側正常。
- 決定路線：鏡像網路（優先）或 NAT + 宿主 IP。
- 確認 mixed-port／Allow LAN 與實際聆聽位址；由 WSL
curl -v測代理埠。 - 設定
http_proxy／https_proxy／ALL_PROXY與合適的no_proxy。 apt另加apt.conf.d；Docker 改守護行程或 Desktop 設定。- 仍失敗再評估防火牆與
netsh portproxy，並記錄還原步驟。
常見問題
鏡像模式開了，仍無法用 127.0.0.1
請確認 WSL 與 Windows 版本符合功能前提、已 wsl --shutdown 重啟；並用 ss -lntp（Windows 上對應工具）核對 Clash 實際綁定位址是否仍限縮在本機。
Git SSH 不走 http_proxy
SSH 協定需透過 nc 的 ProxyCommand 或改走 HTTPS 遠端；與 HTTP 代理環境變數無直接關係。
通了但很慢
瓶頸可能在節點品質、規則把大量流量導向高延遲策略組，或 DNS 反覆逾時；請用 Clash 日誌看策略命中與連線目標。
下一步
把 WSL2 與 Windows 的代理鏈路對齊後，您就能在一致出口下開發、拉套件與建置映像。若您尚未在 Windows 完成客戶端安裝，建議從 Clash for Windows 安裝教學開始。