Clash TUN Mode vs. System Proxy: How Traffic Is Routed and When to Use Each

System Proxy vs. TUN: The Difference Is Where Traffic Enters the Stack

To decide which toggle to use, separate two questions: Does the app's connection reach the Clash core, and how is it handled once it gets there? System proxy and TUN mainly address the first question; rule mode, global mode, and proxy group selection address the second. Enabling TUN does not mean every connection will use a proxy node, and enabling the system proxy does not mean every app will honor that setting.

This article focuses on desktop clients running mihomo, the successor to Clash Meta. Toggle names, permission prompts, and configuration merge behavior vary by client; older Clash cores may not support the same TUN fields. Check the core information in your client to confirm which core is actually running, then compare its configuration. That is more reliable than identifying support by the client name alone.

System Proxy: Apps Send Connections to a Local Port

When you enable the system proxy, the client typically sets the operating system's proxy address to a local listener, such as 127.0.0.1:7890. Browsers and desktop apps that honor this setting connect to that address. The core receives HTTP proxy requests or HTTPS CONNECT tunnel requests, then applies its rules to decide whether to connect directly or route the connection through a proxy node.

The key phrase is “honor this setting.” Windows user proxy settings and WinHTTP configuration are not the same thing; background services, some updaters, and command-line tools may use a different configuration. Proxy options in Linux desktop environments are not a universal setting enforced on every program either. So if a browser works, that alone does not prove that terminal commands, games, and background processes are covered.

TUN Mode: Use a Virtual Network Adapter to Capture IP Traffic

TUN provides a virtual Layer 3 network interface. Once the client or core creates the interface and configures routes, IP packets matching those routes enter TUN and are handled by the core. Apps generally do not need to know about a local proxy port or support HTTP proxy settings. That is why TUN can cover more command-line tools, games, and UDP apps.

However, “covers more” does not mean it captures all traffic unconditionally. Route exclusions, connections bound to a specific interface, IPv6 settings, other VPNs, and LAN traffic can all affect the outcome. TUN is not an Ethernet bridge, so it does not follow that broadcast discovery or every Layer 2 protocol can be carried through a proxy node.

Coverage Compared: Browsers, Command-Line Tools, Games, and UDP

Common Use Cases and What Each Mode Captures
Use case	System proxy	TUN mode
Web browsing	Usually sufficient when the browser honors system proxy settings.	Can capture connections covered by its routes; check DNS and QUIC.
Command-line tools such as curl and Git	Do not assume it applies automatically; specify a proxy address explicitly.	Usually no need to configure a proxy for each tool, but check routes and the runtime environment.
Games and voice chat	Many apps do not read HTTP system proxy settings, so coverage is limited.	Can handle TCP and UDP traffic routed through TUN; the proxy node must support the relevant traffic too.
Containers, virtual machines, and WSL	Often requires proxy settings inside each environment.	Depends on the virtual network topology; enabling it on the host does not guarantee full coverage.
LAN access	Can bypass the proxy using the system proxy's exception list.	Check route exclusions and the core's direct-connection rules.

TUN Being Enabled Does Not Guarantee UDP Will Work

A standard HTTP system proxy does not automatically route arbitrary apps' UDP traffic through a proxy node. SOCKS5 does support UDP relay, but both the app and the local proxy endpoint must support and use it. Simply entering an HTTP proxy address in the system settings does not provide that path.

TUN can pass UDP packets matching its routes to the core, but what happens next also depends on the outbound protocol, node configuration, remote service, and firewall. Even setting udp: true cannot give UDP support to an outbound connection that does not support it. If a game login works but voice chat does not, troubleshoot the voice connection separately rather than testing only a website.

Choosing by Use Case: Start with the System Proxy, Then Cover What It Misses

Web Browsing and Everyday Desktop Apps: Start with the System Proxy

