What Is Clash TUN Mode? How Virtual Adapters Take Over All Traffic

Why You Need TUN: Three Blind Spots of System Proxy

Most Clash clients default to system proxy mode: the core opens a local HTTP/SOCKS mixed port and writes that address into the OS proxy settings. This is simple to set up, but it has three structural blind spots.

• It only covers apps that voluntarily respect the setting. Whether traffic goes through the proxy is up to each app — only programs that actually read the system proxy setting will hand their traffic to the core. Plenty of command-line tools (git, curl, npm, docker), most games, and some desktop software ignore this setting entirely, bypassing the proxy completely.
• It only handles TCP. System proxy has no control over UDP or ICMP, so voice calls, online games, QUIC, and other UDP-based traffic never get intercepted.
• DNS still goes through your local ISP. Apps resolve domains on their own, and that resolution can be poisoned — a poisoned IP handed to the proxy afterward doesn't help.

TUN mode fixes this by moving the interception point from the application layer down to the network layer: the core creates a virtual network adapter, and the OS routes every outbound IP packet through it — completely transparent to the apps themselves.

How It Works: Virtual Adapters Taking Over All Traffic

TUN is a Layer 3 virtual network device provided by the OS — raw IP packets flow in and out of it. Its Layer 2 counterpart is TAP, which handles Ethernet frames instead. Clash-family cores (mihomo, etc.) use TUN.

Once TUN is enabled, the core does three things in sequence:

1. Creates the device. On Windows it loads the wintun driver to spin up a virtual adapter; on macOS it creates a utun device; on Linux it opens /dev/net/tun.
2. Takes over routing. It rewrites the system routing table so the default route points to the virtual adapter (auto-route), while also recording the physical adapter as the real exit interface (auto-detect-interface).
3. Processes packets one by one. The core reads IP packets off the virtual adapter, reassembles TCP sessions and builds forwarding mappings for UDP, then applies your rules (DOMAIN-SUFFIX, GEOIP, IP-CIDR, MATCH, etc.) to decide whether each connection goes to a proxy node, direct, or is rejected.

Choosing a Protocol Stack

Turning raw IP packets back into TCP/UDP streams requires a full TCP/IP stack, and mihomo offers three: gVisor is a userspace implementation with the best compatibility; system reuses the OS's own stack for lower overhead; mixed routes TCP through system and UDP through gVisor, a common middle ground. Desktop clients typically default to gVisor or mixed, and there's usually no need to change this for everyday use.

How It Pairs with fake-ip

TUN typically works alongside fake-ip mode. App DNS queries get intercepted by the core (dns-hijack), which returns a fake address from the 198.18.0.0/16 range and remembers its mapping to the real domain; when the app then connects to that fake address, the core looks up the real domain and routes it precisely by domain-based rules. This gives two direct benefits: it sidesteps local DNS poisoning, and it makes domain-based routing work even for traffic that only carries raw IP packets.

TUN Mode vs. System Proxy at a Glance

The two don't conflict. Most clients recommend keeping system proxy on as a fallback: apps that respect it use the application-layer path, while everything else gets caught by TUN at the network layer.

Setup Steps for Each Platform

Windows (using Clash Verge Rev as an example)

1. Open the Settings page and find Service Mode, then click Install. This service runs persistently in the background to create the virtual adapter, so the main app no longer needs to launch as administrator each time.
2. Go back to Settings and toggle on TUN Mode.
3. If your firewall blocks it the first time, allow the wintun virtual adapter through.

macOS

In Clash Verge Rev or ClashX Meta, toggle on TUN (Enhanced Mode). The system will prompt for your login password to install a privileged helper that creates the utun device. You only need to authorize once — the toggle won't ask again after that.

Linux

Creating a TUN device requires CAP_NET_ADMIN privileges. You either run the core as root, or grant the capability directly to the binary:

sudo setcap cap_net_admin,cap_net_bind_service=+ep /usr/local/bin/mihomo

Android and iOS

Mobile platforms don't have a separate toggle: Android clients (Clash Meta for Android, FlClash, etc.) run on the system's VpnService, while iOS clients (Clash Plus, etc.) use Network Extension's Packet Tunnel — both are essentially virtual adapter implementations by design. That's exactly why mobile clients can capture traffic from every app system-wide.

Manual Configuration (Advanced)

If you're maintaining a mihomo config file directly, the equivalent settings look like this:

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

auto-route takes over the default route, and auto-detect-interface identifies the real exit adapter — you need both. dns-hijack intercepts DNS queries on port 53 and routes them into the core.

When TUN Mode Is Worth Turning On

• Gaming and real-time voice: only TUN can intercept UDP traffic, provided your node supports UDP forwarding.
• Command-line and dev tools: git clone, curl, package managers, container image pulls — anything that ignores system proxy settings.
• Clients that don't respect proxy settings: certain regional apps, legacy software, and programs with hardcoded networking stacks.
• Per-process routing: once TUN takes over, the core can see which process a connection came from, enabling fine-grained routing with PROCESS-NAME rules.

On the flip side, if you mostly just browse the web, TUN won't make much of a difference — system proxy is already enough, so there's no need to enable it just for the sake of it.

Common Conflicts and Troubleshooting

Coexisting with Other VPNs or Accelerators

Every VPN-like tool wants to own the default route, so running two at once usually means their routing tables overwrite each other and both stop working. Keep only one tool as the active interceptor at a time; if you must run both, add your local subnet and the proxy server's address to the other tool's bypass list.

Traffic Loopback

If the core's own outbound traffic to the proxy server also gets routed back into TUN, it creates a loop — which shows up as a total network outage the instant TUN is enabled. auto-detect-interface exists specifically to bind the core's outbound traffic to the physical adapter, bypassing the virtual one. If you're editing the routing table manually, make sure the proxy server's IP always goes out through the physical interface.

Browser DoH Bypassing DNS Interception

Chrome and Edge's "Secure DNS" hands domain resolution off to a DoH server over port 443, which the core's dns-hijack can't intercept — this breaks fake-ip and shows up as domain-based rules simply not working in the browser. The fix is to turn off Secure DNS in the browser so resolution goes back through the core.

Can't Access Local Network Addresses

Once the default route is taken over, you may lose access to your office network, campus network, or router admin page. Add an IP-CIDR direct rule for your local subnet:

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

Virtual Machines, WSL2, and Docker

On Windows, the Hyper-V virtual switch can conflict with TUN's routing, cutting off WSL2 or blocking containers from reaching the internet. You can adjust the virtual adapter's interface metric so WSL2 traffic is routed correctly, or exclude the Hyper-V subnet in the client's settings.

No Internet Access at All After Enabling TUN

1. Confirm that both auto-route and auto-detect-interface are enabled.
2. Quit "Enhanced Mode," "Global Routing," or similar features in any other proxy tool, then try again.
3. Check the client logs to confirm the virtual adapter was created successfully with no permission errors.
4. If it's still not working, turn off the TUN toggle — most clients will restore the routing table automatically. If not, restart your network service or reboot your system.

FAQ

Conclusion

TUN mode moves proxy interception down from the application layer to the network layer: a virtual adapter catches every outbound IP packet, and the core routes each connection according to your rules. It solves exactly the three things system proxy can't reach — apps that ignore proxy settings, UDP traffic, and poisoned DNS. Stick with system proxy for everyday browsing; turn on TUN when you're dealing with gaming, command-line tools, or stubborn clients, and keep an eye out for conflicts with other VPN tools, browser DoH, and local subnets.