Platform Guide 2026-08-02 14 min read

Some Windows apps and games ignore the system proxy. This guide shows how to turn on TUN mode in Clash Verge Rev, grant the required permission, and verify that traffic is being routed correctly. It also explains the difference between system proxy and TUN mode, how to avoid DNS leaks, and what to check when the TUN switch is enabled but an application still cannot connect.

Before you begin

Keep Clash Verge Rev open during the entire setup. You need administrator approval for the TUN service, and the exact names of menu items can vary slightly between releases and core choices. The settings described here apply to a current Windows installation using a Mihomo-compatible core.

Clash Verge Rev TUN Mode Setup on Windows: A Simple Guide

What TUN mode does, and why the system proxy is not always enough

Clash Verge Rev can route traffic in two different ways that are often confused. The first is the ordinary system proxy. When this option is enabled, Windows applications that respect the operating system's proxy settings send HTTP, HTTPS, or SOCKS traffic to Clash's local port. Browsers and many desktop tools work this way. A browser may read the proxy address from Windows Settings, while a command-line program may read the HTTP_PROXY environment variable or use its own configuration.

The limitation is that applications are not required to honor the Windows proxy. Many games, launchers, update services, virtual machines, development tools, and applications based on a separate networking library open direct TCP or UDP connections. In that situation, Clash can be running normally and the system proxy can show as enabled, yet the application never sends a request to the local mixed port. Changing the proxy mode from Rule to Global will not help if the application's packets never enter Clash.

TUN mode works at a lower level. It creates a virtual network interface and asks the Clash core to receive traffic from that interface. The core can then apply routing rules to connections that would otherwise bypass the system proxy. Depending on the selected stack and configuration, TUN can handle TCP and UDP traffic and can redirect DNS queries into the configured DNS processing path. This makes it useful for software that ignores Windows proxy settings.

TUN mode is not a faster node mode and it does not repair an invalid subscription. It only changes how local traffic enters the proxy core. The selected proxy group, rule provider, DNS settings, firewall permissions, and remote node must still be working. A useful mental model is: the system proxy changes application behavior, while TUN changes the path by which Windows traffic reaches Clash.

Feature	System proxy	TUN mode
How traffic enters Clash	Applications connect to a local proxy port	Traffic is captured through a virtual network interface
Application compatibility	Only software that respects proxy settings	Usually covers more TCP and UDP applications
Administrator permission	Usually not required to enable the proxy	Normally required for the service or virtual interface
Main risks	Easy to bypass accidentally	Routing loops, DNS conflicts, or local network interference

Prepare Windows and Clash Verge Rev before enabling TUN

Start with a clean baseline rather than enabling several networking features at once. Open Clash Verge Rev and confirm that the application has loaded a valid profile. The profile should contain at least one proxy node and a usable proxy group. If the profile is empty, expired, or still being parsed, TUN mode cannot make a connection succeed.

Check the active profile.
Open the Profiles or configuration area and select the profile you actually intend to use. Confirm that proxy groups and nodes are visible. If the profile has not been imported successfully, resolve that issue first.
Choose a known working proxy group.
In the dashboard, select a group and test one or two nodes. A node that repeatedly times out is a poor choice for verifying TUN because it combines a routing problem with a remote connectivity problem.
Record the current local network state.
Note whether another VPN, proxy client, traffic filter, virtual machine network, or game accelerator is running. These tools may install their own virtual adapters and compete with the TUN interface.
Update Windows only when appropriate.
A normal, supported Windows build is recommended. If a recent system update changed network drivers or security policy, restart once before troubleshooting so that pending driver and service changes are not mistaken for a Clash failure.

It is also worth deciding whether TUN should be enabled permanently. TUN is convenient for applications that bypass the system proxy, but it can affect local device discovery, printers, corporate networks, captive portals, and some anti-cheat or security software. If you only need proxy routing in a browser, the ordinary system proxy is simpler and has a smaller scope.

Caution

Do not run two full-tunnel tools at the same time unless you understand their routing order. A second VPN, an older Clash client, or a security product with packet interception can create circular routes or make the virtual interface appear connected while traffic is silently dropped.

