Clash TUN Mode: How Virtual Network Adapters Route Traffic on Windows, macOS, and Android

TUN mode vs. system proxy: what traffic each handles

A system proxy provides applications with proxy address settings. Browsers can read them and send requests to a local HTTP proxy port. Games, command-line tools, and some desktop apps that open connections themselves may ignore these settings entirely. Enabling the system proxy does not mean every app's traffic passes through Clash.

TUN is a virtual interface that operates at the network layer. The client creates the interface and adjusts system routes so matching IP packets enter the core. The core handles TCP, UDP, and other connections, then routes them directly, through a proxy, or blocks them according to the rules. Apps generally don't need individual proxy settings, but route exclusions, app exclusions, and platform limitations may still apply.

The YAML examples in this guide are for mihomo, the continuation of Clash Meta. Fields and platform support vary across Clash forks. Check the core name in the client's About or core information screen, then consult the documentation for that core. A TUN toggle in the interface does not mean an older core supports every field below.

How the virtual adapter, routing table, and DNS work together

What happens to a connection

1. An app resolves a domain name or connects directly to an IP address.
2. The operating system selects a route. With automatic routing enabled, matching traffic is sent to the TUN interface.
3. The core receives the destination address and applies DNS mappings, rules, and optional sniffed metadata.
4. Connections routed through a proxy leave via the selected node; direct connections leave through the physical network interface.

Connections from the core to a proxy server must leave through the physical network interface, not loop back into the core. auto-detect-interface identifies the outbound interface automatically, reducing the risk of routing loops. The selected interface may change when you switch Wi-Fi, plug in Ethernet, or enable or disable another VPN, so check the logs and routes again.

DNS hijacking does not intercept all encrypted DNS

dns-hijack can send matching DNS traffic to the core's DNS module, such as UDP or TCP traffic on port 53. When a browser connects to an external resolver over HTTPS, its requests usually use port 443—not a standard port 53 DNS query. A single any:53 entry therefore does not mean all DNS lookups are intercepted.

With fake-ip, the core returns a mapped address and uses later connections to recover the domain name. The example range 198.18.0.1/16 is reserved for benchmarking and used here for internal mapping; it is not a proxy server address. LAN devices and apps that depend on real DNS answers may need domains added to fake-ip-filter. Avoid excluding large numbers of domains indiscriminately.

Configure mihomo TUN and choose a stack

This example is meant to be merged into an existing configuration. It does not include nodes, proxy groups, or routing rules, so it is not a complete subscription. Back up your configuration first, then add the settings using the client's supported override or merge feature to avoid losing local changes when the subscription updates. If fields with the same name already exist, merge their contents instead of adding duplicate top-level dns or tun sections.

mixed-port: 7890
mode: rule

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

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

• mixed-port: 7890 is the HTTP/SOCKS mixed proxy port in this example, not a port used by TUN to receive packets. Changing it to another unused port does not directly affect virtual interface routing.
• listen: 127.0.0.1:1053 is the local listening address for the core's DNS service. It does not mean you should set the system DNS server to “127.0.0.1:1053.” Most system DNS settings accept only a server IP, not an address with a port.
• auto-route adds relevant routes automatically; auto-detect-interface identifies the physical outbound interface. Neither feature tests node latency or automatically selects a node.
• The DNS servers shown are examples to illustrate the configuration fields. Choose upstream servers based on network reachability, resolution policy, and privacy requirements; these example addresses are not universal recommendations.

system, gvisor, and mixed: what's the difference?

Don't assume any stack is a guaranteed “fastest mode.” Throughput, CPU usage, and compatibility depend on the operating system, core build, node protocol, and application workload. To troubleshoot, keep the node and test destination the same, change only the stack, then reconnect before comparing results. Existing connections may still use the previous path.

Windows: service permissions and virtual adapter checks

On Windows 10 and Windows 11, creating a virtual interface and changing routes require the appropriate permissions. Desktop clients may run the core as an administrator or through a background service. “Start at boot” and “service mode” are separate settings. After installing the service, make sure it is actually running.

1. Turn off TUN, import your configuration, and select an available node. Enable the system proxy and open a test website to confirm the subscription and node are working.
2. Look for “Service Mode” in the client settings and follow the prompts to install and start the service, or launch the client as an administrator if its documentation requires it. When Windows displays User Account Control, verify the program path.
3. Temporarily disable the system proxy, then enable “Virtual Network Adapter” or “TUN” mode. This makes it easier to confirm TUN is working without mistaking the system proxy for the cause.
4. Open Settings → Network & internet → Advanced network settings and check for changes to the network adapters. The interface name depends on the client and core configuration; it does not have to be called Clash.
5. Open the client's connection list and run an app with no proxy configured. Check that its connection appears and that the expected rule is matched.

For a closer look, run these read-only commands in PowerShell. Check for a new interface, the interface index used by routes, and DNS servers—not just the connection icon in the taskbar.

Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
Get-DnsClientServerAddress
Get-NetTCPConnection -State Listen -LocalPort 7890

