Windows 11 上 Clash 與 WSL2 同時使用會斷網？預設路由、Hyper-V 與 MTU 逐步修復

先對症狀分類：是「只有 WSL 沒網」還是「兩邊一起抖」？

在 Windows 11 上，許多開發者會同時使用 Clash 類用戶端（系統代理、PAC，或 TUN 虛擬網卡）與 WSL2。實務上最常見的抱怨有兩類：第一類是 Edge 或 Chrome 在宿主機上完全正常，但一進 WSL，curl、apt、git pull 全部逾時或解析不到；第二類則是兩邊間歇性輪流斷一下，關掉 Clash 或關掉 WSL 其中一邊就暫時恢復。

這類問題很少是「單純訂閱壞掉」那麼單純，反而經常落在預設路由被改寫、Hyper-V 相關虛擬介面的介面度量（InterfaceMetric）打架，或封包在虛擬交換與實體網卡之間帶著不合適的 MTU 被靜默丟棄。下面我們用「由外而內」的順序排查：先看 Windows 路由與度量，再看 WSL 內看到的閘道與 MTU，最後才回頭調 Clash 的分流與 TUN 行為。

若您尚未完成訂閱匯入，可先對照 全平台訂閱匯入教學，確保節點與 DNS 設定本身可用，再進行本篇的網路層排查，以免把「規則或 DNS 錯誤」誤判成路由問題。

WSL2 與宿主機之間，資料包實際怎麼走？

WSL2 並非傳統虛擬機裡「再插一張獨立網卡」那麼直觀，而是透過 Hyper-V 的虛擬交換與 NAT，把 Linux 子系統掛在名為「vEthernet (WSL)」或類似名稱的虛擬介面後面。宿主機上的預設閘道、度量、以及 Clash 是否建立 TUN／是否改寫系統路由，都會影響子系統看到的「下一跳」與路徑品質。

因此，當 Clash 以 TUN 接管部分流量時，Windows 的路由表可能出現指向 TUN 介面的條目；若同時存在 VPN、其他虛擬網卡或先前手動加過的靜態路由，哪一條路由的度量較小（優先序較高），就會主導實際轉送。WSL2 內部再經過一層轉發，任何一環 MTU 設得過大，都可能造成 TCP 握手看起來「卡住」、UDP DNS 查詢無回應等現象，表面卻像單純「沒網路」。

步驟一：在宿主機確認預設路由與閘道

請以系統管理員身分開啟 PowerShell 或命令提示字元，先看 IPv4 預設路由。傳統指令 route print 0.0.0.0 會列出目標 0.0.0.0 的項目：留意「網路目的地」「閘道」「介面」「度量」四欄。若 Clash TUN 啟用後，出現多條預設路由且度量接近，Windows 可能在不同介面間搖擺，外觀就是間歇斷線。

在 PowerShell 中，也可使用：

Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric, ifIndex

將輸出與「關閉 Clash TUN、僅保留系統代理」時對照：若差異主要出現在 TUN 相關介面，可先記下介面名稱與索引，供下一步調整度量或暫時停用衝突路由時使用。這一步的目的，是確認不是 WSL 自己壞掉，而是宿主機路由已經在打架。

步驟二：調整介面度量，避免虛擬網卡搶走預設路徑

Windows 會為每張網卡計算介面度量；數字越小越優先。實體 Wi-Fi 或有線網卡若度量反而大於某張 Clash／Hyper-V 虛擬介面，可能導致預設流量誤入虛擬路徑。您可以用：

Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Format-Table ifIndex,InterfaceAlias,InterfaceMetric,ConnectionState

若發現 vEthernet (WSL)、Clash 相關 TUN、或 Hyper-V 預設交換器的度量異常地低，可考慮在「網路介面內容 → IPv4 → 進階」裡，取消自動度量並為實體上網介面指定較小數字（例如 5），為次要或僅供內部轉發的介面指定較大數字（例如 50 以上）。實際數字可依環境微調，原則是真正對外的那張卡要贏過「只該處理子系統或本機轉送」的虛擬介面。

修改後建議重新啟動 WSL（見下一節），讓子系統重新取得與新路由一致的閘道資訊。

步驟三：在 WSL 內對照路由、DNS 與 MTU

在 Windows 側執行 wsl 進入預設發行版後，先檢視預設路由與 DNS：

ip route show default
ip link show eth0
cat /etc/resolv.conf

