Clash TUN Mode vs System Proxy: How Traffic Interception Differs

Start With How Each Interception Method Actually Works

Before you touch a single toggle in Clash, it helps to understand how traffic actually gets "hijacked" into the proxy engine in the first place. Clash and its popular fork Clash Meta (mihomo) offer two fundamentally different approaches: system proxy and TUN mode. Both aim to solve the same problem — routing outbound requests from your device into Clash's rule engine before forwarding them — but they intervene at completely different layers, which directly shapes their coverage, compatibility, and setup effort.

A system proxy is a configuration interface exposed by the operating system itself. In essence, it tells any app that supports the setting: "send your HTTP/HTTPS requests to this address and port first." Windows and macOS both have built-in system proxy settings, and browsers, some download managers, and IDE networking components read from this configuration. TUN mode takes a completely different approach. It creates a virtual network interface inside the OS, which the system treats as a real network exit point. Any IP packet that the routing table decides should go through this exit — regardless of which process created it or what protocol it uses — flows into this virtual adapter first, where the Clash core parses it, matches rules, and forwards it to the right node.

System Proxy: Lightweight but Full of Gaps by Design

System proxy wins on simplicity, low resource usage, and quick on/off switching — it's usually the first method anyone tries with Clash. But it only works because apps have to actively "cooperate": each program reads the proxy address from the system or an environment variable and connects to it on its own to relay requests. That means only apps that follow this convention actually get intercepted correctly.

This is exactly where the problem lies. Not every networked app respects system proxy settings. Common cases where traffic slips past the proxy include:

• Many CLI tools and background services ignore the system proxy environment variables entirely and require manually setting HTTP_PROXY/HTTPS_PROXY.
• Some apps hardcode direct connections or use non-standard ports, making system proxy settings completely irrelevant to them.
• UDP traffic — think real-time communication apps or certain game acceleration scenarios — usually falls outside what system proxy can intercept, since it's designed mainly around TCP-based HTTP/HTTPS requests.
• Mobile app ecosystems are even more fragmented; many apps call low-level system networking APIs directly, skipping application-layer proxy configuration altogether.

In other words, system proxy is more of a "gentleman's agreement": cooperative apps forward traffic properly, while uncooperative ones just connect directly regardless. This is exactly why some users see Clash running fine yet a specific app still shows "not connected to proxy" or produces unexpected results — it's rarely a rule mistake; it's usually that the app never went through the system proxy path to begin with.

TUN Mode: Unified Interception at the Network Layer

TUN mode takes a much more thorough approach. It doesn't rely on whether an app "wants" to cooperate — instead, it inserts a virtual network adapter directly into the OS network stack and, combined with routing table rules, redirects nearly all qualifying IP packets on the device into this virtual interface. Once packets enter the virtual adapter, the Clash Meta (mihomo) core handles protocol parsing in userspace (commonly implemented via gVisor or the system's native stack), domain matching, and rule evaluation, then decides which proxy node — or direct connection — to route through.

Because interception happens at the network layer rather than the application layer, TUN mode is largely app-agnostic. Browsers, CLI tools, game clients, and even the OS's own background services all get managed uniformly as long as their traffic matches the routing rules — including UDP traffic that system proxy simply can't touch. That's why anyone who needs fine-grained routing for games, voice chat, or cross-platform clients eventually ends up switching to TUN mode.

The Real-World Trade-offs in Compatibility and Stability

Broader coverage doesn't come free. Since traffic is intercepted at the network layer, passed through a userspace protocol stack, and then forwarded onward, packets go through an extra layer of encapsulation and parsing. This adds a small performance overhead in theory, which may be noticeable on low-end devices or in latency-sensitive scenarios. There's also potential for the virtual adapter to interact with your local routing table, firewall rules, and VPN clients:

• If another VPN app or virtual networking tool is running at the same time, routing table conflicts can occur, sending some traffic down unexpected paths. Avoid running multiple virtual-adapter-based tools simultaneously.
• Some corporate network environments or security software may flag or block newly added virtual network interfaces. Check your network's policies before enabling TUN mode for the first time.
• Different operating systems implement TUN devices differently — Windows relies on the Wintun driver, macOS uses its Network Extension framework — so setup steps and permission prompts vary slightly, though the end-user toggle experience is largely the same.

By comparison, system proxy carries none of these low-level risks: settings take effect instantly and revert instantly when turned off, and troubleshooting is more straightforward — it's almost always a case of some app not reading the proxy settings. That's why system proxy remains the default choice for plenty of lightweight use cases.

Coverage at a Glance

Which Apps Tend to Bypass System Proxy

If a specific app's traffic never seems to follow your proxy rules, it's usually one of the following:

1. CLI and dev tools: Package managers and build tools, for example, often don't read system proxy settings by default and need their proxy options or environment variables configured separately.
2. Apps with their own custom networking stack: Some messaging and cloud sync apps implement their own connection logic for speed, bypassing the system proxy interface entirely.
3. Games and voice chat: Most games rely on UDP for real-time data transfer, and system proxy's UDP support is generally weak or nonexistent — this kind of traffic essentially requires TUN mode to intercept at all.
4. System background services and updaters: OS-level update checks and telemetry reporting processes typically don't respect user-configured proxy settings.

Rather than hunting down proxy settings in every individual app, it's usually faster to switch to TUN mode and solve the "incomplete coverage" problem once, at the network layer.

When You Should Switch to TUN Mode

Based on the comparison above, here's a reasonably clear rule of thumb:

• If you're just browsing the web and only have a handful of apps that need proxying, system proxy is more than enough — and far less hassle to set up.
• If your device runs a lot of apps that ignore system proxy conventions (CLI tools, games, certain chat apps), or you need rule-based routing for UDP traffic, TUN mode is the more complete solution.
• If you need per-process traffic splitting (say, letting one app connect directly while everything else goes through the proxy), TUN mode combined with Clash Meta (mihomo) process rules (process-name) offers a level of granularity that's impossible at the application layer.
• In corporate networks or environments with strict security software, confirm whether the virtual adapter will get blocked before enabling TUN mode, so you don't disrupt your normal work network.

How the Configuration Actually Differs

From a config file perspective, system proxy needs no extra declaration in your Clash config — it's controlled by a toggle in the client UI that calls a system API directly. TUN mode, on the other hand, usually requires explicitly declaring related fields in the config, such as whether it's enabled, which protocol stack to use, and whether it takes over DNS. Here's a common example from Clash Meta (mihomo):

tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53
  auto-route: true
  auto-detect-interface: true

auto-route controls whether the routing table is automatically configured to send traffic into the virtual adapter, while dns-hijack takes over DNS queries so certain domain resolutions don't slip past rule matching. Most GUI clients already wrap these fields into simple toggles, so most users never need to hand-edit the config — but knowing what they do helps when troubleshooting occasional connection glitches.

Quick Answers to Common Questions

Do I still need system proxy once TUN mode is on? Generally not — TUN mode's coverage already includes everything system proxy handles, and running both at once can confuse routing decisions. Pick one.

Does TUN mode slow down all my traffic? There's some overhead from the extra encapsulation and parsing, but on most modern devices it's barely noticeable. Speed differences you notice are far more likely caused by the proxy node's line quality than by the interception method itself.

Is there a TUN mode equivalent on mobile? On Android, it's typically implemented through the VpnService API, which works conceptually the same way as a desktop virtual adapter and can intercept traffic that app-layer methods miss. On iOS, similar functionality relies on the Network Extension framework.