If your main goal is web browsing and your browser honors system proxy settings, start by leaving TUN off and enabling the system proxy with rule mode. This makes fewer changes and makes it easier to tell whether a problem lies with the local port, rules, or proxy node. In Windows 11, check the proxy server under Settings → Network & internet → Proxy. On macOS, check System Settings → Network → your current connection → Details → Proxies. The exact labels may vary slightly by OS version.

The local address is usually 127.0.0.1; use the port configured in your client. This article uses 7890 as an example, not as a default shared by all clients. If your client listens on another port, update the system proxy, terminal environment variables, and any manually configured app proxies to match.

Terminals and Developer Tools: Set an Explicit Proxy to Limit the Scope

If you want only one download to use the proxy, specify the proxy endpoint for that command instead of routing the whole device. The command below checks whether the local HTTP proxy endpoint can establish an HTTPS tunnel. In Windows PowerShell, use curl.exe to avoid interference from an alias with the same name in older environments.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

This only confirms that the request used the specified proxy endpoint; it does not prove that games or other terminal tasks are covered. If you use environment variables such as HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY, check that the tool supports them and that NO_PROXY does not exclude the target address. HTTPS in the variable name usually describes the type of destination request; it does not mean the local proxy address must use https://.

Games, Voice Chat, and Apps Without Proxy Support: Consider TUN

When an app does not read system proxy settings and has no usable proxy option of its own, TUN can extend coverage. Before enabling it, make sure the client has permission to create a virtual network adapter and change routes. On Windows, this may be handled through service mode or elevated permissions. On macOS and Linux, it depends on the client's helper tools and permission model. This does not mean every platform requires running the entire client interface as an administrator at all times.

Both entry points can be enabled at once, but test them separately when troubleshooting for the first time. With the system proxy on, a browser may keep working through the local port even if TUN is not capturing traffic, making it look like “the web works.” To verify TUN, temporarily turn off the system proxy, clear any proxy settings in the test app, and then check the connection logs.

mihomo TUN Configuration: Routes, DNS, and Rules Have Different Roles

The following snippets illustrate individual fields for mihomo cores that support them; they are not a complete, standalone subscription. A client may generate or override fields with the same names when you use its interface. Back up your configuration before editing, then check the effective configuration afterward so a subscription update does not overwrite your changes.

mixed-port: 7890
mode: rule

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

mixed-port: Provides HTTP and SOCKS proxy endpoints on a single listening port. It serves explicit proxy connections; it is not the port for the TUN virtual network adapter.
stack: mixed: Selects a TUN stack implementation supported by the core. It has nothing to do with “Global” in rule mode. Check the current core documentation for supported values and platform-specific behavior.
auto-route: Requests automatic configuration of TUN routes. Creating the interface successfully does not guarantee that the routes were installed correctly; check the logs and system routing table too.
auto-detect-interface: Attempts to identify the outbound network interface. With multiple adapters, another VPN, or a specialized virtual network, the automatic choice may not be what you expect.
dns-hijack: Sends specified DNS traffic on the relevant capture path to the core's DNS handler. The example covers common UDP 53 and TCP 53 traffic; it does not intercept every form of name resolution.

DNS Needs Its Own Configuration

The snippet above does not include a complete dns configuration. In practice, also confirm that core DNS is enabled, upstream resolvers are reachable, and the fake-ip or redir-host mode is compatible with your existing configuration. A common fake-ip range is 198.18.0.0/16. These addresses are used for connection mapping; they are not the real server addresses of the target websites.

Secure DNS in browsers, in-app DoH, and DoT are not automatically handled like ordinary DNS queries just because port 53 is being monitored. If domain rules do not match or resolution behaves unexpectedly, first find out where the lookup is happening. Then decide whether to adjust browser settings or core DNS rules. Repeatedly switching proxy nodes will not fix a DNS problem.

Rules Still Decide Whether Traffic Goes Direct or Through a Proxy

