Clash TUN Mode vs. System Proxy: How Traffic Is Routed

The short answer: it’s about how traffic enters, not whether the mode is “global”

If you only need browsers and apps that honor system proxy settings to use a proxy, start with the system proxy. Consider TUN when you need to capture traffic from command-line tools, games, or other apps that ignore proxy settings, including UDP traffic. These options determine how traffic enters the Clash core; Rule, Global, and Direct determine how traffic is routed after it gets there. Don’t conflate the two.

With TUN enabled, connections matched by a DIRECT rule still connect directly. With the system proxy enabled, choosing Global won’t make every process automatically use the proxy settings. If you’re wondering, “Global mode is on, so why isn’t my game using the proxy?”, first check whether the game’s traffic reaches the core instead of repeatedly switching nodes.

System proxy: Apps connect to a local proxy port

Request flow and local ports

A system proxy typically adds HTTP, HTTPS, and other proxy settings to the operating system. Apps that honor these settings connect to a local proxy port first; the core then establishes the onward connection based on the destination and rules. For example, with the local mixed port 127.0.0.1:7890, the flow looks like this:

Apps that honor the system proxy
  → 127.0.0.1:7890 (HTTP / SOCKS mixed port)
  → Core rules and proxy groups
  → DIRECT or the selected proxy node
  → Destination service

Here, 7890 is an example, not a port used by every client. Check mixed-port, port, and socks-port in the client settings or active configuration. An HTTP port cannot be used interchangeably as a SOCKS port; only a mixed port accepts both proxy protocols.

HTTPS, UDP, and browser extension limitations

HTTPS: Apps typically use HTTP CONNECT to create a tunnel to the destination. Standard proxying does not mean the core decrypts the website’s TLS traffic, nor does normal proxy use require installing a root certificate.
UDP: The operating system’s HTTP proxy settings are not a general-purpose way to forward UDP. SOCKS5 supports UDP ASSOCIATE, but the app must implement it, and both the proxy endpoint and node must support it.
Browsers: Browser extensions, PAC files, and built-in policies may override system settings. A website loading successfully doesn’t mean all connections use the same route. How transports such as QUIC are handled depends on the browser’s implementation and policies.
Terminals: Many command-line tools read HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY, or accept only their own proxy options. They don’t necessarily follow the desktop system proxy automatically.

In Windows 11, check the system proxy under Settings → Network & internet → Proxy. On macOS, go to System Settings → Network → select your network service → Details → Proxies. These checks confirm that the settings are configured, not that a particular app is using them.

TUN: Receive IP packets through a virtual network interface

TUN provides a virtual interface at the network layer. The client or core configures routes so that matching IP packets enter this interface. The core’s network stack processes TCP and UDP, then passes traffic to the rules and outbound connections. Apps don’t need to support HTTP or SOCKS proxies, so TUN typically covers more traffic than a system proxy.

IP packets sent by an app
  → Operating system routing
  → TUN virtual interface
  → Core network stack, DNS mapping, and rule matching
  → DIRECT or a proxy node
  → Final connection sent through the physical network adapter

This is also why TUN needs elevated permissions: creating a virtual interface, changing routes, and setting up DNS hijacking often require administrator access, a system service, or the relevant network permissions on Linux. TUN isn’t simply a different set of proxy ports.

TUN doesn’t cover every network namespace

Automatic routing can exclude some traffic, and routes may be overridden by another VPN. Check LAN traffic, specific interfaces, IPv6, virtual machines, and containers individually. WSL2, Docker, and virtual machines may route traffic through a separate network namespace or virtual switch. Enabling TUN on the host doesn’t guarantee that DNS and routing are configured correctly in those environments.

Coverage compared: browsers, command-line tools, games, and LAN

