What TUN Mode Does in Clash Verge Rev
Clash Verge Rev TUN mode creates a virtual network interface on Windows and lets the Mihomo core capture traffic at the IP layer. That is different from ordinary system proxy mode. A system proxy changes the HTTP and HTTPS settings that cooperating applications read, while TUN mode gives Clash a path to handle connections from programs that never look at Windows proxy settings.
This distinction matters when you use terminals, game launchers, desktop messaging clients, development tools, virtual machines, or applications with their own networking stack. A browser may work immediately after you enable the Windows proxy, but git, Docker Desktop, a game updater, or an Electron application may continue to connect directly. TUN mode is designed for this wider coverage because traffic is redirected through a virtual adapter before the application needs to understand proxy environment variables.
The feature does not automatically make every connection use a proxy. Mihomo still evaluates DNS behaviour, routing rules, proxy groups, and DIRECT decisions. If your profile deliberately sends a destination directly, TUN mode will not override that rule. Think of TUN as the capture layer and your profile as the decision layer: the first determines which traffic reaches Clash, and the second determines what Clash does with it.
On Windows 10 and Windows 11, the most common setup problems are not caused by the subscription itself. They usually come from missing administrator permission, a disabled service helper, another VPN owning the virtual adapter, incorrect DNS settings, or two applications trying to install competing packet-capture components. This guide walks through a clean setup and includes checks for confirming that TUN is really active rather than merely showing an enabled toggle.
TUN is not a node or protocol. It does not improve a slow server by itself and it does not replace a valid subscription. You still need an active Mihomo-compatible profile, a reachable proxy group, and rules that match the traffic you want to route.
Prepare Windows and the Active Profile
Before changing network settings, close other proxy clients and VPN applications. Examples include older Clash for Windows installations, commercial VPNs, WireGuard tunnels, Wintun-based tools, transparent proxy utilities, and corporate security agents. Multiple programs can coexist in some advanced configurations, but that is not a sensible starting point for troubleshooting. If another service owns the default route or continually recreates a virtual adapter, Clash Verge Rev may appear to enable TUN while packets still follow a different path.
Confirm that Clash Verge Rev is installed from a source you trust and that the application is current enough to include a working Mihomo core. The interface names can vary between releases, so you may see labels such as Settings, General, System, or Experimental. The important controls are usually grouped around TUN, service mode, DNS, and the selected core.
Next, import or update your subscription and activate a profile. A profile that only contains outdated legacy fields may load in the interface but fail to provide the DNS or TUN-related options expected by a modern Mihomo build. Open the profile preview or editor and check that it contains familiar sections such as proxies, proxy-groups, and rules. You do not need to rewrite the entire YAML file for a first test, but you should know which proxy group is the default choice and whether the profile includes a rule that sends most destinations to DIRECT.
It is also useful to record the current state before making changes. Open Windows Settings and note whether a VPN is connected, whether a manual proxy is enabled, and which network adapter is currently used for internet access. In PowerShell, the following commands can help you inspect the route and adapter list:
Get-NetAdapter
Get-NetIPConfiguration
Get-NetRoute -DestinationPrefix "0.0.0.0/0"
You do not need to interpret every line. The purpose is to create a baseline. If internet access breaks after enabling TUN, you can compare the default route, adapter status, and DNS configuration instead of guessing.
Step-by-Step: Enable TUN Mode
The exact wording may differ slightly between Clash Verge Rev builds, but the sequence below reflects the practical order that avoids most permission and profile mistakes.
- Launch Clash Verge Rev with permission to install its helper. Start the application normally first. If Windows displays an administrator approval prompt, accept it only when you initiated the action and the publisher information looks correct. Some releases install or start a service helper for operations that require elevated privileges.
- Open the settings page. Look for a section named Settings, General, or System, then locate the networking area. Find the control labelled TUN Mode, Enable TUN, or a similar phrase. Do not confuse it with the separate system proxy switch.
- Install or enable service mode when requested. If the TUN control is greyed out, the application may need its service helper installed. Click the service-mode installation button and approve the Windows UAC prompt. Wait for the status to change to installed or running before returning to the TUN switch.
- Enable TUN mode. Turn on the TUN option and allow Clash Verge Rev to create its virtual adapter. The first activation can take several seconds. A Windows network notification, a new adapter in Network Connections, or a status message inside the client may appear during this step.
- Review the TUN implementation options. If the build exposes a stack choice such as
system,gvisor, ormixed, begin with the default recommended by the application. Change only one option at a time. A stack change can affect UDP, DNS, game traffic, and compatibility with security software. - Check DNS handling. If the settings page offers TUN DNS hijacking, enhanced mode, or fake-IP mode, leave the profile’s documented default in place for the first test. Avoid combining several independent DNS redirect tools. A DNS leak or resolution loop can look like a TUN failure even when packet capture is working.
- Apply the settings and restart only if necessary. Some versions activate immediately; others require a core restart or application restart. After restarting, confirm that both the profile and the TUN status are still enabled. A restart that leaves the profile inactive can make a successful TUN setup appear broken.
After activation, open the Windows adapter list by pressing Win + R, entering ncpa.cpl, and pressing Enter. Look for an adapter associated with Clash, Mihomo, or a TUN implementation. The exact name depends on the client version and driver. It may not show a normal Wi-Fi icon, and it may display a generic description, so do not judge it solely by the label. What matters is that the adapter exists, is enabled, and appears or changes state when TUN is toggled.
Permission tip: If the TUN switch turns itself off immediately, restart Clash Verge Rev as administrator once and try again. If that fixes the problem, inspect the service helper installation rather than permanently running every desktop application with elevated privileges.
Verify That TUN Is Capturing Traffic
A green toggle is not enough proof. The most reliable confirmation combines the Clash connection view, a controlled command-line test, and a comparison with system proxy mode. Start by selecting a known working proxy group in the active profile. Then open the client’s connections or traffic log and clear the existing entries so that your next test is easy to identify.
Use a browser to visit a simple HTTPS site, then open PowerShell and test a destination that normally does not read the Windows proxy setting:
curl.exe -I https://example.com
Test-NetConnection example.com -Port 443
The first command creates an HTTP request through the Windows command-line executable. The second checks TCP reachability and may behave differently because it is a lower-level test. Watch the Clash connection list while running both commands. You should see the destination hostname or resolved address, the matched rule, the selected proxy group, and the final outbound. If the browser creates entries but the command-line test never appears, system proxy mode may be working while TUN capture is not.
For a more realistic check, test an application that previously bypassed Clash. Run a small git operation against a repository host, open a desktop messenger, or launch a tool that does not support manual proxy configuration. Do not use a large download as your first test. A small request makes it easier to distinguish routing failure from a slow node, certificate inspection, rate limiting, or an application-specific issue.
DNS deserves a separate check. In fake-IP or enhanced DNS configurations, the connection log may show synthetic addresses while the rule matcher still displays the original hostname. That can be normal. The important questions are whether the request appears in the Clash log, whether the intended rule wins, and whether the selected outbound remains stable. If a domain repeatedly resolves but never establishes a connection, inspect the DNS mode and the rule order before disabling TUN.
Compare the result with and without TUN. First disable TUN while leaving the system proxy enabled, then repeat the same command. Re-enable TUN and repeat it again. This controlled comparison tells you whether the application relies on the virtual adapter. It also prevents a common mistake: assuming that a browser success proves system-wide capture when the browser was simply obeying the ordinary proxy listener.
Handle Adapter, VPN, and Routing Conflicts
If internet access stops immediately after TUN activation, do not keep switching random settings. Disable TUN first, wait for the normal route to return, and determine whether the failure affects every destination or only selected domains. If normal access returns, the issue is probably related to the virtual adapter, DNS interception, rule selection, or a competing network filter.
Common conflicts include a second VPN that installs its own default route, antivirus software blocking driver installation, Hyper-V or VMware virtual switches, and a stale TUN adapter left behind by an older client. Corporate laptops may also use endpoint protection that prevents unsigned or unapproved network services from opening. In that environment, the correct solution may require an administrator or an allowlist from IT; repeatedly reinstalling the client will not bypass company policy.
- Adapter appears disabled: open
ncpa.cpl, enable the Clash or Mihomo adapter, and restart the helper service if the client provides a service control. - TUN activates but DNS fails: return DNS settings to the profile’s default, remove duplicate DNS redirect utilities, and test one resolver strategy at a time.
- Only local devices fail: check whether LAN access is disabled by the profile. Options such as
auto-route,strict-route, and bypass rules can change access to printers, NAS devices, and router panels. - VPN stops working: do not run two full-tunnel systems simultaneously during diagnosis. Test the VPN alone, Clash alone, and then a documented compatible combination.
- Everything is slow: inspect the selected proxy group and connection log. TUN capture adds a routing layer, but it does not normally explain severe latency when the same node is fast in ordinary proxy mode.
Windows can also retain old virtual adapters after uninstalling networking software. Removing devices blindly from Device Manager is risky because a similarly named adapter may belong to Hyper-V, a VPN, or a corporate tool. Record the adapter name first, uninstall only the clearly obsolete component, reboot, and then install the current helper through Clash Verge Rev. If the client reports a driver error, check Windows Security, third-party antivirus quarantine, and Event Viewer rather than downloading an unrelated driver package.
Do not expose the control API. TUN mode does not require publishing Mihomo’s external controller to the internet. Keep the controller bound to localhost unless you understand authentication, firewall rules, and remote access implications. A leaked controller secret can allow someone to change proxy settings on your machine.
Make the Setup Reliable for Daily Use
Once the basic test passes, make a small record of the working configuration: Clash Verge Rev version, Mihomo core version, TUN stack, DNS mode, active profile, and whether service mode is enabled. This information is valuable after a Windows update or subscription refresh changes behaviour. Avoid changing five settings at once because you will lose the ability to identify which adjustment solved or caused the problem.
Keep the profile’s rule order understandable. Put specific domain rules before broad geolocation or final rules, and verify that destinations requiring a proxy are not accidentally caught by an early DIRECT entry. For local resources, create deliberate bypass rules instead of disabling TUN globally. This gives you system-wide capture while preserving access to printers, routers, file shares, and development services on your private network.
Use the connection log as an operational tool, not just a failure screen. When an application behaves unexpectedly, reproduce the action, filter by the application’s destination, and note the matched rule and outbound. A TUN problem normally leaves no connection entry at all; a rule problem leaves an entry with an unexpected decision; and a node problem usually shows failed handshakes, retries, or timeouts. Separating these categories makes troubleshooting much faster.
For laptops, test sleep and wake behaviour. Windows may resume Wi-Fi with a different interface index or delay the helper service while background startup is restricted. If TUN works after a full boot but not after sleep, restart the Clash service or toggle TUN after the network reconnects. Also check that battery-saving software has not blocked the client from running in the background.
Finally, know how to recover: disable TUN, disable the system proxy if needed, close Clash Verge Rev, and reconnect your normal VPN or network. If Windows still cannot browse, inspect the active default route and DNS configuration, then reboot before removing adapters. A clean recovery plan is part of a safe TUN setup, especially on a work machine where uninterrupted access matters more than experimenting with advanced options.
Some alternative Windows clients make TUN activation look simpler, but they may hide service permissions, provide fewer diagnostics, or rely on defaults that are difficult to reproduce when a virtual adapter conflicts with a VPN. Older Clash for Windows builds are familiar but lack the modern Mihomo workflow, while highly simplified GUIs can leave you without clear rule, DNS, or connection evidence. Clash Official Site takes a more practical middle path for this scenario: it keeps the Clash Verge Rev and Mihomo concepts visible, explains the permission and adapter checks, and gives you a repeatable way to verify traffic instead of trusting a switch alone. If you want to follow this Windows TUN walkthrough with a supported client setup, you can download Clash clients and start with the version that matches your system.