How Clash TUN Mode Works: Virtual Adapters, Global Traffic Capture & Setup Guide

NT-02.1Why System Proxy Doesn't Cover Everything

Clash's default mode is system proxy: the client writes an HTTP/HTTPS proxy address into the OS network settings, and the operating system passes that address along to applications, which then decide whether to honor it. That word "honor" is the key — system proxy is essentially a suggestion, not a forced redirect. Most GUI browsers and mainstream chat apps read the system proxy setting and comply, but command-line tools (`curl`, `git`, `ping`), some games, older clients, and certain Android/iOS apps often bypass the system proxy setting entirely and send packets straight through the OS's low-level network interface.

This leads to a familiar scenario: your browser's proxy speed test passes and the target site loads fine, but running `curl` on the same address from a terminal just times out. Or an app has "use system proxy" checked in its settings, yet packet captures show the traffic never touched the proxy port at all. This isn't a misconfiguration — it's the inherent limitation of the system proxy mechanism, which only reaches processes that are willing to read and respect that setting.

TUN mode exists specifically to close that gap. Instead of relying on applications to "voluntarily" read the proxy setting, it creates a virtual network adapter at a lower layer of the OS network stack and points the system routing table at it, so almost no outbound traffic can slip past.

NT-02.2How the Virtual Adapter Captures Traffic

TUN (short for tunnel device) is a virtual network interface type provided by the operating system. Like a physical NIC or Wi-Fi adapter, it shows up in the system's list of network interfaces and has its own IP address, but there's no real physical link behind it — packets sent to and from it go straight to the user-space program that created it. When Clash Meta (the mihomo core) enables TUN mode, it creates one of these virtual adapters and adjusts the system routing table so the default route, or specific subnets, get directed there.

From that point on, every IP packet an application sends — whether or not it "knows" a proxy exists — gets evaluated by the system's routing logic first and handed off to the TUN adapter. The mihomo core reads these raw packets in user space, reconstructs the destination address and protocol info, matches them against the rule set to pick a policy group, and forwards them through a real network interface to the selected node. Return traffic follows the reverse path back through the TUN adapter to the requesting process. The whole thing is transparent to the application — it thinks it's talking directly to the target server, but every packet is actually being evaluated against the rules first.

This is also why TUN mode is often called "transparent global proxying": it operates at the network layer, while system proxy works at the application-protocol layer (HTTP/SOCKS). A lower layer means broader coverage, but it also means troubleshooting requires a mental shift — instead of asking "does this app have a proxy option," you start asking "is this device's traffic being routed correctly."

NT-02.3Three Config Options to Understand Before Enabling It

TUN mode isn't a single flip-and-forget switch. The config file usually involves the following options, and understanding what they mean up front can save a lot of troubleshooting later.

1. enable: the master switch for TUN, a boolean. The virtual adapter only gets created once this is turned on.
2. stack: selects the user-space network stack implementation, typically system, gvisor, or mixed. Support varies by core version — start with whatever the docs recommend as default, and only switch to compare if you hit compatibility issues.
3. dns-hijack: whether TUN intercepts DNS queries at this layer, usually written as a listen address plus port (e.g. any:53). This setting is directly tied to DNS handling below — get it wrong and you'll see broken domain resolution or rules that silently fail to route traffic.

TUN mode still relies on the same rule set for routing decisions and shares the same rules config as system proxy mode — the difference is only in how traffic gets fed into the core, not how the core decides where it goes. In other words, enabling TUN won't break your existing rules, but it may surface traffic that system proxy mode was never catching before.

NT-02.4Setup Steps by Platform

The UI entry point differs across clients, but they're all calling the same mihomo core TUN parameters under the hood, so the underlying logic is identical.

Windows

1. Confirm the client is running on the Clash Meta / mihomo core — some clients built on the older Clash core don't support TUN at all.
2. Find the "TUN Mode" or "Tun Mode" toggle in the client settings. The first time you enable it, you'll usually be prompted for admin rights — allow it.
3. If the client was launched without admin rights and the toggle doesn't do anything, relaunch it with "Run as administrator."
4. Once enabled, you'll see a new virtual adapter show up in the system's Network Connections list, typically named something with Mihomo or Meta in it.

macOS

1. Enable TUN mode in the client settings, and macOS will prompt for "Network Extension" or "System Extension" authorization.
2. Go to System Settings → Privacy & Security, or System Settings → Network → VPN & Filters, and manually allow the extension. The exact location varies slightly between macOS versions.
3. Once authorized, toggle TUN back on. If the network extension permission was already handled during installation, you can usually skip this step.

Android

1. On Android, TUN mode taps into the system's VPN service API, so enabling it triggers a system "Connection request" authorization dialog — just tap Allow.
2. After authorization, a VPN icon stays in the status bar. That's a normal system-level indicator, not a sign of a problem.
3. If you have another VPN app installed, keep in mind Android generally only allows one active VPN service at a time, so the two will keep overriding each other.

Linux

1. Creating a TUN device requires CAP_NET_ADMIN capability, so GUI clients typically need to launch the core process with sudo or an equivalent elevation method.
2. If you run the mihomo core from the command line without the right permissions, the log will report a failure to create the TUN device — check how you're launching it.
3. Some distros ship with a firewall enabled by default (ufw, firewalld, etc.) — make sure there's no extra rule blocking forwarding on the virtual adapter.

NT-02.5Common Issues After Enabling TUN

TUN mode introduces a new routing layer, and the following issues come up most often.

• No internet at all after enabling TUN: usually the routing table got fully taken over, but either the rules have a misconfiguration or the core process crashed, leaving the virtual adapter "holding the route without actually forwarding." Try disabling TUN to fall back to system proxy and confirm the base connection works, then troubleshoot the TUN config section separately.
• Can't reach some local network devices: once TUN takes over all routing by default, access to LAN devices like printers or NAS boxes can break. You'll need to add a DIRECT policy for local subnets (e.g. 192.168.0.0/16, 10.0.0.0/8) in the rules to keep them out of the proxy route.
• Conflicts with other VPN software: if the same device is also running a corporate VPN or another virtual-adapter-based tool, the two may fight over the default route, showing up as intermittent disconnects or routing flips. Keep only one virtual-adapter tool active at a time.
• DNS resolution issues: without dns-hijack and fake-ip configured together, domain resolution may still go through your machine's original DNS, causing domain-based routing rules to silently fail — you'll be online, but traffic won't route the way you expect.

NT-02.6When TUN Makes Sense — and When It Doesn't

TUN mode isn't a "the more global, the better" setting. Whether to enable it depends on what you actually need.

• If you need command-line tools, dev environments, game clients, or other non-browser programs to go through the proxy, TUN is currently the most reliable option.
• If your daily use is mostly a browser and mainstream chat apps that all correctly respect the system proxy setting, sticking with system proxy mode is simpler and easier to troubleshoot when something goes wrong.
• On corporate networks or devices with an always-on VPN client, enable TUN carefully — check first that it won't conflict with existing network policies.
• If battery life or stability on mobile is a concern, validate your rule set on desktop first before deciding whether to leave TUN running long-term on your phone.

In short, TUN mode solves the "coverage" problem, while system proxy handles the "good enough for daily use" scenario. Once you understand how the two differ at the network-stack level, you can quickly figure out which mode to switch to when "this one app isn't going through the proxy" — instead of just restarting the client over and over hoping it fixes itself.