Use case	System proxy	TUN
Browser HTTP / HTTPS	Usually works; check for overrides from extensions and PAC files	Can enter the core through routing, then follows the configured rules
Terminal tools such as curl and Git	Often requires environment variables or explicit proxy options	Usually needs no app-level proxy options, but check routing in the actual runtime environment
Game UDP and voice chat	Usually not covered by a standard HTTP system proxy	Can capture UDP; forwarding still depends on node and server support
LAN printers and NAS devices	Often bypassed through the system proxy’s exclusion list	Check LAN rules, route exclusions, and firewall settings
Permissions and scope of changes	Primarily changes proxy settings that apps can read	Involves a virtual interface, routing, and possibly DNS interception

For games, “TUN captures the traffic” and “this node is a good choice for gaming” are two different things. The node must support UDP, and the server must allow the relevant forwarding. Game server region, round-trip latency, jitter, packet loss, and NAT behavior also affect performance. A 60 ms HTTP latency test in the proxy client does not mean game UDP latency will also be 60 ms, nor does it tell you whether voice chat will be stable.

Before enabling TUN: check permissions, routes, DNS, and node support

Establish a baseline first

Record the current setup: Save the active configuration and note the system proxy port, DNS settings, and status of other VPNs. If you’re managing the machine remotely, make sure you have a way to restore network access.
Check the core: Confirm in the client’s core information or logs that it uses mihomo, and note the version. A client’s name alone doesn’t confirm that it supports the same TUN fields.
Check permissions: Follow the client’s service mode or permission prompts. If TUN still fails after installing the service, check startup logs for interface creation failures, permission errors, and route configuration errors instead of repeatedly toggling the setting.
Temporarily disable conflicting routes: During troubleshooting, turn off other VPNs and the system proxy, leaving only TUN enabled. This avoids having two routing paths active at once and makes it easier to identify which path a test uses.
Confirm the outbound interface: After switching between Wi-Fi, Ethernet, or a hotspot, check that the detected outbound interface is still correct. A wrong interface can cause connection failures or, in serious cases, a routing loop.

What the mihomo configuration snippet does

This example shows only how TUN and DNS work together; it does not include nodes, subscription providers, or complete routing rules, so it is not a complete working configuration. Merge these fields into your existing configuration and avoid defining duplicate top-level dns or tun keys. For settings managed by the client, use its override mechanism where possible.

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

stack: mixed is a network stack option, not mixed-port and not a switch for enabling the system proxy. Check the current core documentation for supported stacks and platform-specific behavior.
auto-route configures the core to manage routes; auto-detect-interface identifies the outbound interface. Check these settings manually when using multiple network adapters or another VPN.
dns-hijack with any:53 captures standard UDP DNS requests entering TUN. To handle TCP port 53, configure tcp://any:53 if supported by your core version.
127.0.0.1:1053 is the core’s DNS listening address. It doesn’t mean you can enter an address with a port in the operating system’s DNS settings.
198.18.0.1/16 is the Fake-IP address pool in this example. Getting a synthetic address doesn’t mean DNS resolution failed, as long as subsequent connections still reach the core that holds the mapping.

This example uses a specific DoH upstream, but whether it’s reachable depends on your network and DNS outbound settings. If the network is already offline, don’t keep cycling through DNS options. First check whether DNS requests are reaching the core, then look for upstream resolution or connection errors.

DNS and IPv6: Why traffic may still bypass TUN

Standard DNS interception doesn’t cover encrypted DNS

Rules that intercept UDP/TCP port 53 can’t identify arbitrary DoH requests inside HTTPS connections, or automatically turn DoT into core DNS queries. With “Secure DNS” enabled, a browser may use its own resolution path. The connection itself may still be captured by TUN, but the core may not receive the same domain mapping information.

If domain-based rules behave unexpectedly, temporarily disable the browser’s custom Secure DNS setting, reconnect, and check whether the core logs the domain and matching rule. Once you’ve identified the cause, choose which DNS strategy to keep rather than layering multiple settings you can’t explain.

