One of the first things people run into with Clash is this: why does my game still take a domestic route even with the proxy on? Why does git clone ignore the proxy? Why do command-line tools need to be configured separately? It all comes down to how system proxy works — it simply doesn't cover every application. TUN mode is the definitive fix, and this article will help you understand it inside and out.

The Limits of System Proxy

"System proxy" mode works by telling the operating system, "please send HTTP/HTTPS requests to the local address 127.0.0.1:7890." That approach comes with one fundamental catch: only applications that actively read the system proxy settings will honor it.

Browsers (Chrome, Firefox, Safari) follow the system proxy setting by default, but the following kinds of programs typically don't:

On top of that, a system proxy can only handle HTTP/HTTPS traffic — it can't deal with raw TCP connections or UDP traffic. That means even apps that supposedly "support proxies" will send their UDP traffic straight out, bypassing the proxy entirely.

How TUN Mode Works

TUN (Tunnel Network Interface) is a virtual network adapter interface provided by the operating system. Unlike a TAP interface (which operates at the link layer), TUN operates at the network layer (the IP layer), so it can read and write IP packets directly.

Clash's TUN mode works like this:

  1. Clash asks the OS to create a virtual network adapter (usually named Mihomo or utun0).
  2. It modifies the system routing table so that outbound traffic destined for specific IP ranges is redirected to that virtual adapter.
  3. The Clash core reads the raw IP packets off the virtual adapter and parses out the destination address and protocol type.
  4. For TCP traffic, Clash opens a local TCP connection to receive the data and then forwards it to a proxy node or direct connection according to your rules; UDP traffic is handled the same way.
  5. Data returning from the proxy node or direct server is re-encapsulated, written back to the virtual adapter, and handed to the OS to route to the application that made the request.

Because traffic is intercepted at the network layer rather than the application layer, the outbound packets of every program — whether or not it supports proxy protocols — get captured and processed. That's the fundamental reason TUN mode can deliver truly global proxying.

TUN mode has to create a virtual network adapter and modify the system routing table, and both operations require administrator privileges (a Windows UAC elevation prompt) or Root/sudo (Linux/macOS). This isn't the program "demanding excessive permissions" — it's simply how the OS security model works.

fake-ip: TUN Mode's DNS Solution

Under TUN mode, the way DNS is handled becomes critical — and it's also where things most often go wrong. Let's start with the traditional DNS flow:

App → DNS query: example.com → gets real IP 203.0.113.1 → opens a TCP connection to that IP

Here's the problem: when Clash intercepts a TCP connection request headed for 203.0.113.1 at the TUN level, all it sees is the IP address — it has no idea which domain that connection corresponds to. Yet Clash's rule system relies heavily on domain matching (DOMAIN-SUFFIX, DOMAIN-KEYWORD), and without the domain it can't route correctly.

fake-ip mode is the elegant way to solve this:

  1. The app sends a DNS query for example.com.
  2. Clash intercepts the query and immediately returns a fake IP (such as 198.18.0.1), recording the mapping 198.18.0.1 → example.com internally.
  3. The app takes the fake IP and opens a TCP/UDP connection to 198.18.0.1.
  4. Clash intercepts that connection request at the TUN level, looks up its internal mapping table, and knows the real target is example.com.
  5. Clash decides whether to proxy or go direct based on the domain rules. If it proxies, the actual DNS resolution happens on the proxy node at the destination; if it goes direct, Clash re-queries the real DNS before establishing the connection.

The key advantages of fake-ip: DNS queries for sensitive domains are resolved entirely on the proxy side, which fully prevents DNS leaks; and because Clash holds the domain information, rule matching becomes far more accurate.

Enabling TUN Mode

Clash Verge Rev (Windows / macOS)

  1. Open the client and click the Settings icon on the left.
  2. Find the TUN Mode (or "Tun Mode") toggle and turn it on.
  3. A permission prompt appears — on Windows click "Yes," and on macOS enter your system password to confirm.
  4. The first time you enable it, the virtual network adapter driver (Mihomo) is installed in the background; give it 5–10 seconds.
  5. The client status changes to "TUN active," and from that point on all outbound traffic is handled by Clash.

Full YAML Config (Mihomo core)

tun:
  enable: true
  stack: mixed        # mixed / system / gvisor
  dns-hijack:
    - any:53          # hijack all DNS queries
  auto-route: true
  auto-detect-interface: true

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
    - "+.stun.*.*.*"
  nameserver:
    - https://1.1.1.1/dns-query    # Cloudflare DoH
    - https://8.8.8.8/dns-query    # Google DoH
  fallback:
    - https://1.0.0.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

TUN Stack Modes Explained

TUN's stack parameter determines how captured network packets are processed, and it directly affects performance, compatibility, and stability:

Common Issues & Troubleshooting

Can't reach LAN devices (printer, NAS, router admin page)

TUN mode uses auto-route to take over all traffic, so traffic to LAN IP ranges also gets routed to the proxy egress and naturally can't reach your local devices. Just add the following direct-connection rules at the very top of your rules file:

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
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  # ... other rules

Network drops after closing Clash

Always turn off the TUN toggle in settings before quitting Clash, so the program has a chance to clean up its routing table entries. If you're already cut off: reopen Clash → turn off TUN → then quit the program. Alternatively, open Device Manager (Windows), disable the virtual adapter named Mihomo, and restart your network to recover.

The fake-ip-filter allowlist isn't enough

Local development domains (such as localhost or *.test), corporate intranet domains, and the special service domains of some apps can fail to connect if they get processed through fake-ip. Add these domains to the fake-ip-filter list and Clash will perform a real DNS resolution for them instead of returning a fake IP.

CPU usage rises after enabling TUN mode

This is expected. TUN mode has to process every network packet in user space, so its CPU overhead is 10–30% higher than system proxy mode. If CPU usage is abnormally high (over 20%), try switching the stack from gvisor to mixed, and check whether a lot of UDP traffic (such as P2P) is currently flowing through Clash.

Conclusion

TUN mode is Clash's most powerful and most complete proxy mode. By intercepting all traffic at the network layer through a virtual network adapter, and pairing that with the fake-ip DNS mechanism for precise domain-based routing, it completely solves the limited coverage of system proxy mode.

For everyday browser use, system proxy mode is plenty; but if you need to proxy games, command-line tools, or the traffic of every app, TUN mode is the only real choice. With LAN direct-connection rules and a fake-ip-filter allowlist set up properly, TUN mode runs very reliably.