Fix Clash and WSL2 Breakage on Windows 11: Routing and MTU Steps

What This Guide Covers

Windows 11 with WSL2 is a common developer stack. Add Clash or any Mihomo-based GUI in system proxy mode or with TUN enabled, and you may see a frustrating split: Edge or Chrome on the host works, apt or curl inside Ubuntu on WSL reports timeouts, or both environments alternate between healthy and broken every few minutes. The failure rarely calls for wiping your profile. It usually traces to default route competition, virtual switch plumbing from Hyper-V, adapter interface metrics, stale DNS inside the Linux namespace, or an MTU black hole once traffic is encapsulated twice.

This article is intentionally a troubleshooting checklist, not a repeat of generic “turn it off and on again” advice. It complements our Clash Verge Rev on Windows and macOS tutorial and the Clash TUN mode guide, which explain how to enable features; here we focus on coexistence with WSL2. If you still need subscription basics first, see how to add Clash subscription links across platforms.

Typical Symptoms and What They Imply

Before changing YAML, classify the symptom. Host browsers work, WSL has no path often means the Windows user session honors the system proxy while the Linux network namespace does not, or WSL traffic is routed through an adapter whose gateway disappeared when Clash inserted a virtual interface. Both sides fail together suggests a broken default route on Windows itself, a DNS loop, or an upstream node issue—not WSL specifically. Small packets work, large transfers hang is the classic fingerprint of MTU or PMTUD failure on a nested tunnel. Intermittent flapping can track with DHCP renewals, VPN handshakes, or interface metric reordering after sleep.

Write down three numbers from a good moment and a bad moment: the Windows default gateway, the WSL default gateway as seen from ip route, and the first hop RTT from each side to a well-known resolver. When those three diverge only after Clash starts, you are debugging routing interaction, not rule semantics.

How WSL2 Networking Interacts With Windows

WSL2 runs a lightweight utility VM. Traffic from Linux crosses a virtual NIC that Windows exposes through the Hyper-V virtual switch. That design is why WSL2 behaves more like a separate machine than WSL1 ever did. Anything that reshuffles default routes on Windows—corporate VPN clients, Docker Desktop, third-party filters, or a Clash TUN adapter—can change which gateway the virtual switch expects without the Linux side receiving a coherent story.

Recent Windows 11 builds also offer optional mirrored or networkingMode settings in .wslconfig that alter whether WSL shares the host’s view of adapters more directly. The exact flag names evolve; treat Microsoft’s current documentation as authoritative for your build number. The troubleshooting mindset stays the same: identify whether Linux packets leave through the intended Windows interface and whether NAT or policy routing on the host drops them.

Step 1: Establish a Baseline on Windows and Inside WSL

On Windows, open PowerShell as your normal user and capture Get-NetIPConfiguration for the active adapters, or the classic route print 0.0.0.0 and note the default gateway with the lowest metric. Inside WSL, run ip route show default and ip addr. You want a stable story: Linux should point default traffic at the pseudo-gateway that matches Microsoft’s design for your build, and that path should still exist on the host.

Also run ping -c 3 1.1.1.1 from WSL and Test-NetConnection 1.1.1.1 on Windows. If ICMP succeeds on Windows but not in WSL, you are not done with routing. If both fail, pause WSL-specific theories and verify Clash itself has a working uplink and that you are not blocking ICMP blindly on a middlebox.

Step 2: System Proxy Versus TUN—Different Failure Modes

System proxy mode steers applications that read WinINET or the system proxy key. Many Windows Store and desktop apps respect it. WSL2 processes generally do not inherit that setting. If your only Clash mode is system proxy, it is completely expected that Firefox on Windows works while curl https://example.com in WSL goes direct or stalls on a corporate firewall. Fixes include running a local HTTP or SOCKS listener bound to the LAN side of the WSL virtual network and pointing http_proxy variables at it, or switching to TUN so routing happens at the IP layer for both worlds—each approach has trade-offs.

TUN mode installs a virtual adapter and manipulates routes so selected prefixes traverse the tunnel. That can unify host and WSL behavior when configured correctly, but it is also where default route fights begin. If Clash publishes a default route with an aggressive metric, it may starve the physical adapter temporarily during handshake, or conversely fail to reinsert routes after resume from sleep. When you toggle modes, reboot once cleanly and re-measure rather than stacking stale routes from three experiments.

Step 3: Map Hyper-V and vEthernet Adapters

Open ncpa.cpl and inventory adapters whose names mention vEthernet, WSL, or Hyper-V. Clash or Mihomo TUN adapters often appear alongside them. Note which adapter is up, which owns the IPv4 default route, and whether any adapter shows “no internet” while still carrying traffic. Windows sometimes marks an interface pessimistically even when TCP works; treat the routing table as ground truth, not only the status glyph.