Enable TUN mode in Clash Verge Rev on Windows

The TUN controls are generally found in Clash Verge Rev's settings under a section named Clash Core, Core, General, or TUN. The layout depends on the release and the selected core, but the process follows the same order: select a compatible core, enable TUN, install or allow the required service, then start the interface.

Open Settings.
Launch Clash Verge Rev from the Start menu or notification area, then open its settings page. If the window is minimized to the tray, right-click the tray icon and choose the settings or dashboard entry.
Find the TUN section.
Look for a switch labelled TUN Mode, Enable TUN, or similar. Some versions place it inside the core settings rather than the general application settings.
Select the recommended core.
Use the Mihomo-compatible core supplied or supported by the current Clash Verge Rev release when TUN features require it. A legacy core may show normal proxy controls but lack support for a particular TUN option, DNS mode, or service implementation.
Enable the TUN switch.
Turn on TUN mode and apply the change. Windows may display a User Account Control dialog or a separate permission prompt. Approve it only if the request was initiated by the Clash Verge Rev installation or settings action.
Allow the service or driver installation.
If the client asks to install a service, choose the install or allow option. The service lets the core create and manage the virtual network interface with the privileges required by Windows. A normal user account may need to enter an administrator password.
Restart the core if requested.
Some releases apply TUN changes only after restarting the core or the application. Close and reopen Clash Verge Rev if the switch remains enabled but the interface status does not change.

After activation, Windows should show a virtual adapter associated with the TUN implementation. The name may include terms such as Clash, Mihomo, TAP, or Wintun, depending on the implementation. Do not manually change the adapter's IPv4 address, gateway, or DNS values unless the client documentation specifically requires it. Manual edits can prevent the core from recreating the interface correctly.

Handle administrator permission and service errors

A permission prompt is expected because a user-space application cannot freely create a system-wide virtual network path. If the prompt is denied, TUN may remain visibly enabled in the interface while no functional adapter is created. Reopen the settings page and look for an install-service, repair-service, or reinstall-service action. Running Clash Verge Rev once with Run as administrator can help complete the initial installation, but it should not be necessary to run every application with elevated privileges after the service is correctly installed.

If Windows Security or a third-party endpoint product blocks the service, inspect its protection history and event log. Add an exception only when the executable and installation source are trusted and the file path matches the installed Clash Verge Rev application. Do not disable all security protections as a first troubleshooting step. On managed computers, an organization policy may prohibit virtual network drivers; in that case, an administrator must change the policy or provide an approved networking method.

Configure routing, DNS, and the system proxy without creating conflicts

Turning on TUN does not automatically mean every connection will use a remote proxy. The active mode still determines how Clash handles captured traffic. In Rule mode, domains and IP addresses are matched against the profile's rules and then sent to a proxy group, direct connection, or rejection policy. In Global mode, most captured traffic follows the selected global proxy. Rule mode is usually the better everyday setting because it preserves direct access to local and domestic services when the profile is designed for that purpose.

For the first test, keep the routing choice simple. Select one known working proxy group, use Rule mode if the profile has valid rules, and avoid changing several policy groups while diagnosing TUN. If an application still connects directly, check whether its destination is intentionally matched to DIRECT. That is a rule result, not necessarily a TUN failure.

DNS deserves separate attention. A domain may resolve before Clash receives the connection, causing an application to obtain a local address even though its subsequent traffic is captured. A DNS configuration that includes fake-IP or redirection behavior can improve rule matching, but it may also affect local services that expect ordinary LAN addresses. Follow the DNS mode recommended by the profile and the current Mihomo core rather than copying options from an unrelated configuration.

Use a DNS setup that the active core supports; unsupported fields may be ignored or cause configuration errors.
Keep fake-IP filtering or LAN exclusions consistent with the profile's rules.
Do not add the same local DNS server to several conflicting fallback lists without a reason.
When testing, compare a domain request and a direct IP request because they exercise different parts of the routing path.

