System proxy is Clash's most basic traffic interception method — it configures the OS HTTP/SOCKS5 proxy settings to route traffic from proxy-aware applications into Clash. However, system proxy has an inherent limitation: game clients, command-line tools, and other programs that establish network connections directly are not controlled by it. Clash's official TUN mode intercepts all system traffic at the network layer using a virtual network interface, and is the official solution for achieving true global transparent proxying.
How TUN Mode Works
TUN (Network Tunnel) is a virtual network interface mechanism provided by the operating system, working at Layer 3 (the Network Layer) of the OSI model. When TUN mode is enabled, Clash creates a virtual network interface named utun (macOS) or Meta (Windows/Linux) in the system and modifies the routing table to direct all outbound IP traffic into this virtual interface.
Once traffic enters the virtual interface, Clash parses it in user space, identifies the target address, decides whether to proxy or connect directly based on the rule configuration, and then sends it out through the actual physical network interface. The entire process is completely transparent to applications — no configuration is required on their end.
Compared to TAP mode (which works at Layer 2 — the Ethernet frame level), TUN mode does not need to handle ARP, Ethernet headers, or other Layer 2 details, resulting in better performance and easier cross-platform compatibility.
How to Enable TUN Mode
There are two ways to enable TUN mode. Graphical clients typically provide a TUN toggle in the settings page. In Clash for Windows, for example, you must first install "Service Mode" in the General settings, then enable the "TUN Mode" switch. Installing Service Mode requires administrator privileges so that Clash can run as a system service and gain permission to modify the routing table.
Alternatively, you can declare the TUN configuration directly in the config file:
tun:
enable: true
stack: mixed
dns-hijack:
- any:53
auto-route: true
auto-detect-interface: true
Choosing Between Three TUN Stack Modes
The Mihomo core offers three TUN protocol stack implementations, each with its own trade-offs:
- system: Uses the operating system's native TCP/IP stack directly. Highest performance with the smallest CPU and memory overhead, but may experience compatibility issues on some system configurations.
- gvisor: Uses the user-space TCP/IP stack from Google's gVisor project. Completely isolated from the OS kernel, offering the best compatibility — ideal for troubleshooting or use in special environments — but slightly lower performance than system mode.
- mixed: TCP connections use the system stack; UDP connections use the gVisor stack. Combines the best of both — TCP performance close to native, and good UDP compatibility. This is the currently recommended choice and performs best in the vast majority of scenarios.
DNS Hijacking and Leak Prevention
The dns-hijack: [any:53] configuration is critical. It forcibly redirects all DNS requests sent to port 53 on any IP address to Clash's built-in DNS module for processing.
Why is DNS hijacking necessary? In TUN mode, if an application sends DNS requests directly to 8.8.8.8:53 (bypassing the system DNS settings), those requests will go out through the physical interface without passing through Clash's rule engine. This can cause DNS leaks (exposing your real browsing history) and prevent certain domains from being correctly routed to the proxy node. With DNS hijacking enabled, all DNS requests are handled centrally by Clash, and combined with Fake-IP mode, you get the best possible DNS hijacking/spoofing protection.
Verification and Troubleshooting
After enabling TUN mode, you can verify it is working correctly by running curl -I https://www.google.com in a terminal — if you receive a normal HTTP response header, command-line tool traffic is going through the proxy. You can also check the Connections page in Clash to see all connections intercepted by TUN in real time, including programs that system proxy could not previously cover.
If the network becomes completely unreachable after enabling TUN, the most common cause is that auto-detect-interface failed to correctly identify the outbound network interface. You can specify it manually:
tun:
enable: true
stack: mixed
auto-route: true
interface-name: en0 # macOS physical interface name; on Windows it is usually Ethernet or Wi-Fi