How to Enable Clash TUN Mode: How a Virtual Network Adapter Takes Over All Traffic

The Fundamental Difference Between TUN Mode and a System Proxy

In Clash clients, the familiar “system proxy” and “TUN mode” are not two levels of the same switch. They are two different ways of routing traffic into Clash. A system proxy writes HTTP and HTTPS proxy addresses to the operating system; the common listening address is 127.0.0.1:7890. Browsers, chat apps, and other programs that actively read system proxy settings hand their connections to Clash. Apps that ignore those settings continue connecting directly.

TUN mode creates a virtual network adapter and adds the corresponding routes to the system routing table. IP packets that match those routes enter the virtual adapter first. The mihomo core then identifies the destination, evaluates the rules, and decides whether to proxy, connect directly, or reject the traffic. TUN therefore captures traffic at the network layer, without requiring every application to understand HTTP or SOCKS proxies.

When TUN Mode Is Worth Enabling

• The browser works, but a game launcher, store client, or desktop app always connects directly.
• git, package managers, and other command-line tools do not read the system proxy.
• An application uses UDP or QUIC, which a basic HTTP proxy setting cannot cover.
• You do not want to configure HTTP_PROXY, HTTPS_PROXY, or a SOCKS5 address in every application.
• You want one set of Clash rules to handle more connections from the local machine.

If you only browse the web, a system proxy is usually simpler and easier to troubleshoot. TUN changes the routing and DNS paths, so it is best reserved for cases that genuinely require traffic capture—not treated as a mandatory post-install setting.

Prepare Permissions and Services Before Enabling TUN

The examples below use the Clash Verge Rev 2.x configuration layout with the mihomo core. Menu labels vary slightly between clients, but the preparation is much the same: the core needs sufficient permission to create a virtual adapter and write routes, and it must clean them up correctly when the app exits or restarts.

Windows: Install Service Mode

1. Quit any other VPNs, network accelerators, or virtual adapter tools that are running to avoid route conflicts during the first installation.
2. Open the client and go to “Settings” → “System Settings” → “Service Mode.”
3. Select “Install,” then approve administrator access in the Windows User Account Control prompt.
4. After installation, confirm that the service status shows it is running, then open the “Proxy” page and enable “TUN Mode.”
5. After enabling it for the first time, wait about 3–10 seconds for the virtual adapter and routes to initialize.

Service Mode lets a background service with administrator privileges manage the virtual adapter and routes while the graphical interface continues running as a standard user. If clicking Install produces no status change, fully exit the client, launch it once with “Run as administrator,” and install again. On managed corporate computers, service installation may require authorization from the device administrator.

macOS: Allow the Helper or Network Extension

1. Open the client’s “Settings” → “System Services” or “Service Mode,” then choose to install the helper.
2. Confirm the operation with your system password or Touch ID when prompted.
3. If macOS blocks the network component, open “System Settings” → “Privacy & Security” and allow the corresponding component near the bottom of the page.
4. Return to the client and enable TUN. If macOS asks again whether to allow a VPN configuration to be added, choose Allow.

After a macOS update, an older helper may need to be authorized again. If the system repeatedly asks for your password or the TUN switch turns itself off, uninstall Service Mode in the client, restart macOS, and reinstall it from the current client version. Do not keep system services from two Clash GUI clients installed at the same time.

Android: Confirm VPN Permission

On Android, Clash Meta-style clients usually create a local virtual adapter through the system VPNService. Open “Settings” → “Network” → “TUN,” and Android will show a VPN connection confirmation dialog. After approval, a key or VPN icon appears in the status bar. Android supports only one active VPN service at a time, so an existing corporate VPN, WireGuard connection, or other proxy app will be disconnected.

Recommended Clash TUN Settings

For most desktop setups, a good starting point is stack: mixed, auto-route: true, and auto-detect-interface: true, with Clash DNS handling queries on port 53. The following is a basic configuration structure recognized by the mihomo 1.19 series:

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query

GUI clients often generate or overwrite some of these fields. If the client provides “TUN Stack,” “Auto Route,” or “DNS Hijacking” switches, change them in the interface first instead of editing a subscription-generated read-only configuration at the same time. Subscription updates may overwrite the configuration body, while client-saved global overrides generally remain active.

Stack Selection: Start with mixed

Do not keep switching stacks just because one name sounds more advanced. Start with mixed and test web browsing, DNS, downloads, and the applications that need to be captured. If only one category of connection fails, test system and then gVisor, fully disconnecting and re-enabling TUN after each change.

Automatic Routing and Outbound Interface Detection

auto-route: true makes the core write the routes needed to capture traffic automatically; auto-detect-interface: true identifies the current physical outbound adapter. When a laptop switches from Ethernet to Wi-Fi or from a home network to a phone hotspot, automatic detection reduces the chance of sending the proxy connection back into TUN.

strict-route: true applies tighter routing constraints and can also reduce some DNS requests bypassing the capture path on Windows. Strict routing may affect LAN discovery, virtual machine bridges, or corporate intranets. If printers, NAS devices, or company subnets become unreachable, temporarily disable strict-route for comparison instead of turning off TUN entirely.

Why DNS Hijacking Commonly Uses any:53

dns-hijack: any:53 sends traditional UDP/TCP port 53 queries from captured traffic to the mihomo DNS module. This keeps DNS results consistent with rule evaluation and reduces the chance that an app bypasses the system DNS settings. It does not automatically capture built-in DoH, which is HTTPS traffic sent to a specific server and must be handled separately through domain or IP rules.