The final command only checks whether the example proxy port is listening; it does not confirm that TUN is working. If the logs show a permissions error, fix the service permissions first. If the port is in use, identify the process listening on it. Don't disable the entire Windows Firewall to fix a virtual interface creation failure.

macOS: helper services and utun route checks

macOS clients typically use a privileged helper service to create or manage TUN, while some use a system network extension. Authorization depends on the client's implementation, so don't assume one app's menu applies to every client. When downloading and installing, make sure to choose the build for Apple silicon or Intel.

1. First verify the node with the system proxy, then follow the client's prompts to install a helper service or approve a network extension. Before entering an administrator password, make sure the authorization request comes from the client you just installed.
2. Enable TUN. If macOS asks you to allow a background component, follow the prompt to open System Settings → General → Login Items & Extensions and check the relevant item. The wording may vary slightly between macOS versions.
3. Temporarily turn off the system proxy, then reopen a test app and check in the client that its connections still reach the core.
4. Test again after waking from sleep or switching networks. If TUN stops working only after wake, note the outbound interface and core logs, then restart TUN and test again.

ifconfig
netstat -rn -f inet
route -n get 1.1.1.1
scutil --dns

utun interfaces may also be used by other system services or VPNs. Seeing utun0 does not prove that it belongs to the current client, and interface numbers are not fixed. Compare interfaces and routes before and after enabling TUN, then check the client logs. A route lookup only shows how a specific destination IP will be routed; by itself, it cannot confirm that all DNS queries or IPv6 traffic enter the core.

Android: VPN permission, app coverage, and background limits

Android clients typically use the system VpnService to create a virtual interface, with no root access required for most users. The first time you connect, Android displays a VPN permission prompt. Android's “VPN mode” serves a similar purpose to desktop TUN, but the app usually manages interfaces and routes itself, so don't copy desktop auto-route settings blindly.

1. Import your subscription, select a proxy group, and start the connection. Check the app name in Android's VPN permission prompt, then tap Allow.
2. Check the app routing settings in the client. If you choose “Proxy selected apps only,” apps you haven't selected won't use the proxy just because the VPN icon is visible.
3. On Android 13, the usual path is Settings → Network & internet → VPN. Some manufacturers put this under “Connection & sharing” or a similar section; search Settings for “VPN” if you can't find it.
4. Open the client's app info in system settings. Under Battery or App battery usage, allow background activity as needed. If the connection drops only when the screen is locked, check battery optimization and background restrictions first.
5. If “Always-on VPN” or “Block connections without VPN” is enabled, make sure the client can reconnect reliably. The latter may block all network access when the VPN disconnects.

Usually, only one app using VpnService can be active for the same Android user or work profile at a time. Starting another VPN, a local-VPN-based filtering app, or a packet capture tool may replace the current connection. Check which VPN app Android has authorized instead of repeatedly reimporting the subscription.

No internet after enabling TUN? Troubleshoot by connection layer

First determine whether the node or traffic routing is failing

Turn off TUN, restore the system proxy, and use the same node to access the same destination. If it still fails, troubleshoot the node, subscription, or proxy group first. If the system proxy works but TUN does not, check permissions, routes, DNS, and other VPNs. This comparison narrows down the cause more effectively than changing ports, stack, and DNS all at once.

• Browser works, but games don't: Check whether the game's connections appear in the client, whether the node supports UDP, and whether the rules send the traffic to the intended proxy group. A working HTTP website does not prove that UDP traffic can reach its destination.
• IP addresses work, but domain names don't: Check DNS logs, system resolver settings, and secure DNS in the browser. nslookup example.com can help inspect DNS results, but its query path may differ from the browser's when encrypted DNS is enabled.
• LAN printer or NAS is unreachable: Check private IP routing, DNS resolution, and rules. LAN traffic needs to be routed directly or excluded correctly; adding a direct-connection rule alone may not fix an incorrect system route.
• Some pages take a long time to load: Check whether IPv4 and IPv6 use different routes, then investigate MTU. Don't apply a fixed MTU value without first checking for nested tunnels or path fragmentation.
• It only works again after restarting the client: Check for old services, duplicate core processes, and other active VPNs. Note when the error occurs; don't assume the stack is at fault based on symptoms alone.

Verification and rollback

A reliable check should provide three kinds of evidence: interfaces or routes change as expected; connections from apps without proxy settings reach the core; and the matched rules and final exit route are correct. A VPN icon, an open proxy port, or a node latency reading alone is not enough.

To roll back, turn off TUN in the client first and wait for its interface and routes to be removed. Then restore the system proxy if needed. On Android, check whether “Block connections without VPN” is enabled. If you still can't connect, look for leftover manual DNS or proxy settings and other VPNs. Don't delete network adapters unless you know what they're for.

Frequently asked questions