Clash TUN Mode vs System Proxy: How Each One Actually Works

How System Proxy Works: Apps Have to Read the Setting Themselves

System Proxy is a standard interface provided by the operating system — Windows' "Network & Internet > Proxy" and macOS' "System Settings > Network > Proxies" both live at this level. When a Clash client turns on system proxy, what actually happens is that the OS's HTTP/HTTPS proxy address gets set to the local 127.0.0.1:7890 (the exact port depends on your configuration) and written into the registry or system config files.

The key point is that this is only an "advisory setting" — whether it actually takes effect depends entirely on whether the application chooses to read it. Browsers and most GUI software actively check the system proxy and follow it, which is why web browsing gets proxied instantly. But quite a few programs simply ignore system proxy settings, including:

• Command-line tools that implement their own network stack instead of relying on the OS network libraries — for example, some statically-compiled Go CLI binaries.
• Game clients, especially ones using UDP for real-time sync; many game engines don't call into the system proxy interface at all.
• Background update services, drivers, and system-level components, which often run with elevated privileges or in an isolated network context.
• Some Electron apps that never explicitly read proxy environment variables can also bypass system proxy.

In other words, system proxy is an "honor system" at the application layer. Clash writes the address, but whether it's actually used is up to the app. That's exactly why people often report "the client says connected, the browser works fine, but this one program still can't get through" — the program simply never went through the system proxy in the first place.

How TUN Mode Works: A Virtual Adapter Takes Over the Network Layer

TUN mode (also called Tun Mode in the Clash Meta / mihomo core) takes a completely different approach. Once enabled, the client creates a virtual network interface (a virtual adapter) on the system and modifies the local routing table so that traffic is redirected to this virtual adapter at the network layer (IP layer), where the Clash core receives, parses, and forwards it according to your rules.

Because the interception happens at the routing layer instead of the application layer, whether traffic gets proxied no longer depends on any program implementing proxy protocol support — as long as a process produces IP packets and hands them to the system network stack, the virtual adapter catches them. This means:

• CLI tools that have no idea what system proxy is can still be covered by TUN mode.
• UDP traffic from most games can be covered by TUN mode (the actual outcome still depends on the transport protocol the game uses and whether it runs over IPv6).
• Requests from background system services and non-browser processes also pass through the virtual adapter.

Think of system proxy as "a sign at the door asking people to cooperate with a voluntary check"; TUN mode turns the door into a mandatory checkpoint that everyone passes through whether they like it or not. The former relies on cooperation, the latter doesn't.

Common TUN Mode Configuration Fields

In a mihomo core config file, the core TUN mode fields roughly look like this (shown as a YAML snippet — exact field names may vary depending on your client's actual config structure):

tun:
  enable: true
  stack: system     # or gvisor / mixed, determines how the virtual adapter is implemented
  dns-hijack:
    - any:53
  auto-route: true   # automatically takes over the system routing table
  auto-detect-interface: true

auto-route controls whether the routing table is modified automatically, and dns-hijack controls whether DNS queries get redirected into Clash's internal resolver as well. Combined with DNS handling mechanisms like fake-ip, this helps prevent certain apps from bypassing the proxy by making direct DNS requests.

Key Differences Side by Side

Here's a table comparing the two modes directly.

Which Mode Fits CLI Tools and Games

Given the differences above, here's a fairly clear decision path.

Command-Line Tools

If you're using package managers, version control tools, or scripting HTTP libraries in a terminal, first check whether they support the HTTP_PROXY / HTTPS_PROXY environment variables. If they do, turning on system proxy plus setting those variables is usually enough — no need for TUN mode. Only consider TUN mode as a fallback when a tool clearly doesn't support proxy environment variables but still needs network access.

# Temporarily set proxy environment variables for the current terminal session (adjust the port to match your setup)
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

Games

Most game clients don't read system proxy settings at all, especially ones using custom network protocols or connecting directly to servers over UDP. In these cases system proxy is essentially useless, and you'll need TUN mode to force interception at the network layer. Once TUN mode is on, it's worth setting up a dedicated policy group for the game's domains or IP ranges in your rules, so game traffic doesn't share a node with everything else and cause latency spikes.

Everyday Browsing and Office Work

If your needs are mostly browser use, streaming video, and a handful of desktop apps that honor system proxy, system proxy mode is already enough — there's no need to enable TUN mode on top of it. TUN mode covers more ground, but it needs higher privileges and makes more invasive changes to routing, which also makes troubleshooting more involved when something goes wrong. It's the more powerful but heavier option — turn it on only when you actually need it.

Common Issues When Switching Modes

No internet access at all after enabling TUN mode

This is usually caused by insufficient privileges preventing the virtual adapter from being created, or a routing table conflict with another network tool (such as certain VPN clients) that's also modifying routes. Try closing other tools that touch the routing table, then relaunch the Clash client with admin/root privileges.

Some sites behave oddly after enabling TUN mode

This is usually related to DNS hijacking and split-routing rules. Check the dns-hijack configuration and make sure no domain that should go direct is being mistakenly routed to a proxy node.

System proxy is on but a program still connects directly

This is the normal behavior explained earlier — the program simply isn't reading the system proxy configuration. The fix is to set a proxy environment variable specifically for it, or switch to TUN mode instead.

Can both modes run at the same time

Technically yes, but there's little point — TUN mode already intercepts nearly all traffic at the network layer, so system proxy's effect gets overridden or creates redundant decisions. It's generally better to pick one based on your scenario, which also reduces the number of variables when troubleshooting.