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

What This Guide Covers Key Takeaways

This article is intentionally a troubleshooting checklist, not a repeat of generic “turn it off and on again” advice.

Windows 11 with WSL2 is a common developer stack. Add Clash or no matter which 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 as a rule traces to preconfigured 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.

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 in Brief

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

The key point: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.

Both sides fail together suggests a broken preconfigured 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.

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

How WSL2 Networking Interacts With Windows A Closer Look

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 straightforward. The exact flag names evolve; treat Microsoft’s current documentation as authoritative for your build number.

WSL2 works a slim 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.

Let me put it this way:Anything that reshuffles preconfigured 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.

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.

Step 1: Establish a Baseline on Windows and Inside WSL What Matters

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

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

Concretely:You want a trustworthy story: Linux are best off point preconfigured traffic at the pseudo-gateway that matches Microsoft’s design for your build, and that path are best off still exist on the host.

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 Key Takeaways

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

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

Where this lands:If Clash publishes a preconfigured 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 fairly than stacking stale routes from three experiments.

Step 3: Map Hyper-V and vEthernet Adapters in Brief

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

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 preconfigured route, and whether no matter which 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.

Do not skip this: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: Front end Metrics and Adapter Top billing A Closer Look

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.

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

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

The key point:When hard-coding is the least bad choice for a lab machine, document the change: future driver upgrades 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 What Matters

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

Symptoms that look like “no internet” are often DNS-only failures. From WSL, work 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.

Let me put it this way: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 “A fair few Sites Load” Pattern Key Takeaways

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.

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

Concretely: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 in Brief

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.

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.

Where this lands:A common mistake is tightening rules until preconfigured traffic falls into a dead group whose outbound node is offline, which hurts WSL first because long-lived package downloads expose response time spikes browsers mask.

Step 8: Sleep, Resume, and Fast Startup A Closer Look

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 What Matters

Use this order: confirm symptom class (proxy-only versus routing versus DNS versus MTU); compare Windows and WSL preconfigured 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 it is possible to roll back deliberately.

Closing Thoughts Key Takeaways

When you want a maintained installer and pointers without hunting scattered releases, spin up from one place.

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 preconfigured 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.

Do not skip this:→ Download Clash for free and experience the difference.