The Windows system proxy can remain enabled alongside TUN, and many users leave it on so ordinary proxy-aware applications behave predictably. However, enabling both does not mean traffic is routed twice. A proxy-aware application may send its request to Clash's local port, while other applications enter through the TUN interface. If you see a loop, repeated connection attempts, or a local address being proxied back into itself, temporarily disable the system proxy and test TUN alone.

Practical baseline

For the first verification, use one active profile, one selected node, Rule or Global mode, the profile's default DNS settings, and no second VPN. After traffic works, re-enable other networking tools one at a time.

Verify that Windows traffic is really passing through TUN

A green TUN switch is only an administrative state. Verification should include the interface, the Clash connection log, and an application that previously bypassed the system proxy. Start with the Clash dashboard and watch the connection list while opening a new website or launching the affected application. A new connection entry with the expected process, domain, rule, and proxy group is stronger evidence than the switch alone.

Check the virtual adapter.
Open Windows network settings or run ncpa.cpl from the Run dialog. Look for the adapter created by Clash or its TUN implementation. It should not be permanently disabled. If it is missing, return to the service and permission checks.
Inspect Clash's connections.
Open the dashboard's Connections view or log panel. Clear old entries, start the test application, and observe whether fresh TCP or UDP sessions appear. Record the rule decision and the selected outbound group.
Test a proxy-aware browser.
Open a new private window and visit a neutral connectivity page. This confirms that the profile and selected node work, but it does not by itself prove that TUN is needed because the browser may already honor the system proxy.
Test the application that bypassed the proxy.
Close and reopen the game, launcher, or tool after TUN is active. Many applications resolve servers or cache routes during startup. If a new connection now appears in Clash, TUN is capturing the traffic.
Compare with TUN disabled.
Stop the application, disable TUN, start it again, and compare the connection list. A clear difference between the two tests helps separate a TUN capture issue from a bad node, blocked destination, or application-side failure.

Command-line checks can add useful evidence. In PowerShell, Get-NetAdapter lists network adapters and their status, while Get-NetRoute displays active routes. These commands do not tell you whether a remote node is healthy, but they can show whether the expected virtual interface exists and whether Windows has a route associated with it. Avoid deleting routes manually during the test; record the output first and let Clash manage its own interface.

Fix the most common TUN failures on Windows

If TUN does not work after the first setup, troubleshoot from the local permission layer outward. Randomly switching nodes can hide the actual cause. The following symptoms are more useful than the status color.

The switch is on, but no virtual adapter appears

This usually indicates a missing service, denied elevation, blocked driver, or unsupported core. Restart Clash Verge Rev, run its service installation or repair action, and approve the Windows permission prompt. Then check Device Manager and Windows Event Viewer for driver or service errors. If the adapter still does not appear, test with third-party VPN software stopped and confirm that the selected core supports the TUN implementation used by the release.

The adapter exists, but Clash shows no new connections

Check whether the affected process is excluded by a bypass list, whether the destination is being handled directly, and whether another VPN has a higher-priority route. Temporarily disable the system proxy, stop other tunnel software, and restart the target application. If only one program is missing from the connection list, that program may use a special driver, encrypted transport, or a local relay that TUN cannot capture in the expected way.

Connections appear, but websites or games cannot connect

At this point TUN is probably capturing traffic, so move to rule, DNS, node, and firewall checks. Look at the connection entry to see whether the rule selected REJECT, DIRECT, or an unintended proxy group. Test another node, verify the system clock, and check whether the remote service blocks the selected address. For DNS problems, compare a hostname with a known reachable IP and review the core's DNS log. Do not assume that changing to Global mode will fix a node that is offline.

Local devices stop working after TUN is enabled

Printers, NAS devices, routers, and other LAN services may depend on private address ranges or multicast discovery. Confirm that the profile's TUN route exclusions and DNS filters cover the local network in use. If local access returns when TUN is disabled, add a carefully scoped LAN bypass according to the configuration syntax supported by the active core. Avoid excluding broad public ranges just to make one application work; identify the actual private subnet first.

Do not do this first

Do not repeatedly reinstall Windows network drivers, delete every route, or disable the firewall before collecting evidence. Those actions can remove useful diagnostics and create a second problem. First record the TUN status, adapter presence, service state, connection log, rule decision, and exact error message.

