Why Clash TUN on Windows can take the whole machine offline

TUN mode installs a virtual network adapter and steers traffic through the Clash core (for example mihomo) according to your rules. That is powerful: applications that ignore system proxy settings still follow IP routing, so games, terminals, and background updaters behave more predictably than they do under HTTP proxy alone. The trade-off is surface area. When TUN comes up, Windows must install routes, allow the tunnel through Windows Defender Firewall, and coexist with anything else that thinks it owns the default gateway or DNS path. If any of those layers disagree, you do not get a polite error in one app—you often get no internet everywhere at once.

This article assumes you already imported a working profile and can reach nodes in another mode (for example system proxy or a browser-only extension). The failure begins when you flip to TUN or change routing mode. If that matches your story, work the steps in order; each one removes a common class of routing conflict before you touch deep packet inspection or obscure YAML keys. For installation context first, see Clash Verge Rev: Windows & macOS install and usage; for DNS and Fake-IP theory, pair this walkthrough with Clash YAML: routing rules, proxy groups, and Fake-IP.

Step 1: Label the failure and remove system proxy double capture

Start by writing down exactly what you toggled. Did you enable TUN while system proxy was still on? Some stacks tolerate both; others send traffic through two different expectations—OS proxy points at 127.0.0.1, while TUN rewrites routes—so connections stall or loop. In your Clash-compatible GUI, turn system proxy off, keep only TUN enabled, and apply. If the client merges those switches into one “mode,” pick the explicit TUN-only preset if one exists.

Next, confirm Windows still has a sane manual proxy dialog. Open Settings > Network & Internet > Proxy and verify you are not stacking a second manual proxy on top of TUN unless you intend to. Corporate MDM sometimes re-applies proxy PAC files every reboot; if a policy fight is suspected, test on a clean local account or briefly disconnect from domain policy (only if your workplace rules allow it).

Finally, close browsers that cache proxy state aggressively and retry a simple check: ping 1.1.1.1 and a DNS lookup you trust. If ICMP is blocked upstream, use curl or open a lightweight HTTPS site. You are not proving speed yet—only whether anything still moves when TUN is the only capture layer.

Step 2: Pause other VPNs, filters, and competing virtual adapters

Another commercial VPN, corporate always-on client, or filter driver often registers itself as the default interface with higher priority than Clash’s TUN adapter. Symptoms include TUN showing “connected” in the app while Windows still routes through the other product’s tunnel—or worse, through a half-removed tunnel with no working gateway.

Quit the other VPN cleanly from its own UI, not only from the tray. Then open ncpa.cpl (Run dialog) and scan the list of network adapters. You want one coherent path: your physical Wi-Fi or Ethernet, plus the Clash or mihomo virtual adapter when TUN is active. If you see stale “TAP” or “Wintun” entries from old tools, disable the ones you no longer use after you uninstall the parent software—orphan adapters occasionally keep routes pinned.

Hypervisors and some Android emulators also install virtual switches. They rarely break Clash, but when they do, it is usually because two stacks fight over the same subnet or metric. Temporarily disabling the extra bridge for testing is enough to confirm guilt.

Step 3: Service mode, elevation, and letting the TUN driver finish

On Windows, reliable TUN almost always depends on a service or helper with rights to create the adapter and bind filters. GUI clients such as Clash Verge Rev prompt for service mode on first run—accept it when policy allows. If you declined earlier, open the client settings and enable the service, then restart the application as a normal user (not perpetual Administrator). Running the whole desktop shell elevated is a poor substitute; it widens the attack surface without fixing driver registration.

If TUN fails to start, read the in-app log rather than guessing. Look for errors mentioning wintun, CreateFile, or access denied on device nodes. A reinstall of the client from our download page often restores the driver bundle; grabbing random DLLs from forums does not.

After any driver change, reboot once. Windows networking stacks cache more than users expect. A reboot is cheap compared to an hour of toggling YAML keys that were never the problem.

Step 4: Inspect routes, gateways, and interface metrics

