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

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

在 Windows 11 上同时开 Clash（无论是仅系统代理，还是 TUN 虚拟网卡接管）并使用 WSL2 时，很多人会碰到两类反差极大的症状：第一类是资源管理器里 Edge 秒开，但 Ubuntu 里 apt update 一直卡住或解析失败；第二类是两边都能上，却周期性「断一下又恢复」，尤其在 SSH、git push、大文件下载时更明显。它们很少是「WSL 装坏了」或「必须重装 Clash」才能解决，更多来自 默认路由 变化、Hyper-V 虚拟网卡 与真实网卡的接口度量、以及叠加 VPN 式隧道后的 MTU / PMTU 问题。

本文目标是把排查拆成可照着做的步骤：先在 WSL 与 PowerShell 各看一遍路由与 DNS，再对照 Clash 是否改写了全局默认出口、是否把虚拟局域网误送进代理，最后处理 MTU 与可选的镜像网络、宿主机代理等架构级选项。若你刚接触桌面端安装与订阅，可先读 Clash Verge Rev 使用教程 把基础模式理清；需要理解 TUN 与规则的关系时，可对照 Clash TUN 模式指南，再回到本文处理 WSL2 并存场景。

先记住：WSL2 是独立网络栈，却依赖宿主的路由表

WSL2 运行在轻量虚拟机里，通过宿主侧的 Hyper-V 虚拟交换机与外界通信。对 Linux 发行版来说，它有自己的一张路由表和一块（或多块）虚拟网卡；但当 Clash 在宿主上添加默认路由、把流量导向 TUN 适配器，或修改接口度量让某张网卡「更优先」时，WSL2 侧看到的下一跳与 MTU 也会随之变化。于是出现「宿主浏览器走了系统代理一切正常，而 WSL 内仍按另一套默认路由尝试直连」的割裂；或者「两边都进了 TUN，但隧道 MTU 偏小导致大包静默失败」的间歇故障。

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

第零步：在 WSL 与 Windows 各打一张「路由快照」

在 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 一下哪张适配器成了新的默认出口，往往第一眼就能定位「被谁劫持」。

DNS 也要单独看：WSL2 默认会通过 /etc/resolv.conf 指向宿主解析器；若 Clash 在宿主侧启用了本地 DNS 监听或 fake-ip，而 WSL 仍指向旧的上游，会出现「IP 能 ping，域名全解析失败」。此时在 WSL 里 cat /etc/resolv.conf，对照宿主 Clash 的 DNS 入站端口与绕过列表，比盲目改 Linux 的 resolv.conf 更有效。

第一步：默认路由与接口度量（跃点数）

当 Clash 创建 TUN 适配器并插入一条低度量的默认路由时，WSL2 出网流量可能被导向该隧道；若隧道未正确转发、或策略组里对应节点暂时不可用，表现就是子系统「完全无网」。反过来，若 TUN 关闭、仅系统代理，而 WSL 内应用不读 Windows 代理设置，它们仍会尝试直连，若你的物理网络本身需要代理才能访问外网，则宿主「有代理所以正常」、WSL「无代理所以全红」。

处理思路分两支：若你希望 WSL 与宿主一致走 Clash，应确保默认路由确实指向 Clash 负责的接口，且该路径上 DNS 与分流规则覆盖 WSL 要访问的目标；若你希望 WSL 绕过 Clash 直连（例如仅宿主浏览器走代理），则需要在 Clash 规则或 TUN 排除列表里显式放行 WSL 虚拟网段，并避免把 172.x、192.168.x 等私网前缀误送入代理策略组。任何「一半直连一半进隧道」的半吊子状态，最容易触发间歇断线。

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

设备管理器与 Get-NetAdapter 中常见的 vEthernet (WSL)、Hyper-V Virtual Ethernet Adapter 等，是 WSL2 与宿主之间的桥梁。Clash TUN 也会多一张虚拟网卡。问题是：当多张虚拟网卡同时存在时，Windows 会按路由最长匹配 + 度量决定实际出口。若某次更新或手工改过度量，可能导致流量从错误的接口溜出去，或被防火墙 profile 当成「公用网络」而拦截。

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

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

系统代理主要影响遵循系统 WinHTTP/IE 代理栈的应用；常见桌面浏览器、部分微软商店应用会跟随，但 WSL 内的绝大多数 CLI 工具默认不使用该代理。于是最干净的方案之一，是在 WSL 里为需要翻墙的工具显式设置 HTTP_PROXY / HTTPS_PROXY 指向宿主的 Clash 混合端口（宿主 IP 可用 $(cat /etc/resolv.conf | awk '/nameserver/{print $2; exit}') 一类方式获取，视版本而定），或改用下面提到的镜像网络。

TUN 模式则在路由层接管，理论上可以让未感知代理的程序也走 Clash，但前提是默认路由与策略路由没有漏网之鱼，且 MTU、ICMP、DNS 环路都被处理干净。若 TUN 与某些公司 VPN 客户端同时抢默认路由，还会出现「谁后启动谁赢」的抖动。此时应固定启动顺序，或让其中一方配置拆分隧道（split tunnel），避免双默认路由打架。

第四步：MTU、PMTU 与大包「假死」

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

sudo ip link set dev eth0 mtu 1350

若症状立刻缓解，说明应把该值写进发行版启动脚本，或在宿主侧排查究竟是哪一段链路把 MTU 咬窄了。Windows 也可用 netsh interface ipv4 show subinterfaces 查看各接口 MTU。注意：盲目把全局 MTU 调得过低会影响局域网吞吐，建议只在确认 PMTU 黑穴存在时作为针对性补丁。

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

Clash 的 分流若把微软更新、WSL 资源下载域名、或你内网 Git 服务器的私网段误配进「代理」策略组，会出现「时好时坏」——节点一抖动，WSL 里依赖这些地址的命令就集体超时。请检查规则顶部是否有足够的 GEOIP cn / IP-CIDR / DOMAIN-SUFFIX 直连条目，并确保局域网与链路本地地址始终 DIRECT。对开发者常用场景，给 github.com、容器镜像站、包管理器 CDN 单独建策略组，比在全局里硬切「全局 / 规则」更稳。

这与「重装 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 与防火墙排查文。