The fundamental difference between the two interception methods
Clash clients (and the mihomo core) offer two fundamentally different ways to intercept traffic: system proxy and TUN mode. People often treat them as "two switches with similar effects," but the way they operate at the operating system level is completely different — and that difference is exactly what determines which traffic gets proxied and which slips through.
The system proxy approach works by modifying the proxy settings of the operating system or browser, telling proxy-aware applications "send your HTTP/HTTPS requests to this address and port." This is an application-layer convention that relies on each program voluntarily reading and honoring that setting. Windows' "Network & Internet settings," macOS's "Network preferences," and the proxy options in Linux desktop environments are all, at their core, writing a queryable configuration that programs read and then decide, on their own, whether to use.
TUN mode works completely differently. It creates a virtual network interface at the operating system kernel level, making the system believe it has an additional network adapter. Clash then uses routing table rules or firewall rules to redirect nearly all outbound traffic from the device to this virtual adapter, after which the mihomo core parses the raw IP packets in user space, reconstructs the actual connection requests, and forwards them according to the rules. This approach operates at the network layer and does not depend on whether an application "cooperates" — it's a lower-level traffic hijacking mechanism.
Why the system proxy misses traffic
The core limitation of the system proxy is that it's a "voluntary compliance" mechanism, not a forced takeover. This creates several real-world scenarios where traffic gets missed.
Programs that don't read the system proxy setting
A large number of command-line tools, background services, and some desktop programs never query the system proxy configuration at all — they establish TCP connections directly. Common examples include curl, git, ssh, some package managers (such as pip or npm without an explicitly configured proxy), and quite a few native clients outside the Electron ecosystem. Requests from these programs bypass Clash entirely and go through the machine's default network path.
UDP traffic is generally unaffected by the system proxy
System proxy settings are essentially designed for TCP-based requests like HTTP/HTTPS — there's no unified "system-wide UDP proxy" concept at the OS level. This means UDP-dependent applications — including the real-time sync traffic of many online games, QUIC-based (HTTP/3) web requests, some video call software, and DNS queries themselves — often bypass Clash entirely under system proxy mode. Even if the proxy node itself supports UDP forwarding (as with Shadowsocks or some Trojan implementations), that capability simply isn't usable in system proxy mode.
The special case of game clients
Games are extremely sensitive to network latency, so most game engines call low-level socket interfaces directly to establish connections — they neither query the system proxy nor commonly support application-layer proxy protocols. Getting game traffic to route through a proxy almost always requires a network-layer interception method; the system proxy is essentially ineffective in this scenario.
The "some sites work, some don't" symptom under system proxy mode is often not a node or rule problem at all — it's usually that the program in question simply doesn't honor the system proxy setting, or it's using a UDP channel that the system proxy has no control over. Checking how the affected program handles networking before troubleshooting can save a lot of time spent needlessly switching nodes.
How TUN mode achieves full coverage
TUN mode's interception scope is noticeably broader and, in principle, covers most of the scenarios the system proxy misses — because it operates at the network layer rather than the application layer.
- No cooperation from the program required. The combination of a virtual adapter plus routing table rules means all outbound packets to the public internet default to routing through this virtual interface, regardless of whether the program initiating the connection "knows" a proxy exists. This matters especially for command-line tools and programs that don't support proxy settings.
- Native UDP support. When the mihomo core handles TUN traffic, it parses UDP packets and forwards them according to the rules. As long as the selected proxy node supports UDP over the corresponding protocol, games, voice calls, and QUIC requests can all be proxied normally — no longer a blind spot as they are under system proxy mode.
- Applies to all network interfaces on the machine. Traffic generated by virtual machines, containers, and some development environments will also be captured by the TUN adapter as long as it ultimately passes through the system's default route — offering more thorough coverage than configuring a proxy app by app.
It's worth noting that TUN mode isn't a "zero-configuration cure-all." It relies on operating-system-level permissions — on Windows it needs to run with administrator privileges to create the virtual adapter and modify the routing table; on macOS and Linux it typically requires installing a kernel extension or using a specific network extension framework and granting the corresponding permissions. Some clients (such as Clash Verge Rev and FlClash) provide a "Service Mode" or "TUN Mode" toggle in settings, and enabling it usually triggers a permission authorization prompt — this is normal behavior, not an error.
Side-by-side comparison of the two modes
| Dimension | System proxy | TUN mode |
|---|---|---|
| Operating layer | Application layer (requires the program to actively read the setting) | Network layer (virtual adapter + routing table) |
| Command-line tool coverage | Depends on whether the tool reads proxy environment variables | Covers everything by default |
| UDP / game traffic | Generally unsupported | Supported (depends on the node's protocol capability) |
| Permissions required | Regular user permissions suffice | Requires administrator/root privileges or system network extension authorization |
| Setup cost | Low — flip the switch and go | Higher — involves one-time permission configuration |
| Compatibility with local network tools | Essentially no conflicts | May conflict with some VM networking or VPN client routes |
How to choose: scenario-based decision criteria
Neither option is absolutely better — the choice should be based on your actual use case. Here are a few typical decision paths.
Just everyday web browsing or accessing external services from office software
The system proxy is enough. Browsers and most office-oriented clients honor the system proxy setting, so there's no need to introduce the extra permission setup and potential routing conflicts that come with TUN mode. This is also the default initial mode in most clients.
Need to use git, curl, package managers, and similar tools in a terminal
Favor TUN mode, or configure proxy environment variables individually for these tools (such as setting the HTTP_PROXY/HTTPS_PROXY environment variables to point at Clash's mixed port). The latter is lighter-weight but requires per-tool configuration, which isn't as convenient as the one-time setup that TUN mode provides.
Playing online games that connect to servers abroad
You'll essentially have to rely on TUN mode. Game traffic is predominantly UDP and doesn't read the system proxy setting, so system proxy mode has almost no effect on game connections — this is one of the common reasons behind "I turned the proxy on but my game still won't connect" complaints in the community.
Work computers or environments where you're cautious about system permission changes
The system proxy is recommended. TUN mode requires elevated system permissions and modifies the routing table, so on managed office devices you should confirm it's consistent with your organization's device usage policy before enabling it.
Mainstream clients (Clash Verge Rev, FlClash, Clash Plus, and others) all support switching directly between system proxy and TUN mode from the settings screen, with no need to manually edit configuration file fields. The first time you enable TUN mode, just complete the one-time permission authorization prompt as instructed — after that, switching is just a toggle.
A few notes on running both at once
Some users enable both the system proxy and TUN mode at the same time. In theory this doesn't conflict, but it has limited practical value — once TUN mode is active, almost all traffic is already being redirected by the routing table to the virtual adapter, so the system proxy setting essentially never gets triggered anymore. Enabling both is more of a psychological "double insurance" than something that adds actual coverage.
Also worth noting: TUN mode can end up competing for the routing table with the network adapters used by some VPN clients and virtual machine desktop software. If you notice VM networking acting oddly or another VPN connection dropping after enabling TUN mode, it's usually a routing priority conflict — you can adjust the TUN route's metric in the configuration, or temporarily disable the conflicting side to isolate the issue, rather than assuming Clash itself is broken.
Whichever mode you choose, the underlying logic for proxy groups, proxy nodes, and routing rules is shared between them — TUN mode only changes "how traffic gets handed to Clash in the first place." Everything downstream — rule matching, node selection, and forwarding — works exactly the same as it does under system proxy mode. Once you understand that, switching between the two modes is purely a choice of interception method, not a matter of learning a whole new rule system.