Use TUN mode safely in daily work and gaming

Once TUN works, keep the configuration understandable. Give the active profile a clear name, note which core is selected, and avoid importing several profiles with overlapping DNS and TUN settings at the same time. Enable auto-start only after manual startup is stable. If the computer changes between home Wi-Fi, office Ethernet, and a mobile hotspot, test each network because firewall policy, captive portals, and DNS interception can differ.

For games and launchers, start Clash Verge Rev before launching the software and leave enough time for the profile and node to initialize. Some games use UDP and may require a TUN stack and rule set that handles UDP correctly. A successful browser test does not prove that UDP is available. Watch the connection list while the game logs in, and verify that the relevant traffic is not being sent directly or rejected by a rule.

When a website or application should never use the proxy, prefer a narrow rule or application-specific bypass over disabling TUN globally. When a service stops working after a profile update, compare the new rules and DNS behavior with the last known working profile. The goal is not to force every packet through one path, but to make the path for each class of traffic explicit and reversible.

To turn TUN off, close the applications that depend on it, disable the TUN switch, and restart the core if requested. If Windows continues to show the virtual adapter, that does not necessarily mean traffic is still being proxied; an installed adapter can remain present while inactive. Check the Clash status and connection list before removing the service. Only uninstall the service when you no longer need TUN and the client provides a supported uninstall action.

Download Clash Client

Choosing an installer: architecture and build differences

Windows client builds differ in underlying core and interface type, and picking the wrong one will throw off every step that follows. Most mainstream clients are now built on Clash Meta (the mihomo core) and ship with a GUI plus subscription management. You'll typically see three package types: an installer build (an exe that writes to the registry and Start Menu), a portable build (unzip and run, no system changes), and a few variants that bundle a separate driver installer. First check your system architecture — 64-bit Windows 10/11 needs the x64 package, while older machines or ARM-based Windows need the matching build. Installing the wrong architecture usually shows up as the app doing nothing on double-click, or an error saying it's "not a valid Win32 application."

The main difference between the installer and portable builds comes down to permissions and leftovers: the installer build registers a local service to support TUN mode, so uninstalling cleanly requires going through the system's "Uninstall a program" entry. The portable build keeps all config files inside its extracted folder, which makes it easier to move around or run multiple instances — but if you want TUN mode, you'll still need to run it as administrator once to register the driver. For a first install, the installer build is the better pick: the setup flow is more complete and leaves clearer logs for troubleshooting later.

First launch: dealing with SmartScreen and security prompts

The first time you run a freshly downloaded installer, Windows will very likely show a "Windows protected your PC" SmartScreen warning. This is just the default block for new, low-download executables — it has nothing to do with whether the file is actually trustworthy. To proceed, click "More info" in the prompt, then click "Run anyway." If that button doesn't appear, Group Policy or third-party security software has likely tightened SmartScreen settings, and you'll need to temporarily adjust this under Windows Security → App & browser control.

Note

After installation, opening the client for the first time may trigger another prompt from security software flagging a newly installed networking app. This is normal behavior detection, not a real threat — just allow network access when prompted and it won't affect normal use.

Keep the default install path (usually under your user folder or Program Files). Avoid installing into a deep path containing Chinese characters or special symbols, which can cause encoding issues when some versions read config file paths.

Importing a subscription and verifying basic connectivity

Once the client is installed and open for the first time, import your subscription before touching any other settings — doing things out of order makes it much harder to tell network issues apart from configuration issues. Most GUI clients have a "Subscriptions" or "Profiles" page with a URL field: paste your subscription link and click download, and the client will parse out the node list and rule groups automatically.

Paste the subscription URL and download it, then confirm the node list isn't empty and the names match what you expect.
On the nodes page, run a manual latency test or select a node, and check that it returns an actual millisecond value rather than a timeout.
Don't rush to enable the system proxy yet — first confirm in the client's built-in logs or connections page that it can establish connections normally.
Once that checks out, move on to system proxy and mode settings.

If the node list is empty or the download fails at this step, first check whether the subscription link was copied in full or has expired. Subscription format issues aren't the focus of this article, so check other troubleshooting notes on the site for that.

