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

What This Guide Covers Demystified

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.

Windows 11 with WSL2 is a common developer stack. Add Clash or whichever 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 typically traces to out of the box route competition, virtual switch plumbing from Hyper-V, adapter UI 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.

Typical Symptoms and What They Imply at a Glance

When those three diverge only after Clash launchs, you are debugging routing interaction, not rule semantics.

One more angle: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 UI.

Both sides fail together suggests a broken out of the box 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 UI metric reordering after sleep.

Write down three numbers from a good moment and a bad moment: the Windows out of the box gateway, the WSL out of the box gateway as seen from ip route, and the first hop RTT from each side to a well-known resolver.

How WSL2 Networking Interacts With Windows Broken Down

The troubleshooting mindset stays the same: identify whether Linux packets leave through the intended Windows UI and whether NAT or policy routing on the host drops them.

WSL2 executes a lean 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.

A detail worth adding:Anything that reshuffles out of the box 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 straight away. The exact flag names evolve; treat Microsoft’s current documentation as authoritative for your build number.

Step 1: Establish a Baseline on Windows and Inside WSL From the Ground Up

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.

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 out of the box gateway with the lowest metric. Inside WSL, execute ip route show default and ip addr.

Said differently:You want a steady story: Linux ought to point out of the box traffic at the pseudo-gateway that matches Microsoft’s design for your build, and that path ought to still exist on the host.

Also execute 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.

Step 2: System Proxy Versus TUN—Different Failure Modes Demystified

If Clash publishes a out of the box 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 somewhat than stacking stale routes from three experiments.

System proxy mode steers applications that read WinINET or the system proxy key. Numerous 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 out of the box route fights begin.

Step 3: Map Hyper-V and vEthernet Adapters at a Glance

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.

In practice that means: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 out of the box route, and whether whichever adapter shows “no internet” while still carrying traffic. Windows sometimes marks an UI pessimistically even when TCP works; treat the routing table as ground truth, not only the status glyph.

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

Step 4: UI Metrics and Adapter First choice Broken Down

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

Worth noting:Windows selects among multiple out of the box routes using route metrics. Lower numbers win.

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

Step 5: DNS Inside WSL—resolv.conf and systemd-resolved From the Ground Up

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.

One more angle:Symptoms that look like “no internet” are often DNS-only failures. From WSL, execute 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 the majority 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.

Step 6: MTU, PMTUD, and the “A number of Sites Load” Pattern Demystified

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.

A detail worth adding:Encapsulation cut downs 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 UI or the WSL-related virtual adapter stabilizes transfers, you have a smoking gun.

Step 7: When Clash Rules Matter for WSL Traffic at a Glance

A common mistake is tightening rules until out of the box traffic falls into a dead group whose outbound node is offline, which hurts WSL first because long-lived package downloads expose delay spikes browsers mask.

Said differently: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 UI metric on Windows.

Step 8: Sleep, Resume, and Fast Startup Broken Down

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.

In practice that means: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 From the Ground Up

Use this order: confirm symptom class (proxy-only versus routing versus DNS versus MTU); compare Windows and WSL out of the box routes; inventory vEthernet and TUN adapters; review UI 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 are able to roll back deliberately.

Closing Thoughts Demystified

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

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 out of the box 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.