When TUN is on but traffic dies, the routing table is a prime suspect. Open an elevated PowerShell or Command Prompt and run route print -4. You are looking for a sensible default route (0.0.0.0) with a gateway that matches your LAN router, and you want to understand which interface metric wins when multiple defaults exist.

Clash typically adds more specific routes or adjusts the default toward the tunnel; if your profile or rule set is too aggressive, you can accidentally steer domestic destinations through an exit that drops them, which feels like total outage on region-locked networks. Cross-check your YAML: domestic CDNs and local APIs should hit DIRECT rules before broad MATCH lines. If you recently imported a huge community rule set, remember that order matters—our YAML deep dive explains how top-down matching interacts with GEOIP.

IPv6 deserves a mention. If your network is dual-stack but your profile assumes IPv4-only exits, some apps prefer IPv6 paths and appear “offline.” You can test quickly by temporarily disabling IPv6 on the adapter (only for diagnosis) or by adding explicit IPv6 handling in your profile once you know the behavior. Do not leave IPv6 disabled forever without understanding the trade-offs.

Step 5: Windows Defender Firewall and private network trust

Firewall issues masquerade as routing problems. After TUN creates a new interface, Windows may classify it as Public, applying stricter rules to the Clash executable and helper service. Open Windows Security > Firewall & network protection > Allow an app through firewall, locate your Clash or Verge binaries and services, and ensure both private and public checkboxes match how you actually use the machine on untrusted Wi-Fi.

For a decisive test, temporarily set the active profile to “allow” for the Clash folder (narrow the scope to signed binaries you installed), then revert to a tighter posture once connectivity returns. Third-party endpoint suites layered on Defender can block filter drivers even when the stock UI looks open—if you run corporate antivirus, check its network component logs in parallel.

Do not confuse this with “opening ports inbound.” Clash usually initiates outbound connections; you are ensuring the engine and helper are not silently dropped as new apps on a fresh adapter.

Step 6: DNS, stack mode, and last-resort resets

If IP connectivity works but names fail, you are past pure routing—you are in resolver territory. TUN setups often steer DNS to Clash’s built-in resolver or to Fake-IP. Misaligned dns stanzas produce NXDOMAIN loops or timeouts that look like total blackout in browsers while raw IPs still answer ping. Tail the core log for DNS errors and compare with your dns and tun sections. Small mistakes—mixed redir-host versus fake-ip expectations—show up here first.

Some cores expose multiple stack implementations (system, gVisor, mixed). If you changed the stack for gaming or compatibility, roll back to the default for a sanity check. Stack modes interact with Windows filtering platforms in different ways; what helps one title can confuse another.

When all else fails, export your profile, uninstall the client, reboot, reinstall from the official download page, import the profile, and enable TUN once service mode is healthy. That sequence clears half-installed drivers without encouraging you to delete random registry keys.

For broader reference material beyond this Windows-focused rescue, bookmark the documentation hub—it pairs well with hands-on client guides.

Recovery checklist before you escalate

Walk through this compact list when you are tired: (1) TUN only, system proxy off unless you truly need both. (2) Other VPNs exited and adapters sane in ncpa.cpl. (3) Service mode enabled and logs clean on adapter creation. (4) route print shows expected defaults and metrics. (5) Firewall allows the Clash binaries on the active profile. (6) DNS and stack settings match how you browse—Fake-IP versus redir-host decided deliberately, not by accident.

If every box is green and packets still die, capture a short log snippet and your anonymized route table—community support can move faster with numbers than with screenshots of blank browsers.

Closing thoughts

Clash TUN on Windows is supposed to make life simpler: one ruleset, consistent capture, fewer apps sneaking past a manual proxy. When it misfires, the fix is usually operational—who owns the default route, which firewall profile applies, whether another tunnel got there first—not a mystery bug in your subscription. Work the six steps calmly, prefer evidence from logs and route print over random YAML churn, and keep a known-good profile backup before you experiment.

Compared with ad hoc scripts, maintained desktop clients bundle the service pieces and driver updates most people need for stable TUN. When you are ready to align your installer with the guides you just read, start from the download page so builds and documentation stay in sync. → Download Clash for free and experience the difference.