Working IPv4 doesn’t prove IPv6 works

When a destination has both A and AAAA records, an app may prefer IPv6. If you’ve only tested IPv4 routing, IPv6 may still take a different path. Check IPv4 and IPv6 test results, routes, and connection logs separately. If only IPv6 fails, investigate local IPv6 connectivity and the relevant core settings rather than assuming the node is completely down.

Fake-IP also depends on an intact route: if DNS returns a synthetic address but the app’s connection bypasses TUN, that address usually can’t be reached over the public internet like a real server address. If some apps keep failing after you switch modes, clear their DNS or connection caches and check that system DNS isn’t still pointing to a local service that has stopped.

How to test: separate “traffic reaches the core” from “traffic uses a proxy”

Step 1: Test the local proxy explicitly

Turn off TUN but keep the core running, then use the command below to explicitly connect through the example mixed port. --noproxy "" clears the bypass list for this request so NO_PROXY won’t interfere. In Windows PowerShell, use curl.exe to avoid an alias with the same name in older environments.

curl -I --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com

This test checks only the explicit proxy endpoint and the outbound path for this request. It doesn’t confirm that the system proxy is working or that UDP is available. If it fails, check the listening port, rules, and node first—not the virtual network adapter.

Step 2: Leave only TUN enabled and disable the explicit proxy for this request

Turn off the system proxy, enable TUN, then run the command below. --proxy "" disables proxy settings for this curl request, while --noproxy "*" tells curl not to use an application-level proxy. Neither option bypasses the operating system’s TUN routes.

curl -4 -I --connect-timeout 10 --max-time 20 --proxy "" --noproxy "*" https://example.com
curl -6 -I --connect-timeout 10 --max-time 20 --proxy "" --noproxy "*" https://example.com

Find the request at the matching time under “Connections” or the client’s connection list, then check “Logs” for the rule, proxy group, and final outbound. Some interfaces show TUN as the inbound type. If yours doesn’t, use virtual interface counters and route checks as supporting evidence. A successful webpage load alone doesn’t prove traffic was captured; it may have connected directly.

Step 3: Test UDP with the app you actually use

Join a game server or start a voice chat session, note the time, and look for the UDP connection, destination address, rule, and proxy chain in the connection list. If the connection reaches the core but matches DIRECT, adjust the relevant rule. If it matches a node but keeps timing out, check the node’s UDP support and server restrictions. Browser speed tests and ICMP pings are no substitute for this test.

Troubleshooting and rollback: change one thing at a time

Browser works, terminal doesn’t: With a system proxy, check the terminal’s environment variables and the program’s proxy options. With TUN, first check whether the terminal is running in a container, WSL2, or on a remote host.
Enabling TUN cuts off internet access: Turn TUN off to restore the baseline, then check service permissions, virtual interface creation, default routes, the physical outbound interface, and DNS upstreams. Temporarily disconnect other VPNs to avoid route conflicts.
Game traffic reaches the proxy but performance gets worse: Check the route to the game server, UDP packet loss, and jitter. Compare direct and proxied results at the same time of day. Don’t choose a gaming node based only on HTTP latency.
NAS or printer is unreachable: Check whether the LAN subnet matches a direct-connection rule, whether a route exclusion is needed, and whether the local firewall allows the connection. DIRECT is the core’s outbound decision; it doesn’t necessarily mean the packet bypassed the virtual interface entirely.
Network problems after closing the client: Check whether the system proxy still points to a closed port, DNS still points to a stopped local listener, or TUN routes and the virtual interface haven’t been restored.

The choice can be simple: use the system proxy when apps honor proxy settings and your main need is web access. Enable TUN when you need to cover apps that aren’t proxy-aware or need UDP, then verify permissions, routes, DNS, and node support one by one. Wider coverage doesn’t guarantee faster speeds. Your setup is complete when you can explain how each connection enters and leaves.