Once traffic reaches the core, rule mode still determines how it is handled. Domain rules, IP rules, and the fallback MATCH rule together determine the outbound path; TUN does not bypass this logic. Whether a domain can be matched also depends on DNS mapping, sniffing, and other mechanisms. Do not assume the original domain can be recovered for every connection that only has a destination IP.

Printers, NAS devices, and corporate intranets on a LAN usually need a direct route. For example, when accessing 192.168.1.10, check that it is correctly excluded from capture or matches a direct-connection rule. If an automatic route prevents packets from reaching the core in the first place, changing rules inside the core will not affect that connection. First identify which layer is causing the problem.

Repeatable Troubleshooting: Separate Capture, Routing, and Proxy Node Issues

Record a baseline. Note the local port, running core, current proxy group, and target domain. Start by visiting one fixed target in a browser. Do not change the node, DNS, and capture mode all at once between tests.
Test the system proxy alone. Turn off TUN, enable the system proxy, and verify it with the explicit proxy command above. If the command works but the browser does not, first check the browser's own proxy settings, the system exception list, and extensions.
Test TUN alone. Turn off the system proxy, remove proxy settings from the test app, enable TUN, and start a new connection. Check the logs for the target, network type, matched rule, and outbound policy.
Check routes and DNS. On Windows, check route print; on Linux, check ip route and ip rule; on macOS, check netstat -rn. Do not rely on the virtual adapter icon alone to decide whether traffic is being captured.
Test UDP separately. Start a connection using the actual game or voice feature, then find the corresponding UDP session in the client's connection list. A website test or ICMP ping cannot replace a test of UDP over the proxy path.

To rule out explicit proxy variables, you can use the command below. Note that --noproxy "*" only makes curl bypass its explicit proxy path. If TUN is enabled, the system may still route the connection through the core, so this is not a “force direct connection” command.

curl --noproxy "*" --connect-timeout 10 -I https://example.com

Also close existing connections before testing again. Browser connection pools, persistent game connections, and DNS caches may retain state from before the switch. A connection that keeps working after you change a setting does not necessarily mean a new connection will take the same path.

FAQ: Permissions, VPN Conflicts, and Restoring Network Access

Why does enabling TUN leave the whole device without internet access?

Turn off TUN to restore your baseline, then check the core logs, upstream DNS, and routes separately. A virtual interface may be created even though the core cannot handle traffic correctly, or routes may point to the wrong outbound interface; either can interrupt connectivity. If domains fail but a connection to a known IP responds, investigate DNS first. This is a troubleshooting clue, not a universal connectivity test for every service.

Can TUN and a corporate VPN run at the same time?

It depends on their routing, DNS, and security policies; coexistence is not guaranteed. If both programs change the default route, they may overwrite each other's settings or create an unexpected path. First verify each one on its own, then check whether corporate network ranges, the default route, or DNS have changed. On organization-managed devices, follow the network policy in place; do not delete routes or change security settings blindly.

Why does my browser still report a proxy connection error after I quit the client?

The system proxy may still point to the now-closed 127.0.0.1:7890. Check the system proxy settings for that leftover address, and check whether the browser has its own proxy configured. If the issue is with TUN, restart the client and turn TUN off normally so the client can clean up its routes. Do not bulk-delete virtual adapters or system routes unless you understand the network topology.

Is TUN mode always faster than the system proxy?

Not necessarily. The main difference is what traffic each mode captures; actual speed still depends on node bandwidth, path congestion, packet loss, DNS, MTU, and device performance. A comparison is meaningful only when the destination, node, time of day, and transport type are as similar as possible. TUN gives apps that did not previously reach the core a proxy path. That changes coverage; it does not mean the same connection has become faster.

Keep the choice simple: use the system proxy for web browsing, configure an explicit proxy for a few command-line tasks, and enable TUN when you need to cover apps without proxy support or UDP use cases. Change one thing at a time, use connection logs to verify the entry point and rules, then assess node quality. This is usually easier to troubleshoot than turning on every option at once.