If you run Docker Desktop or other Hyper-V consumers, expect additional virtual switches. The goal is not to remove them blindly but to understand which gateway WSL-bound packets hit first. Misconfigured bridge or internal switch types have caused “WSL only” outages in the field; comparing against a machine with Docker stopped can isolate that class of bug quickly.

Step 4: Interface Metrics and Adapter Priority

Windows selects among multiple default routes using route metrics. Lower numbers win. VPN and TUN stacks sometimes set very low metrics to ensure capture, which is fine until a virtual adapter with no usable upstream steals precedence from your Wi-Fi or Ethernet NIC. Use Get-NetIPInterface | Sort-Object InterfaceMetric in PowerShell to view the ordering.

If you must adjust, prefer narrowing the scope of Clash routes—splitting only the prefixes you truly need through the tunnel—over permanently hard-coding metric hacks. When hard-coding is the least bad option for a lab machine, document the change: future driver updates love to reset metrics silently. Also verify you are not fighting a corporate MDM policy that reapplies metrics at login.

Step 5: DNS Inside WSL—resolv.conf and systemd-resolved

Symptoms that look like “no internet” are often DNS-only failures. From WSL, run dig example.com or nslookup example.com and compare against curl -4 https://1.1.1.1 using a literal IP. If the IP literal works but names fail, fix name resolution before touching Clash rules.

WSL generates /etc/resolv.conf from Windows name servers in most setups. A Clash fake-ip DNS mode on Windows can leak confusing addresses into that path if the Windows resolver returns synthetic answers that Linux misinterprets. Align Clash DNS mode with what your distro expects: sometimes switching to redir-host style resolution for local diagnostics clarifies the issue, even if you return to fake-ip later for daily driving. If you maintain a custom resolv.conf, ensure generateResolvConf = false in wsl.conf and accept the maintenance burden.

Step 6: MTU, PMTUD, and the “Some Sites Load” Pattern

Encapsulation reduces the effective maximum transmission unit. WSL2 already adds overhead; stacking Clash TUN, a corporate VPN, or PPPoE on the same machine can push you into territory where TCP SYNs succeed but large TLS records stall. The user-visible pattern is maddening: small JSON APIs succeed, image-heavy sites hang, git clone of big repos never finishes.

From WSL, test with ping -M do -s 1300 1.1.1.1 (Linux) adjusting sizes, or trace path MTU discovery failures. If lowering MTU on the Clash tunnel interface or the WSL-related virtual adapter stabilizes transfers, you have a smoking gun. Common trial values are 1400, 1350, or 1280 bytes on problematic Wi-Fi or double-NAT paths. Prefer fixing the underlying middlebox when you control it; MTU tweaks are a pragmatic bridge when you do not.

Step 7: When Clash Rules Matter for WSL Traffic

After routing, DNS, and MTU look sane, return to split routing in Clash. WSL traffic sourced from the virtual network appears as ordinary forwarded flows on the host. GEOIP or PROCESS rules that keyed only on browser PIDs will not classify Linux workloads the way you expect. Broaden tests using domain rules for the hosts your WSL session actually hits—package mirrors, Git remotes, container registries—and place them ahead of catch-all DIRECT or PROXY lines in first-match profiles.

If you deliberately send only a subset of prefixes through the tunnel, verify that the rest still exit via a working interface metric on Windows. A common mistake is tightening rules until default traffic falls into a dead group whose outbound node is offline, which hurts WSL first because long-lived package downloads expose latency spikes browsers mask.

Step 8: Sleep, Resume, and Fast Startup

Laptops accumulate ghost states. Fast Startup can leave networking stacks half-hibernated while Clash believes TUN is up. After major changes, do one cold reboot with Fast Startup disabled for the test, then re-enable if you prefer. If issues appear only after resume, script a post-resume restart of the Mihomo core or the GUI service. That is a workaround, not a root fix, but it narrows the bug to power management interaction.

Copy-Paste Checklist

Use this order: confirm symptom class (proxy-only versus routing versus DNS versus MTU); compare Windows and WSL default routes; inventory vEthernet and TUN adapters; review interface metrics; test literal IP reachability versus name resolution; probe MTU if large transfers fail; validate Clash rule order for real WSL destinations; retest after a clean reboot. Document metrics before and after each change so you can roll back deliberately.

Closing Thoughts

Clash on Windows 11 next to WSL2 is workable once you treat the pair as a small network topology problem. Reinstalling the client rarely teaches you which virtual adapter stole the default route or which MTU setting cleared the black hole. Compared with endlessly tweaking unrelated YAML, measuring gateways and packet sizes returns control quickly—and keeps your split rules meaningful because traffic actually reaches the core.

When you want a maintained installer and pointers without hunting scattered releases, start from one place. → Download Clash for free and experience the difference.