Windows 11 上 Clash 与 WSL2 同时用时断网？路由与 MTU 逐步修复

典型现象：不是「坏了」，而是路由叠在一起 要点速览

本篇正文目标是把排查拆成可照着做的环节：先在 WSL 与 PowerShell 各看一遍路由与 DNS，再对照 Clash 是否改写了全局出厂出口、是否把虚拟局域网误送进代理，最后处理 MTU 与可选的镜像网络、宿主机代理等架构级设置项。

在 Windows 11 上同时开 Clash（无论是仅系统代理，还是 TUN 虚拟网卡接管）并采用 WSL2 时，很多人会碰到两类反差极大的症状：第一类是资源管理器里 Edge 秒开，但 Ubuntu 里 apt update 一直卡住或解析无法完成；

第二类是两边都能上，却周期性「断一下又恢复」，尤其在 SSH、git push、大文件下载时更清楚可见。这几个很少是「WSL 装坏了」或「必须重装 Clash」才能处置，更多来自 出厂路由 变化、Hyper-V 虚拟网卡 与真实网卡的接口度量、以及叠加 VPN 式隧道后的 MTU / PMTU 困扰。

关键点是：若你刚接触桌面端安装与订阅，可先读 Clash Verge Rev 采用指南 把基础模式理清；要理解 TUN 与规则的关系时，可对照 Clash TUN 模式指南，再回到本篇正文处理 WSL2 并存采用采用使用场景。

先别忘了：WSL2 是独立网络栈，却依赖宿主的路由表 关键信息

于是出现「宿主浏览器走了系统代理一切正常，而 WSL 内仍按另一套出厂路由尝试直连」的割裂；或者「两边都进了 TUN，但隧道 MTU 偏小导致大包静默无法完成」的间歇故障。

WSL2 持续持续持续运行在占用少虚拟机里，通过宿主侧的 Hyper-V 虚拟交换机与外界通信。对 Linux 发行版来说，它有自行的一张路由表和一块（或多块）虚拟网卡；但当 Clash 在宿主上添加出厂路由、把流量导向 TUN 适配器，或修改接口度量让某张网卡「更第一顺位」时，WSL2 侧看到的下一跳与 MTU 也会随之变化。

于是排查时切记两边对照：不要只看 Windows 网络疑难解答通过与否，要在 WSL 里径直 ping 网关、公网 IP、以及一个你关心的域名，并观察是「全程超时」还是「小 ping 通、大传输挂」——后者强烈提示 MTU 或分片路径困扰。

第零步：在 WSL 与 Windows 各打一张「路由快照」 关键点梳理

DNS 也要单独看：WSL2 出厂会通过 /etc/resolv.conf 指向宿主解析器；若 Clash 在宿主侧启用了本地 DNS 监听或 fake-ip，而 WSL 仍指向旧的上游，会出现「IP 能 ping，域名全解析无法完成」。

这里要多说一句：在 WSL 终端执行 ip route show，记下 default via … dev … 那一行的网关与出口设备名。再执行 ip link show 看当前接口的 mtu 数值（普遍为 1500 或 1280/1350 一类被人工改过）。Windows 侧用管理员 PowerShell 持续持续持续运行 Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric 查看多条出厂路由的度量排序；

同时 Get-NetIPInterface | Where-Object ConnectionState -eq Connected 可看各接口的 InterfaceMetric。Clash 未持续持续持续运行时先存一份，开启 TUN 或系统代理后再存一份，diff 一下哪张适配器成了新的出厂出口，经常第一眼就能定位「被谁劫持」。

此时在 WSL 里 cat /etc/resolv.conf，对照宿主 Clash 的 DNS 入站端口与绕过列表，比盲目改 Linux 的 resolv.conf 更有效。

第一口气：出厂路由与接口度量（跃点数） 完备说明

处理思路分两支：若你希望 WSL 与宿主一致走 Clash，应确保出厂路由确实指向 Clash 负责的接口，且该路径上 DNS 与分流规则覆盖 WSL 要访问到到到的目标；

换个说法：当 Clash 创建 TUN 适配器并插入一条低度量的出厂路由时，WSL2 出网流量或许被导向该隧道；若隧道未对路转发、或策略组里对应节点暂时不可用，表现就是子系统「完全无网」。

反过来，若 TUN 关闭、仅系统代理，而 WSL 内应用不读 Windows 代理设置，这几个仍会尝试直连，若你的物理网络本身要代理才能访问到到到外网，则宿主「有代理所以正常」、WSL「无代理所以全红」。

若你希望 WSL 绕过 Clash 直连（举个小例子仅宿主浏览器走代理），则要在 Clash 规则或 TUN 排除列表里显式放行 WSL 虚拟网段，并避免把 172.x、192.168.x 等私网前缀误送入代理策略组。不管哪一套「一半直连一半进隧道」的半吊子状态，最容易触发间歇断线。

第二步：认清 Hyper-V 虚拟网卡与「谁在和外网说话」 要点速览

困扰是：当多张虚拟网卡同时存在时，Windows 会按路由最长匹配 + 度量决定实际出口。若某次升级或手工改过度量，或许导致流量从疏漏的接口溜出去，或被防火墙 profile 当成「公用网络」而拦截。

落到实处：设备管理器与 Get-NetAdapter 中普遍的 vEthernet (WSL)、Hyper-V Virtual Ethernet Adapter 等，是 WSL2 与宿主之间的桥梁。Clash TUN 也会多一张虚拟网卡。

