1 為何 WSL2 不會自動跟著 Windows「系統代理」
在 Windows 桌面開啟 Clash 的系統代理後，Edge、Chrome 與多數 Win32 程式會讀取系統 Proxy，流量導向本機 127.0.0.1 上的 mixed-port 或 HTTP 埠。但 WSL2 內的 Linux 是獨立的網路命名空間，透過虛擬化與 Windows 主機通訊；預設情況下，Linux 內的行程不會自動繼承 Windows 登錄檔或 WinHTTP 寫入的代理設定。因此您會看到「瀏覽器已翻牆，終端機裡 curl 卻仍走直連」的割裂現象——這不一定是節點故障，而是雙網路棧未對齊。
另一個高頻問題是 DNS：WSL2 發行版常透過 /etc/resolv.conf 指向 Windows 側解析器；若 Clash 使用 FakeIP 或自訂 DNS 鏈路，而 WSL 內仍用另一套解析結果，可能出現「網域能 ping、HTTPS 握手失敗」或「只有特定網域異常」。因此實務上需要同時處理出站走哪個 HTTP／SOCKS 代理，以及名稱解析是否與 Clash 規則一致。以下步驟以「先讓 TCP 流量穩定到達 Windows 上的 Clash，再細調 DNS」為順序，與站內TUN 模式與終端機代理類文章互補：本文聚焦WSL2 與宿主機 Clash 的銜接，而非在 Linux 內另起一個 Mihomo 常駐（若您要純 Linux 常駐，可另參Linux Mihomo systemd 教學）。
2 Windows 端：開啟 Allow LAN、確認監聽位址與埠
WSL2 要連到 Windows 上的 Clash，封包目標必須是「從 Linux 看得見的那個 IP」，而不是只在 127.0.0.1 監聽卻拒絕區網連線。請在 Clash Verge Rev（或您使用的圖形介面）中確認：Allow LAN（允許區域網路／外部連入本機埠）已開啟，且核心實際監聽在 0.0.0.0 或等同於接受非本機介面的位址。混合埠 mixed-port 常見為 7890，實際數字以您的設定檔為準。
若您尚未完成 Windows 側安裝與系統代理基礎設定，建議先對照Clash Verge Rev Windows 安裝教學，避免埠號、服務模式與防火牆規則不一致，否則後續在 WSL 內怎麼設 http_proxy 都會連線被拒。
3 取得「宿主機」IP：resolv.conf 與預設 NAT
在未啟用鏡像網路的傳統 WSL2 設定下，從 Ubuntu 內存取 Windows 主機的常見方式，是讀取 /etc/resolv.conf 中的 nameserver 欄位：該位址多半是 WSL 為您配置的預設閘道／主機在虛擬網路上的 IP，可用來組 http://<HOST_IP>:<PORT> 形式的代理 URL。請在 WSL 終端機執行（僅示意，請以實際輸出為準）：
grep -E '^nameserver' /etc/resolv.conf
將取得的 IP 記為 WIN_HOST，代理埠記為 7890（請改為您的 mixed-port）。在驗證階段可先測試：
export HOST_IP=$(grep -m1 '^nameserver' /etc/resolv.conf | awk '{print $2}')
curl -x "http://${HOST_IP}:7890" -I https://www.google.com若此時仍逾時或連線被拒，請回到上一節檢查 Allow LAN 與防火牆；若成功，代表 WSL2 已能將 HTTP 代理流量送到 Windows 上的 Clash，後續只是把這組位址寫進 apt 與 shell 環境。
4 鏡像網路模式：讓 127.0.0.1 與主機共享語意
自 Windows 11 起，WSL 可選用鏡像網路（Mirrored networking）模式：在此模式下，WSL 與 Windows 共享更接近「同一張網路平面」的行為，在 WSL 內使用 127.0.0.1 往往可直接連到 Windows 上監聽的服務，因此代理 URL 可簡化為 http://127.0.0.1:7890，不必每次從 resolv.conf 推算宿主機 IP。這能顯著降低教學與腳本維護成本，也減少公司網路或 VPN 變更時 IP 漂移帶來的斷線。
啟用方式（需較新 Windows 與 WSL 版本，實際選項以微軟文件為準）：在使用者目錄建立或編輯 .wslconfig，於 [wsl2] 區段加入 networkingMode=mirrored，存檔後在 Windows 以 wsl --shutdown 重啟子系統，再開啟 Ubuntu 驗證。若您啟用鏡像後仍希望沿用 WIN_HOST 寫法，兩者通常也可並存，但請擇一為主，避免同一台機器上多份互相矛盾的代理設定。
[wsl2]
networkingMode=mirrorednameserver IP 法，不要硬套設定檔。
5 環境變數：http_proxy、https_proxy、ALL_PROXY
對多數命令列工具，建議在 ~/.bashrc 或 ~/.zshrc 內設定（鏡像模式用 127.0.0.1，NAT 模式用 WIN_HOST）：
# Mirrored: proxy on Windows 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"
# NAT: use host IP from resolv.conf
# 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"
ALL_PROXY 是否使用 SOCKS 取決於您的 Clash 埠型態；若僅開 HTTP／mixed，請與圖形介面顯示一致。設定後執行 source ~/.bashrc，再以 curl -I https://example.com 測試。若需切換「走代理／直連」，可封裝函式或另開不載入代理的工作階段，避免長期把敏感內網流量誤送代理。
6 apt 專用：Acquire::http::Proxy
apt 不一定繼承互動式 shell 的環境變數（視版本與呼叫方式而定）。最穩妥作法是在 /etc/apt/apt.conf.d/ 新增一檔（例如 95clash-proxy.conf），由 root 寫入（將位址改為您的鏡像或 NAT 方案）：
Acquire::http::Proxy "http://127.0.0.1:7890/";
Acquire::https::Proxy "http://127.0.0.1:7890/";
NAT 模式下將 127.0.0.1 換成 resolv.conf 取得的 WIN_HOST。完成後執行 sudo apt update 觀察是否仍卡在連線或憑證驗證；若僅特定鏡像慢，可另搭配台灣或鄰近區域的 sources.list 鏡像，與「是否走代理」分開考量——代理解的是出境路徑，鏡像解的是套件伺服器地理距離。
7 Git、curl、wget
Git 可設定全域代理（同樣依鏡像或 NAT 替換位址）：
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890
若僅部分網域需代理，可改用 insteadOf 或條件式設定；取消時設為空字串即可。curl、wget 在已匯出 http_proxy／https_proxy 時通常會跟隨；若某腳本清空環境，請在該腳本內顯式帶上 -x 或 --proxy。
8 DNS 與 resolv.conf 被覆寫
WSL 可能在每次啟動時重新產生 /etc/resolv.conf；若您手動改寫却被還原，請在 /etc/wsl.conf 設定 [network] 底下 generateResolvConf = false，再自行維護解析檔——細節依發行版與 WSL 版本略有差異，升級前請備份。若 Clash 使用 FakeIP，請確保 WSL 內的 DNS 查詢也經過相同邏輯，否則可能出現「IP 看起來正確、實際連線卻錯策略」的現象；此時可優先參考站內Meta 核心 DNS 防洩漏，對照 FakeIP、DoH 與嗅探選項。
實務上許多使用者會在排錯時先暫時關閉過度進階的 DNS 實驗，確認「純代理、純系統 DNS」可通後，再逐項加回 FakeIP 與規則，以免同時改動 WSL、Windows 與 Clash 三處變因。
9 常見症狀與排查
- 只有 apt 慢或失敗：優先檢查
apt.conf.d是否單獨指定代理，與 shell 環境是否一致；並確認走 HTTPS 的套件索引未被中間人攔截。 - curl 正常、瀏覽器在 Windows 正常，但 Git SSH 仍失敗：SSH 預設不走 HTTP 代理；需改用 HTTPS clone、或為 SSH 設定
ProxyCommand／走 VPN／TUN 類方案，與本文 HTTP 代理路徑不同。 - 間歇性連不上宿主機 IP：留意睡眠喚醒、VPN 與虛擬網卡順序變更；鏡像模式或固定腳本從
resolv.conf讀取可有助穩定。 - 升級 Windows 後行為改變：重新確認 WSL 版本與
.wslconfig是否仍生效，必要時wsl --update與wsl --shutdown。
10 總結
在 Windows 已執行 Clash 的前提下，要讓 WSL2 內 Ubuntu 的 apt、Git 與 curl 穩定走代理，核心是先讓 Linux 側能連到主機上的監聽埠：開啟 Allow LAN、選擇鏡像網路（可簡化為 127.0.0.1）或沿用 /etc/resolv.conf 內 nameserver 所代表的宿主機 IP，再分別寫入 apt 的 Acquire::http::Proxy 與 shell 的 http_proxy。同時別忽略 DNS 與 resolv.conf 是否與 Clash 的 FakeIP／規則一致，否則會出現「代理已通、解析卻打架」的假性故障。
相較在論壇零散複製指令，先釐清雙網路棧再動手，長期維護成本更低。若您尚未在 Windows 安裝用戶端或希望與本站教學版本一致，建議從本站下載頁取得 Clash Verge Rev，再依本文與 Windows 安裝、TUN、DNS 專文逐步銜接。
