一、為什麼 127.0.0.1 在 WSL2 裡常指錯對象
WSL2 本質上是在輕量虛擬化環境裡跑一顆 Linux 核心，擁有自己的網路命名空間。因此當你在子系統裡寫 http_proxy=http://127.0.0.1:7890 時，127.0.0.1 指的是WSL2 自己，而不是Windows 宿主機上正在聽著連接埠的 Clash。瀏覽器在 Windows 裡設定「本機代理」可以連上，是因為那條連線發生在 Windows 的命名空間內；兩邊看似同一臺電腦，對 TCP 來說卻是不同終點。
要把 WSL2 裡的流量導到 Windows 上的代理，常見做法有三類：改用宿主機在虛擬網路上的 IP（最直覺）、在 Windows 做連接埠轉發把某個位址映射到 Clash 監聽埠，或在新版環境啟用mirrored 等網路模式讓 localhost 語意更接近直覺（見後文）。若跳過這一步直接懷疑節點或訂閱，往往會白忙一場。
curl -v http://127.0.0.1:（你的代理埠） 在 WSL2 裡測一次；若顯示連線被拒或逾時，而同一埠在 Windows 上用瀏覽器或 PowerShell 測試正常，幾乎可判定是命名空間／監聽介面問題，而不是出口節點故障。
二、Windows 端：Clash 監聽位址與「允許區域網路」
無論使用哪一種 Clash 圖形客戶端或核心（如 Mihomo），都要確認HTTP／SOCKS 混合埠實際綁在哪個介面。只綁 127.0.0.1 時，從 WSL2 虛擬網路過來的連線屬於跨命名空間的「連入」，Windows 可能根本不接收。多數客戶端提供「允許區域網路連線」或等效選項，本質上常是把監聽改為 0.0.0.0 或同時綁定區網介面，讓虛擬網段能連進來。
建議檢查項
- 在客戶端確認混合埠／HTTP 埠／SOCKS 埠數字，與你在 WSL2 設定的環境變數一致。
- 開啟「允許 LAN」或關閉「僅本機」類限制後，在 Windows 上用
netstat或資源監視器確認行程是否正在對外介面監聽目標埠。 - 若仍被擋，對照 《Clash Windows 11 混合埠與區域網路共享》 中的防火牆段落：Windows Defender 防火牆對「連入」規則很敏感，需為 Clash 主程式或核心行程放行私人網路（視你的 WSL 虛擬交換器歸類而定）。
這一步處理的是「封包有沒有到達 Clash」。若監聽仍僅在 loopback，而你又沒做轉發，WSL2 永遠對不到正確的監聽端點。
三、在 WSL2 取得 Windows 主機的可用 IP
在傳統 NAT 模式下，WSL2 會透過虛擬網路與 Windows 通訊。預設閘道那一側通常就是宿主機在該網段上的位址，因此可在子系統內執行 ip route show default，查看 default via … 後面的 IPv4，多數情況即為可連到 Windows 的位址。另一常見做法是讀取 /etc/resolv.conf 裡的 nameserver：在預設由 WSL 產生此檔時，該位址往往同樣指向宿主機（用於 DNS 轉送）。
取得 IP 後，在 WSL2 內用 curl -v --proxy http://（該IP）:（混合埠） https://www.example.com 做探測。若此時可通，而先前用 127.0.0.1 不行，便完成了一次決定性的對照實驗。請注意企業環境或自訂 Hyper-V 交換器時，閘道與名稱伺服器可能與家用情境不同，需以實際路由表為準。
/etc/resolv.conf，或啟用了 systemd 管理解析，nameserver 未必再代表宿主機；此時應以 ip route 為主，避免把代理指到錯誤的下一跳。
四、環境變數與工具差異：apt、git、curl
在 Linux 側，常見變數為 http_proxy、https_proxy、all_proxy 與 no_proxy。請統一使用宿主機 IP 或轉發後的位址，並帶正確配置式（http:// 與 socks5h:// 等）。no_proxy 應涵蓋區網與內部網域，避免內部 Git、私有套件庫被誤送進代理。
各工具行為提示
- curl：預設尊重環境變數；除錯時加
-v可看實際連線目標與 TLS 握手階段。 - git：除環境變數外，也可能使用
http.proxy／https.proxy設定；兩套來源並存時易混淆，建議用git config --list核對。 - apt：需
Acquire::http::Proxy等設定檔項目，單純 export 變數有時不生效；可參考發行版文件在/etc/apt/apt.conf.d/內建立片段。
若只有瀏覽器能上、命令列全掛，多半是工具未讀代理或仍指向 127.0.0.1，而不是 Clash 規則本身失效。
五、何時需要連接埠轉發（portproxy）
部分場景下，你希望 WSL2 內仍寫 127.0.0.1:埠，或與 Windows 上某固定本機位址對齊，可在系統管理員權限的 PowerShell 使用 netsh interface portproxy，把 WSL 可達的位址與埠轉到本機 Clash 監聽埠。這適用於腳本大量寫死 localhost、或與其他工具鏈綁定而難以全面改 IP 的情況。
設定後務必用 netsh interface portproxy show all 複查，並在重開機或睡眠恢復後確認規則是否仍在。轉發與「允許 LAN」、防火牆規則是疊加關係：任一環節缺失都會表現為連線失敗。若你同時使用 TUN 模式接管 Windows 本機路由，請留意與虛擬網路卡的互動；更完整的系統層排查可參考 《Clash TUN 與 Windows 路由、防火牆排查》。
六、DNS：resolv.conf、systemd-resolved 與 Fake-IP
代理「能連上」之後，第二類高發問題是名稱解析：命令列顯示正在連線卻長時間卡在解析，或解析到的位址與 Clash 內 DNS／Fake-IP 假設不一致。WSL2 發行版若啟用 systemd-resolved，實際生效的解析鏈可能由 resolvectl 與連結的 /etc/resolv.conf 共同決定，與你在 Windows 瀏覽器裡看到的「安全 DNS」設定無必然關係。
建議排查順序
- 在 WSL2 內用
resolvectl status（若可用）或讀取目前nameserver，確認查詢是否會經過宿主機、還是直接對外。 - 對照 Clash 設定中 DNS 模式（如
redir-host與fake-ip）：Fake-IP 下，本機若繞過核心做解析，可能出現「IP 看起來對了但連線行為錯亂」的現象。 - 暫時用
dig／nslookup對同一網域在 WSL2 與 Windows 各查一次，比對回應是否一致；若不一致，優先修正誰負責解析，而不是先換節點。
若你希望讓子系統與 Windows 上 Clash 的 DNS 行為強一致，可評估在 Clash 開啟適當的 DNS 監聽或轉發，並在 WSL2 將 nameserver 指到能觸達該監聽的位址（仍須符合安全與公司政策）。細部選項請以 設定與規則文件 與你所用核心版本為準。
七、WSL 網路模式與 mirrored 簡述
微軟持續調整 WSL 的網路模型；在支援mirrored（鏡像）模式的環境中，localhost 轉送行為可能與傳統 NAT 不同，部分使用者回報「子系統與 Windows 共用本機語意」後，設定代理的摩擦變小。是否可用取決於 Windows 與 WSL 版本與 .wslconfig 設定，升級後建議重新閱讀官方版本說明。
無論使用何種模式，排查時仍建議保留一條可重複的驗證路徑：從「能否 TCP 連到混合埠」→「HTTPS 是否通」→「DNS 是否一致」逐步收斂。模式切換後，舊的 resolv.conf 手改或固定 IP 腳本可能過時，宜重新量測而非沿用記憶中的位址。
八、現象與檢查項速查表
| 現象 | 優先檢查項 |
|---|---|
WSL2 內 127.0.0.1:埠 連不上，Windows 正常 |
localhost 命名空間；改宿主機 IP 或 portproxy；Clash 是否允許區網連入 |
| TCP 能通，HTTPS 或 git 仍失敗 | TLS 攔截與憑證；git 獨立 proxy 設定；規則是否分流錯誤 |
| 解析很慢或解析錯網域 | systemd-resolved／resolv.conf；Clash DNS 與 Fake-IP 是否一致 |
| 更新 WSL 或 Windows 後突然失效 | 網路模式是否變更；防火牆規則是否重置；宿主機 IP 是否漂移 |
把「連得到代理埠」與「解析與規則正確」拆成兩段驗證，可大幅減少同時改訂閱與系統設定造成的混亂。
九、小結
WSL2 與 Windows 上的 Clash 協作時，最常卡關的不是節點延遲，而是代理位址是否指向宿主機、監聽與防火牆是否允許虛擬網段連入，以及DNS 解析鏈是否與核心假設一致。依本文順序先對齊連線，再處理 systemd-resolved 與 Fake-IP，通常能穩定恢復 apt、curl、git 的出口行為。
相比只在瀏覽器裡切換系統代理，把兩套作業環境的網路語意對齊之後，日常開發與套件管理會省心許多；成熟 Clash 生態在規則與核心上的彈性，也能在跨平臺工作流裡延續同一套策略。
若你尚未在 Windows 安裝客戶端，或希望使用維護積極的版本與預設安全選項，可從本站下載頁取得安裝指引，再依上文順序自檢混合埠與 DNS。