TUN Mode vs System Proxy: How the Two Traffic Interception Methods Differ

The Fundamental Difference Between the Two Mechanisms

Clash clients offer two ways to route traffic through a proxy: System Proxy and TUN mode. Many people treat these as a simple "which one is better" toggle, but they actually operate at completely different layers and solve different problems. Understanding this difference explains why some apps ignore your proxy settings entirely, while some command-line tools simply refuse to connect no matter how you configure them.

System proxy is a configuration interface provided by the operating system — essentially it just writes an "HTTP/HTTPS proxy server address" record into the system or browser settings. It operates at the application layer: only programs that choose to read this setting and forward requests to that address will actually route traffic through the proxy. Programs that don't read this setting continue using their normal network path, entirely unaffected by the proxy.

TUN mode works completely differently. The client creates a Virtual Network Interface on the system and modifies the routing table so that most or all outbound traffic on the device is first sent to this virtual interface, then handed off to the Clash core for processing. This happens at the network layer and doesn't depend on any app cooperating — as long as a packet leaves the device, it passes through the virtual interface, regardless of what program generated it or what protocol it uses.

How System Proxy Works — and Its Limits

System proxy's implementation breaks down into three steps: the client starts an HTTP/SOCKS mixed port (Clash's default mixed-port is typically 7890), the client writes this port into the system or browser proxy settings, and applications query this setting when making requests and forward them to that port. The key is step three — forwarding only happens because the app chooses to cooperate, not because the system enforces it.

Most GUI browsers and mainstream desktop apps properly read system proxy settings, so system proxy mode is plenty for everyday web browsing, chat apps, and most desktop software. But it has several clear limitations:

• Programs that don't follow system proxy settings are unaffected — common with some CLI tools, some game clients, and apps that connect directly using custom networking libraries.
• It only covers HTTP/HTTPS and some SOCKS traffic, not UDP-heavy protocols (such as certain games or video calls that rely on UDP), unless the program itself supports SOCKS5 UDP forwarding.
• It depends on PAC files or system-level configuration entries, and implementation details differ across operating systems — macOS, Windows, and various Linux desktop environments each have their own proxy configuration paths with slightly different behavior.

How TUN Mode Intercepts Traffic at the Network Layer

TUN stands for Tunnel virtual network device — a network interface type provided by the OS kernel that behaves almost exactly like a real network card: it has its own IP address, can be referenced by the routing table, and can be matched by firewall rules. The difference is that it isn't connected to physical hardware; packets sent and received through it are read and processed by a user-space program — in this case, the Clash / Clash Meta core.

When TUN mode is enabled, the client does three things: creates a virtual network interface and assigns it an internal IP, points the system's default route (or part of it) to this virtual interface, and takes over packets arriving through this interface within the kernel, forwarding them according to proxy rules. Since routing already directs traffic to the virtual interface, any program that sends requests through the system's network stack gets intercepted at this layer, whether or not it even understands the concept of a "proxy." This is why TUN mode is often described as global traffic interception.

A concrete config snippet illustrates this layer difference — here are the common TUN-related fields in a Clash Meta (mihomo) config:

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

auto-route automatically writes routing table entries, while dns-hijack intercepts DNS queries and processes them within the core as well, preventing a scenario where traffic goes through the proxy but DNS resolution still exposes the real exit point. Together, these two settings are what actually make "global interception" true to its name — system proxy mode simply cannot hijack DNS queries, which is a real privacy difference between the two.

Why CLI Tools and Games Often Require TUN

Command-line tools (certain package managers, version control tools, custom scripts) often don't read system proxy settings at all — instead they require you to manually pass a --proxy flag or set HTTP_PROXY/HTTPS_PROXY environment variables for the proxy to take effect. If a tool never implements this kind of parameter, system proxy settings are simply invisible to it, and TUN becomes the only way to route its traffic — because TUN intercepts packets at the routing layer, it doesn't matter whether the tool is "willing" to cooperate with the proxy.

Games face a similar situation, but for more layered reasons:

1. Many games' networking modules call low-level socket APIs directly to establish connections, completely bypassing system or browser proxy configuration.
2. Matchmaking, voice chat, and some resource downloads rely heavily on UDP, while system proxy's default HTTP/HTTPS coverage offers limited UDP support.
3. Some game clients run anti-cheat or network environment checks that specifically block known system proxy port signatures, but don't treat virtual network interfaces at the system level any differently.

These three factors combine to produce the common scenario where "system proxy is on but the game still connects directly" — switching to TUN mode gets traffic correctly intercepted immediately. This is why many clients list TUN mode as a separate option and specifically recommend it for games and CLI use cases in their tutorials.

Performance and Stability Trade-offs to Expect

TUN mode covers more ground, but at the cost of an extra layer of data copying and processing between user space and kernel space, which in theory adds a bit more latency and CPU overhead than system proxy — especially noticeable in high-throughput scenarios like large file downloads or 4K video. Because its path is shorter, system proxy tends to feel lighter in lightweight scenarios. In practice, this difference is imperceptible for most people, but if your device has limited performance or you're extremely latency-sensitive (competitive gaming, for example), it's worth doing a personal comparison test before settling on one mode long-term.

Also, because TUN mode modifies the system routing table, in rare cases it can conflict with other VPN software, virtual machine networking, or corporate intranet clients — showing up as complete loss of network access or only partial access after enabling it. If this happens, first check whether another network tool that also modifies the routing table is running simultaneously; disabling one of them usually resolves the issue. Since system proxy never touches the routing table, it rarely runs into this kind of conflict and is more consistently compatible.

Which One Should You Use? Matching Modes to Scenarios

There's no need to overthink "which is better" — they're designed for different scenarios. Here's a practical way to decide:

• For everyday browsing and mainstream chat/desktop apps, system proxy is plenty — shorter path, lower resource usage.
• If a CLI tool, SDK, or package manager needs network access but doesn't recognize system proxy settings, just turn on TUN instead of hunting for proxy parameters in every individual tool.
• For games that need proxy routing, or games with heavy UDP traffic causing abnormal latency under system proxy, try TUN first.
• If you suspect an app is bypassing your proxy and connecting directly, verify first with system proxy mode plus a packet capture tool, then decide whether to switch to TUN to close that gap entirely.

Most clients (Clash Verge Rev, FlClash, Clash Nyanpasu) present system proxy and TUN mode as independent toggles in settings — you can even enable both at once without conflict, though when both are active, TUN takes precedence as the interception layer actually in effect. After first installing a client, it's best to verify your nodes and rules with the default system proxy mode, then decide whether to additionally enable TUN based on how specific apps behave on your network.