How TUN Mode Works and How to Enable It: Full Traffic Takeover Done Right

A system proxy is an OS-level setting. In practice it writes a set of proxy addresses into the system or an app's runtime environment (environment variables like HTTP_PROXY / HTTPS_PROXY, or Windows' WinINet/WinHTTP settings, or macOS Network preferences). Only when a program actually reads that configuration and routes its own traffic to the proxy port does it count as "going through the proxy." It's a **cooperative** form of forwarding — whether the proxy takes effect depends entirely on whether the target program plays along.

TUN mode works completely differently. When Clash Meta (mihomo) enables TUN, it creates a virtual network adapter on the system (backed by the Wintun driver on Windows, or a utun/tun0 device on macOS/Linux) and points the system's default route at that virtual adapter. From then on, every IP packet that passes through the network layer — regardless of which process sent it or whether that process even knows a proxy exists — is intercepted by the virtual adapter first and handed to the Clash core for rule-based processing. This is a **forced takeover at the network layer**, with no cooperation from any program required.

In short: system proxy controls "whether traffic is willing to go through," while TUN mode controls "traffic goes through me no matter what."

In the following scenarios, a system proxy simply won't work — only TUN mode covers them:

• UDP-based protocols. The system proxy mechanism is built around HTTP/HTTPS (TCP-based). Many online games, VoIP calls, and some video-conferencing apps use UDP directly and never read the system proxy configuration.
• CLI tools and background services. Many CLI tools (package managers, some build scripts) and system daemons don't check proxy environment variables at all, or need an extra --proxy flag to use one — fiddly to configure and easy to miss.
• Apps with hardcoded socket connections. Some desktop and mobile apps call low-level socket APIs directly, bypassing system proxy settings entirely — common in some messaging and cloud-sync tools.
• ICMP and other non-standard protocols. ICMP-based traffic like ping and traceroute, along with some P2P protocols, also fall outside what a system proxy can handle.
• Traffic inside VMs and containers. The host's system proxy usually doesn't propagate to virtual machines or containers automatically, whereas TUN mode intercepts at the host's routing layer and, combined with the right network mode settings, can cover this traffic too.

If you notice an app "still connecting directly even with the proxy on," it's most likely one of the cases above — and enabling TUN mode is the most direct fix.

Because TUN mode has to create a virtual adapter and modify the system routing table, all three major platforms require elevated permissions — though the specifics differ.

sudo modprobe tun
sudo setcap cap_net_admin=eip /path/to/mihomo

Once TUN mode is enabled, DNS queries are intercepted by the virtual adapter too — and this is where things most often go wrong. Your config usually needs to explicitly declare a DNS hijacking and resolution strategy:

tun:
  enable: true
  stack: system
  dns-hijack:
    - "any:53"
  auto-route: true
  auto-detect-interface: true
dns:
  enable: true
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

dns-hijack forces all outbound DNS requests on port 53 to be intercepted and handled by the Clash core, preventing traffic from bypassing the rules and connecting directly to a censored or otherwise unreliable DNS server. fake-ip mode assigns each domain a fake IP within a private address range; apps see this fake IP, and the core only swaps in the real outbound address once the connection is actually established. The benefit is that rules can match by domain name without waiting on the real DNS resolution result.

Common troubleshooting angles:

• DNS leaks. If DNS requests from direct traffic aren't being intercepted (for example, the browser is still using the OS's native DNS), check whether dns-hijack covers the right port, and whether your OS network settings have a fixed DNS server manually specified that's conflicting.
• Routing loops. Under TUN mode, the connection to the proxy server itself must not be routed back through the TUN adapter, or you'll get a "proxy connecting to itself" infinite loop. Clients usually avoid this through auto-detect-interface or explicit process exclusion rules — when configuring manually, always make sure this option is enabled.
• Conflicts with VPN clients. Running TUN mode and another VPN app at the same time means both are fighting over the default route, which shows up as one of them intermittently failing. It's best not to run both at once.

After enabling TUN mode, verify it in the following order rather than trusting the toggle's on/off state alone:

1. Check that the virtual adapter exists. On Windows, open "Network Connections" and look for a new adapter named something like "Mihomo" or "Clash." On macOS/Linux, run ifconfig or ip addr to check for a utun / tun0 device.
2. Check the default route. Use route print on Windows, or netstat -rn / ip route on macOS/Linux, to confirm the default route points to the virtual adapter rather than the physical one.
3. Test with a tool that ignores the system proxy. For example, run curl in a terminal without any proxy flags, or ping a domain from the command line that your rules say should be proxied, and see whether it takes the expected route.
4. Check the client's connection log. Most clients label each connection's inbound type in the "Connections" or "Logs" panel. Connections under TUN mode are usually tagged TUN rather than HTTP/SOCKS — a reliable way to confirm which path is actually in effect.

If all of the above checks out but a specific app still isn't being proxied, it's most likely bound to a fixed network interface at the OS level or using a custom DNS resolver. Troubleshoot that program's own network settings rather than continuing to adjust the Clash config.