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

What This Guide Covers in Depth

Windows 11 with WSL2 is a common developer stack. Add Clash or whichever you pick 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.

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.

Mechanically:The failure rarely calls for wiping your profile. It more often than not traces to stock route competition, virtual switch plumbing from Hyper-V, adapter front-end metrics, stale DNS inside the Linux namespace, or an MTU black hole once traffic is encapsulated twice.

Typical Symptoms and What They Imply Mechanically

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 front-end.

Write down three numbers from a good moment and a bad moment: the Windows stock gateway, the WSL stock 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 kick offs, you are debugging routing interaction, not rule semantics.

Both sides fail together suggests a broken stock 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 front-end metric reordering after sleep.

How WSL2 Networking Interacts With Windows Step by Step

WSL2 operates a trim 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.

More strictly: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 with no detour. 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 front-end and whether NAT or policy routing on the host drops them.

Anything that reshuffles stock 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.

Step 1: Establish a Baseline on Windows and Inside WSL Internals and Practice

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 stock gateway with the lowest metric. Inside WSL, operate ip route show default and ip addr.

At a different level:Also operate 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.

You want a not jumpy story: Linux it makes sense to point stock traffic at the pseudo-gateway that matches Microsoft’s design for your build, and that path it makes sense to still exist on the host.

Step 2: System Proxy Versus TUN—Different Failure Modes in Depth

System proxy mode steers applications that read WinINET or the system proxy key. Plenty 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.

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 stock route fights begin.

Thinking it through:If Clash publishes a stock 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 reasonably than stacking stale routes from three experiments.

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.

Step 3: Map Hyper-V and vEthernet Adapters Mechanically

Open ncpa.cpl and inventory adapters whose names mention vEthernet, WSL, or Hyper-V. Clash or Mihomo TUN adapters often appear alongside them.

If you operate 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.

First, a clarification: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.

Note which adapter is up, which owns the IPv4 stock route, and whether whichever you pick adapter shows “no internet” while still carrying traffic. Windows sometimes marks an front-end pessimistically even when TCP works; treat the routing table as ground truth, not only the status glyph.

Step 4: Front-end Metrics and Adapter Foremost Step by Step

Windows selects among multiple stock routes using route metrics. Lower numbers win.

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.

Mechanically:When hard-coding is the least bad toggle for a lab machine, document the change: future driver re-syncs love to reset metrics silently. Also verify you are not fighting a corporate MDM policy that reapplies metrics at login.

VPN and TUN stacks sometimes set deeply 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.

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

Symptoms that look like “no internet” are often DNS-only failures. From WSL, operate dig example.com or nslookup example.com and compare against curl -4 https://1.1.1.1 using a literal IP.

WSL generates /etc/resolv.conf from Windows name servers in most of of of 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.

More strictly: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.

If the IP literal works but names fail, fix name resolution before touching Clash rules.

Step 6: MTU, PMTUD, and the “Certain Sites Load” Pattern in Depth

Encapsulation lowers 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.

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 front-end or the WSL-related virtual adapter stabilizes transfers, you have a smoking gun.

At a different level: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.

The user-visible pattern is maddening: small JSON APIs succeed, image-heavy sites hang, git clone of big repos never finishes.

Step 7: When Clash Rules Matter for WSL Traffic Mechanically

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.

If you deliberately send only a subset of prefixes through the tunnel, verify that the rest still exit via a working front-end metric on Windows.

Thinking it through:A common mistake is tightening rules until stock traffic falls into a dead group whose outbound node is offline, which hurts WSL first because long-lived package downloads expose lag spikes browsers mask.

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.

Step 8: Sleep, Resume, and Fast Startup Step by Step

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 Internals and Practice

Use this order: confirm symptom class (proxy-only versus routing versus DNS versus MTU); compare Windows and WSL stock routes; inventory vEthernet and TUN adapters; review front-end 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 may roll back deliberately.

Closing Thoughts in Depth

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 stock route or which MTU setting cleared the black hole.

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

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.