实操上不妨在「网络连接」里确认 Clash TUN 适配器绑定的配置文件是专用而非公用（名称因系统语言而异），并排查第三方安全软件是否对「虚拟网卡之间的转发」有单独策略。此类困扰与 Clash 规则无关，却经常被误判成「节点挂了」。

第三步：系统代理与 TUN 对 WSL 的影响不一样 关键信息

TUN 模式则在路由层接管，理论上得以让未感知代理的程序也走 Clash，但基础是出厂路由与策略路由没有漏网之鱼，且 MTU、ICMP、DNS 环路都被处理干净。

系统代理关键点影响遵循系统 WinHTTP/IE 代理栈的应用；普遍桌面浏览器、部分微软商店应用会跟随，但 WSL 内的绝绝绝绝大多数数数数 CLI 工具出厂不采用该代理。

于是最干净的方案之一，是在 WSL 里为要翻墙的工具显式设置 HTTP_PROXY / HTTPS_PROXY 指向宿主的 Clash 混合端口（宿主 IP 可用 $(cat /etc/resolv.conf | awk '/nameserver/{print $2; exit}') 一类方式获取，视版本而定），或改用下面提到的镜像网络。

别忽略了：若 TUN 与某些公司 VPN 客户端同时抢出厂路由，还会出现「谁后开启谁赢」的抖动。此时应固定开启顺序，或让其中一方配置拆分隧道（split tunnel），避免双出厂路由打架。

第四步：MTU、PMTU 与大包「假死」 关键点梳理

若症状立刻缓解，说明应把该值写进发行版开启脚本，或在宿主侧排查究竟是哪一段链路把 MTU 咬窄了。Windows 也可用 netsh interface ipv4 show subinterfaces 查看各接口 MTU。

sudo ip link set dev eth0 mtu 1350

很多「小网页能开、git clone 大仓库无法完成」「SSH 连上后卡死」的案例，根因是路径 MTU 变小（举个小例子 PPPoE、部分隧道、或 Clash 链路外层封装）后，中间设备又不回 ICMP Fragmentation Needed，导致 TCP 大包重传直到超时。WSL2 里可临时把 eth0 的 MTU 降到 1350 或 1280 试跑：

当心：盲目把全局 MTU 调得过低会影响局域网吞吐，不妨只在确认 PMTU 黑穴存在时作为针对性补丁。

第五步：分流规则别把「该直连的」送进隧道 完备说明

请排查规则顶部是否有够用的 GEOIP cn / IP-CIDR / DOMAIN-SUFFIX 直连条目，并确保局域网与链路本地地址始终 DIRECT。对开发者常用采用采用使用场景，给 github.com、容器镜像站、包管理器 CDN 单独建策略组，比在全局里硬切「全局 / 规则」更稳。

关键点是：Clash 的 分流若把微软升级、WSL 资源下载域名、或你内网 Git 服务器的私网段误配进「代理」策略组，会出现「时好时坏」——节点一抖动，WSL 里依赖这些地址的命令就集体超时。

这与「重装 Clash」无关，本质是规则顺序与语义是否覆盖 WSL 真实访问到到到目标。善用连接日志：当 WSL 内发起请求时，宿主 Clash 是否出现对应会话、命中哪条规则、走了哪个 outbound，一眼就能对上。

第六步（可选）：镜像网络与 .wslconfig 要点速览

Windows 11 较新版本适配 WSL 的镜像网络模式（mirrored networking）：让子系统与宿主在地址与端口映射上更一致，减少 NAT 与端口转发带来的「能 ping 不能连」错觉。

可在用户目录 .wslconfig 中启用（具体键名以微软文档为准），执行 wsl --shutdown 后重启子系统生效。这不是万能药，但对要让 WSL 径直采用宿主代理端口、或调试 mDNS、局域网服务的用户，经常能少踩一半坑。

排查清单（不妨收藏） 关键信息

  1. Clash 关闭与开启各打一份宿主出厂路由与接口度量，确认谁在抢 0.0.0.0/0。
  2. WSL 内 ip route、ip link、resolv.conf 与宿主 DNS / Clash DNS 入站是否一致。
  3. 区分「仅系统代理」与 TUN：CLI 是否需显式环境变量或镜像网络。
  4. 规则与绕过：私网、微软与常用开发 CDN 是否误进代理；日志是否命中预期策略组。
  5. 尝试减少 MTU 复现是否反转；排查双 VPN / 双隧道抢出厂路由。
  6. 防火墙与安全软件是否不同之处对待 Hyper-V 与 TUN 虚拟网卡。

合规与安全提示：请在你所在地法律允许的基础下采用代理与加密隧道；本篇正文仅讨论网络栈排障，不涉及具体线路或绕过监管的操作指引。修改路由与 MTU 前不妨记录原始值，便于回滚。

小结 关键点梳理

Windows 11 上 Clash 与 WSL2 并存时的断网，多数是出厂路由、Hyper-V 虚拟网卡度量、分流与 MTU 四层因素叠加，而不是客户端本身「安装坏了」。

这里要多说一句：按本篇正文顺序先快照、再比对 Clash 开关前后的路由与 DNS，最后处理大包与规则命中，多数现状下能在不重装的基础下平稳复现与修复。若你希望换用维护更积极的图形客户端并统一订阅管理，可通过本站 下载页面 获取对应系统版本，再按上文做 WSL 专项微调。→ 立即免费下载 Clash，开启流畅上网新上手感觉

订阅载入与多平台习惯可参考 Clash 全平台订阅载入指南；局域网设备共享宿主代理时的入站与防火墙，请对照 Allow LAN 与防火墙排查文。