若 default 指向的閘道與宿主機上 ipconfig 所見的 WSL 虛擬網段不一致，或 resolv.conf 指向的 nameserver 在您的 Clash DNS 模式下無法連通，就會出現「解析得到 IP 但連不上」或「完全無法解析」。此時除了路由，也要對照 Clash 的 DNS 設定（例如 redir-host／fake-ip 與略過清單），必要時可暫時在 WSL 內用 dig @8.8.8.8 這類指令對照，縮小是 DNS 還是轉發層的問題。

MTU 方面，可在 WSL 內查看目前介面 MTU，並嘗試以較保守值測試（常見實驗值為 1280 或 1400，視環境而定）：

sudo ip link set dev eth0 mtu 1280

若調低 MTU 後，長網址的 HTTPS 與 apt update 明顯變穩，代表路徑上可能存在 PMTU black hole（路徑 MTU 探索失敗），可再回宿主機對對應的 vEthernet 介面做持久化 MTU 設定。Windows 上可使用（介面名稱請替換為實際別名）：

netsh interface ipv4 show subinterfaces
netsh interface ipv4 set subinterface "乙太網路" mtu=1400 store=persistent

請將範例中的介面名稱改成您環境中對外連線的那一張；對 WSL 虛擬介面調整時務必謹慎，錯誤介面可能反而中斷子系統通訊。建議每改一項就重啟 WSL 驗證。

步驟四：重啟 WSL 與選用的 .wslconfig

完成路由或 MTU 調整後，在 PowerShell 執行：

wsl --shutdown

再重新開啟 WSL，讓虛擬網卡與路由表全量重建。若您曾在使用者目錄下使用 .wslconfig 限制記憶體或網路模式，請一併確認未啟用與目前 Windows 版本不相容或實驗性選項；少數情況下，關閉不必要的自訂區段後，預設 NAT 行為反而最穩定。

步驟五：Clash 側與分流設定的務實調整

當宿主機路由與 MTU 大致正常後，再回到 Clash。若您主要使用系統代理，理論上 WSL2 內的程式預設不會自動走 Windows 的系統代理，仍會嘗試直接對外；此時若宿主機同時開著會改寫路由的 TUN，就容易出現「以為是代理問題、其實是路由」的混淆。建議在排查期間一次只改一種模式：先關 TUN、僅系統代理，或反之，觀察 WSL 行為是否跟著變。

在 Rule／分流模式下，請確認沒有過寬的規則提早把本機或區網流量導向錯誤策略；關於規則順序與 MATCH 兜底，可延伸閱讀 規則分流詳解。對開發者而言，常見需求是讓套件索引站、Git 主機、容器映像庫走穩定出口，其餘維持直連；這類需求應透過具體網域或 IP 規則完成，而不是把預設路由整張表交給實驗性選項。

Windows 桌面用戶端的細部開關（例如是否開啟 TUN、是否允許區域連線繞過）因分支而異，可搭配 Clash Verge Rev 完整教學對照您使用的介面名稱與權限提示，但核心原則不變：先讓作業系統路由合理，再談規則細修。

可列印檢查清單（建議順序）

• 症狀確認：宿主機瀏覽器與 WSL curl -I 是否一致失敗？僅 WSL 失敗時，優先看路由／MTU／DNS。
• 路由：route print 或 Get-NetRoute 是否有多條預設路由競爭？關閉 Clash TUN 後是否消失？
• 度量：Get-NetIPInterface 中實體卡是否優先於不相干的虛擬介面？
• WSL 內：ip route、/etc/resolv.conf 是否合理？調低 MTU 是否改善？
• 重啟子系統：wsl --shutdown 後重測。
• Clash 模式：系統代理與 TUN 分開驗證；分流規則是否誤傷區網或虛擬網段。

結語

Windows 11 上 Clash 與 WSL2 並存時的斷網，多半是路由優先順序、虛擬網卡度量與 MTU 疊加造成的路徑問題，而不是單靠重裝用戶端就能解決。依本篇順序先在宿主機收斂預設路由，再進 WSL 驗證 DNS 與 MTU，最後才微調分流與 TUN，通常能穩定重現「哪一環出錯」，也避免無效嘗試浪費時間。

相較於零散搜尋指令，使用持續更新的核心與可信設定來源，並搭配圖形用戶端備份組態，長期維護成本會低很多。若您希望從本站取得對應平台的用戶端與整理後的教學起點，可先前往下載頁選擇 Windows 版本，再依教學完成訂閱與模式切換。