#TUN Mode vs. System Proxy: Interception Layers, Compatibility, and How to Choose

How System Proxy Works: Voluntary Cooperation at the App Layer

System proxy is essentially a set of environment variables or registry entries provided by the OS, recording "where HTTP traffic should be sent" — address and port. When a Clash-family client enables the system proxy, it points these settings to the port it's listening on: port (HTTP) or socks-port (SOCKS5). Browsers and most desktop apps with network settings read these values before making a request, actively connecting to Clash's listening port, which then routes the connection according to its rules.

The key word here is "voluntary." This mechanism depends on apps actively reading and honoring the proxy settings. Once a program doesn't read the system proxy — older Java programs, some game clients, or CLI tools that ignore environment variables by default — its traffic goes straight out through the physical network card, completely bypassing Clash's rule evaluation. This isn't a flaw in Clash; it's an inherent boundary of the system-proxy approach itself — it can only manage processes willing to cooperate.

How TUN Mode Works: A Virtual Adapter at the Network Layer

TUN mode takes a completely different approach — instead of persuading apps at the application layer, it attaches a virtual network interface directly at the OS network layer. Once enabled, Clash Meta (the mihomo core) creates a virtual adapter named utun (macOS), Meta, or something similar (Windows/Linux), and by modifying the system routing table, directs the default route or specific subnets' traffic to this virtual adapter.

From that point on, what the OS sees isn't "should this app use the proxy," but "which network card should this packet go out through" — a decision made at the kernel routing layer, independent of whether the app is proxy-aware. Once a packet enters the virtual adapter, the mihomo core parses it in user space, reconstructs it into a TCP/UDP connection, and forwards it according to the proxy rules. Because the decision point has moved down to the network layer, almost all traffic from every process gets captured by this virtual adapter — there's no such thing as "a program that won't cooperate."

# Basic fields for enabling TUN mode in config.yaml
tun:
  enable: true
  stack: system   # options: system / gvisor / mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

Here stack determines how the virtual adapter is implemented: system uses the OS's native TUN/TAP driver, offering better performance but with some OS version requirements; gvisor is a user-space network stack with better compatibility but slightly lower throughput; mixed is a middle-ground option offered by newer kernels. auto-route handles writing to the routing table automatically — turning it off requires manual route configuration, so non-advanced users should generally leave it on.

Coverage and Compatibility Differences

In terms of coverage, system proxy can only manage processes that actively read proxy settings — typically browsers and most desktop apps' network requests. System-level services, some background processes, CLI tools, and game clients' networking modules often don't read the system proxy at all, so their traffic bypasses it entirely. TUN mode, working at the routing layer, can in theory capture all traffic based on the IP stack, including processes that "don't recognize" proxies.

But broader coverage doesn't come without compatibility trade-offs. Watch out for these scenarios:

• Virtual machine and container networking: If a VM uses NAT or bridged networking, its traffic path may conflict with the host's TUN routing table, causing the VM to lose connectivity or take the wrong path. Usually you need to exclude the VM's subnet under route-exclude-address.
• Local network access: With TUN enabled, accessing a local printer, NAS, or router admin page can fail if direct-connect rules or LAN exceptions aren't configured correctly — the traffic may be mistakenly routed through the proxy.
• Running alongside other VPN software: Two virtual adapters competing for the default route often leads to conflicts or disconnections. Running a system-level VPN and Clash's TUN mode at the same time is generally not recommended.
• Admin/system privileges required: Creating a virtual adapter and modifying the routing table are system-level operations. TUN mode needs administrator rights on Windows, and typically sudo or an equivalent permission grant on macOS/Linux — unlike system proxy, which is just a toggle switch.

By contrast, system proxy doesn't touch the routing table or a virtual adapter, so it rarely conflicts with VMs or other VPNs, and its permission requirements are lower — that's its compatibility advantage. Its only downside is incomplete coverage.

Performance Overhead and Stability Compared

System proxy's forwarding path is fairly short: the app connects directly to Clash's listening port, Clash evaluates the rules and forwards to the target server, passing through just one user-space proxy layer. The overhead mainly comes from rule matching and encryption/decryption, which has minimal impact in most bandwidth scenarios.

TUN mode adds an extra step of "network-layer interception + protocol reconstruction": a packet enters the virtual adapter first, gets processed by the kernel network stack, then handed to the mihomo user-space process to be parsed into a full TCP/UDP session before going through the proxy rules and forwarding logic. This process involves one more data copy between kernel space and user space compared to system proxy, which in theory adds a slight amount of latency and CPU usage — the exact magnitude depends on the stack choice, with the system stack usually coming closer to system-proxy-level performance than gvisor. For everyday browsing or video streaming, this difference is barely noticeable; but for scenarios with lots of small packets and high concurrency (some download tools, blockchain node syncing), the gap becomes more visible.

On stability, issues with system proxy usually show up as "one specific app isn't going through the proxy" — limited scope, easy to pinpoint. Issues with TUN mode can instead show up as widespread connectivity loss caused by routing table problems, and the fix is to disable TUN or restart networking services — harder to troubleshoot. That's why most clients tuck TUN mode away under "advanced settings" rather than enabling it by default.

Choosing the Right Mode: CLI Tools, Games, and UWP Apps

Different app types support proxy settings to very different degrees. Here's guidance for a few typical scenarios.

CLI Tools (curl, git, package managers, etc.)

Most CLI tools don't read the system proxy by default — they rely on explicitly set environment variables, for example:

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"

If setting environment variables one by one feels tedious, or a tool doesn't even recognize environment variables (some statically compiled Go/Rust tools), enabling TUN mode is the easier route — no need to configure each tool individually; the virtual adapter handles everything uniformly.

Game Clients

Many games run the launcher and the game itself as two separate processes, and rely heavily on UDP (especially real-time sync data in competitive games). System proxy's limited UDP support usually only covers the launcher's login step, while in-match traffic still goes through the physical network card. If you need in-match traffic to also follow your rules — say, routing through a dedicated node to cut latency — TUN mode is essentially the only reliable path, since it uniformly handles both TCP and UDP at the network layer. Be sure to put your game-acceleration node in its own group in the rules, so game traffic doesn't get starved of bandwidth by heavy-traffic groups like movies or downloads.

UWP Apps (Windows Store Apps)

UWP apps on Windows run inside an isolated Network Isolation container, and by default neither read the system proxy nor fall within TUN mode's normal routing capture — this is sandbox isolation by Windows design, not an oversight in the Clash client. To get a UWP app (say, a Store-version browser or chat app) to go through the proxy, you typically need to run a CheckNetIsolation.exe command to allow that app through network isolation, or find a switch in the client along the lines of "allow UWP loopback/network access." This step is required regardless of mode — neither system proxy nor TUN mode is inherently more compatible here.

Which to Choose: A Simple Decision Guide

If your daily usage centers on browsers and regular desktop apps, system proxy already covers the vast majority of cases — simple to configure and easy to troubleshoot, making it the more hassle-free default. Consider switching to TUN mode if any of these apply: you frequently need CLI tools to use the proxy but don't want to set environment variables one by one; games or voice calls need their UDP traffic routed by rule; or some process clearly ignores the system proxy, rendering your rules pointless. Before switching, check whether your VM or other VPN software might conflict with the virtual adapter's routes, and make sure your client's LAN direct-connect rules are configured correctly to avoid breaking access to local network devices after enabling TUN.