System proxy vs. TUN mode: enabling order and permission requirements

On Windows, there are two ways to actually route your browser and other apps through the proxy, and they work very differently in terms of mechanism and permissions — worth understanding both before choosing.

System proxy mode

This is the most basic method: the client writes an HTTP/HTTPS proxy address (usually 127.0.0.1 plus a port) into Windows' network settings, and any app that respects the system proxy setting will pick it up automatically. It's usually toggled with a "System Proxy" switch in the client UI — once enabled, you'll see the manual proxy address filled in under Settings → Network & Internet → Proxy. This mode doesn't require administrator rights, but it only covers apps that honor the system proxy setting; some apps bypass it and connect directly regardless.

TUN mode

TUN mode sets up a virtual network adapter at the system level and intercepts all traffic (or traffic matching your rules), giving much more complete coverage. But it requires installing a network driver (commonly based on WinDivert or Wintun), so the client must be run as administrator the first time you enable it, and you'll need to approve the driver installation or service confirmation prompt that appears. It's usually toggled via a "TUN Mode" or "Virtual NIC Mode" switch in Settings. Expect a brief network interruption (a few seconds to over ten seconds) the first time you enable it — that's just the virtual adapter initializing and is completely normal.

Important

If you run the client without administrator rights, the TUN toggle may appear to switch on even though the underlying driver failed to load — it looks enabled but doesn't actually work. If this happens, fully quit the client (including the system tray icon), then right-click and choose "Run as administrator" before trying again.

Auto-start on boot and troubleshooting service install failures

For everyday use, it's worth enabling auto-start so you don't have to manually open the client every time, which would otherwise leave your proxy status inconsistent. Most GUI clients have an "Auto-start on boot" toggle under general settings, which registers a startup entry or scheduled task in the background — no extra steps needed once it's on.

Some clients install an additional background service to support TUN mode (so the virtual adapter can keep running even when no user is logged in), and failures during this service install are the second most common source of errors on Windows. Here's a rundown of typical symptoms and fixes:

Error symptom	Common cause	How to fix
Service install/start failure prompt	The app wasn't launched or installed with administrator rights	Right-click "Run as administrator" and trigger the service install again
Prompt about driver signature or driver load being rejected	The system has strict driver signature enforcement enabled	Confirm the system isn't in a restricted test mode, or temporarily allow the driver through Windows Security
Service already exists but the client still throws an error	A leftover service with the same name from an old uninstalled version	Stop and delete the leftover service via the Services management panel, then reinstall

If the install keeps failing, try rebooting once before retrying — this rules out most false failures caused by leftover processes or held handles.

Checklist for common pitfalls like port conflicts

Beyond permission and driver issues, the following problems come up frequently during initial Windows setup — listed here together so you can check them off one by one.

Mixed port already in use: If the local port the client listens on by default (commonly 7890/7891) is already taken by another proxy tool or local service, the client may fail to start or the proxy simply won't work. You can change the listening port in settings, or close whatever else is using that port first.
System proxy conflicting with browser proxy extensions: If your browser has a standalone proxy extension installed, its settings may override the system proxy, causing browser behavior to not match the client's actual state. During troubleshooting, try temporarily disabling the extension first.
Virtual adapter conflicting with a local VPN client: If you're also running enterprise VPN software or similar virtual-adapter tools, TUN mode may compete with it over routing priority, showing up as some sites working and others not. Try temporarily disabling one to test the other in isolation.
Accidentally clicking "Block" on the first firewall prompt: The first time Windows Firewall detects the client trying to access the network, it shows a prompt asking for permission. If you clicked Block by mistake, go to Windows Defender Firewall → Allow an app through firewall and manually check the public/private network permissions for the client.
Websites still won't load in rule mode: Confirm the current policy mode (rule-based/global/direct) matches what you expect — in rule mode, some sites being routed directly by rule design is normal behavior, not a malfunction.

Working through this order — is the system proxy on → is TUN mode actually active with admin rights → are the port and firewall allowed through → does the policy mode match expectations — covers the vast majority of first-time setup issues on Windows, and the same checklist applies just as well after future updates.