198.18.0.1/16 is a commonly used fake-IP range. When an app looks up a domain, it first receives a mapped address from this range; the core then restores the original domain from the mapping and evaluates the rules. If LAN devices, printer hostnames, or applications that require real IP addresses behave unexpectedly, add the relevant domains to the fake-IP filter list instead of casually switching to a normal public address range.

Complete Workflow: From Enabling TUN to Verifying Traffic Capture

1. On the “Profiles” page, update and select a working configuration, then confirm that at least one node connects successfully.
2. Set the operating mode to “Rule” to avoid global policies interfering with the test.
3. Go to “Settings” → “Clash Settings” → “TUN,” and set the stack to mixed.
4. Enable “Auto Route,” “Auto Detect Outbound Interface,” and “DNS Hijacking.”
5. Confirm that Service Mode is installed and running, then turn on the main TUN switch.
6. First test a browser that follows the system proxy, then test an application that the system proxy could not capture before.
7. Open the client’s connection logs and check whether the destination domain appears, along with the rule and policy group that ultimately matched it.

To verify the result, temporarily disable the system proxy and leave only TUN enabled. If the browser and target app still connect according to Clash rules, the virtual adapter path is working. Whether to re-enable the system proxy afterward depends on the client; mihomo can usually handle both entry points at once, but troubleshooting is clearer when only one is enabled at a time.

Windows: Check the Virtual Adapter and Routes

Run the following commands in PowerShell to view the current network adapters and IPv4 routes. Adapter names created by different clients may contain Mihomo, Clash, or Meta:

Get-NetAdapter | Sort-Object Status, Name
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Select-Object -First 20

The virtual adapter should show an Up state, and the routing table should contain entries managed by TUN. Do not judge success solely by whether the default route points to the virtual adapter: different systems and core versions may use split routes, policy routing, or more specific route entries.

Use Logs to Verify Rules, Not Just the Web Result

Open the “Logs” page and set the level to info. After launching the app under test, you should see the destination address, network type, and matched policy, such as TCP, UDP, MATCH, DIRECT, or a specific proxy group. If no corresponding connection appears, the traffic has not entered the core. If a log exists but shows DIRECT, check the rule order. If a proxy was selected but the connection times out, check the node, UDP support, or remote service next.

Troubleshooting Order When TUN Breaks Internet Access

Do not change the stack, DNS, node, and rules all at once. Check each layer in this order: service permissions → virtual adapter → DNS → rules → node. This usually locates the failure much faster.

Step 1: Confirm the Base Configuration and Node Work

Disable TUN, enable the system proxy, and test the current node in a browser. If it still cannot connect, the virtual adapter is not the problem; fix the configuration, policy group, or node status first. TUN only changes how traffic enters the core—it cannot repair a failed node.

Step 2: Distinguish a DNS Failure from a Routing Failure

If a domain fails but a known IP address works, check DNS first. If the client logs contain no DNS query, check dns.enable and port 53 hijacking. If queries appear but the upstream times out, switch to a reachable upstream DNS server and confirm that the bootstrap DNS used to resolve proxy server domains is directly reachable.

If the domain resolves but the TCP connection never appears in the logs, the routes may not have been written, the virtual adapter may not be running, or another VPN may have captured the traffic first. Quit other VPNs and network filtering tools, then turn TUN off and on again.

Step 3: Handle LAN and Virtual Machine Networking

Common private ranges include 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. Home routers, NAS devices, and printers should generally match DIRECT. Place these rules before the fallback MATCH, for example:

rules:
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,Node Selection

Virtual machines and containers may also use these ranges, so do not mechanically exclude every private address from TUN. If virtual machine traffic needs to be proxied, first determine which host adapter actually carries it, then choose between a DIRECT rule, route exclusion, or a separate proxy configuration inside the virtual machine.

Performance, IPv6, and Long-Term Use

TUN adds a virtual adapter and user-space processing layer, but everyday browsing and download speeds are usually limited more by node latency, congestion, protocol, and the remote server. For a fair comparison, use the same node and target file, test with TUN off and on, and run each set at least three times. A single speed test is easily skewed by caching and short-term network fluctuations.

When CPU usage is high, first lower the log level from debug back to info, stop continuous connection tests, and inspect the specific process. Large numbers of UDP sessions, P2P software, and frequent DNS queries can all increase the connection count substantially. The desktop client’s connections page can help identify unusually active applications.

Do Not Enable IPv6 Blindly

If the local network, proxy nodes, and rule set all properly support IPv6, enable the corresponding handling. If the ISP provides unstable IPv6, an app may try an AAAA address first and wait for a timeout. During troubleshooting, temporarily disable IPv6 in the Clash configuration and compare connection times to the same destination. Do not permanently disable IPv6 across the operating system just to fix one site.

Keep a Rollback Configuration

• Record the currently working stack type, DNS mode, and strict-route state.
• After updating the client or mihomo core, confirm that Service Mode is still running.
• After a subscription update, check the policy group names so local rules do not point to groups that no longer exist.
• Before editing YAML, use the client’s configuration checker and use spaces consistently for indentation.
• If the network goes down, disable TUN first. If connectivity returns immediately, troubleshoot each item in this article’s order.

The key to TUN is not turning on every switch; it is completing the chain of permissions, routing, DNS, and rules. First confirm that the virtual adapter is created, then use logs to verify that traffic enters the core, and finally inspect the matched rule and outbound route. Following this order turns issues such as browsers working while desktop apps fail, domains breaking after enablement, or LAN devices disappearing into clear troubleshooting steps.