Clash TUN Mode vs. System Proxy: How Traffic Interception Works

Start with the layers: proxy settings and virtual network interfaces

Both system proxying and TUN mode can send traffic through Clash, but they intercept it at different network layers. A system proxy registers an HTTP, HTTPS, or SOCKS proxy address with the operating system. Applications that read this setting actively hand requests to Clash's listening port. TUN mode creates a virtual network interface and uses system routes to direct IP packets to the Clash core. The former depends on whether an application follows proxy settings; the latter mainly depends on whether the routes cover the target traffic.

This distinction determines real-world coverage. Browsers, some desktop communication apps, and programs that use the system networking APIs can usually use a system proxy directly. Command-line tools, games, standalone updaters, software with its own networking stack, and UDP-only applications may ignore system proxy settings. TUN operates at a lower layer and can generally receive TCP or UDP traffic from these programs, then let cores such as mihomo choose between proxying, direct connection, or rejection according to the rules.

These modes are not speed settings either. Enabling TUN does not automatically increase node bandwidth, and using a system proxy does not mean the connection will perform worse. Speed still depends on the local network, node load, route quality, transport protocol, destination site, and DNS results. The main purpose of choosing a mode is to determine which traffic enters the core and how domain information is associated with connections.

System proxy: applications actively connect to a local port

The “System Proxy” switch in a Clash GUI client typically sets the operating system's HTTP and HTTPS proxy address to the local loopback address and the core's listening port, such as 127.0.0.1:7890. If the client uses mixed-port, that port can accept both HTTP and SOCKS connections. After reading the proxy setting, an application connects to this local port first; Clash then reads the destination address and applies the rules.

When a browser visits an HTTPS website, it generally sends a CONNECT request to the HTTP proxy containing the destination domain and port. Clash can use that domain to match DOMAIN, DOMAIN-SUFFIX, or rule providers. Once the tunnel is established, HTTPS content remains end-to-end encrypted; traffic interception does not mean that web content is decrypted. For ordinary HTTP requests, the proxy can likewise obtain the domain from the request target.

The main advantage of a system proxy is its clearly defined scope of change. As long as a program follows the system settings, there is no need to rewrite system routes or create a virtual network interface. It is often a good starting point for initial setup, browser access, document downloads, and common desktop applications. When the switch is turned off, the client should restore the previous system proxy state, making this mode useful for quickly determining whether a problem lies in the proxy path or the local direct-connection path.

Common coverage gaps with system proxies

• Application ignores system settings: Some programs have their own proxy options and connect directly when those options are not configured.
• Proxy settings are not inherited by the command-line environment: Terminal tools may read only HTTP_PROXY, HTTPS_PROXY, or their own configuration files.
• UDP traffic does not pass through an HTTP proxy: Games, voice calls, and some real-time communication features may continue to connect directly.
• Background services run under a different account: A system service may not read the proxy settings of the current desktop user.
• Applications use their own DNS and connection policies: Domain resolution and subsequent connections may bypass the system proxy entry point.

So when the browser works but a particular program cannot connect, do not switch nodes immediately. First check whether the program offers a proxy option, then verify whether it supports HTTP or SOCKS5. Consider TUN mode only if the program has no proxy support at all or if UDP must also be intercepted.

TUN mode: routes send IP packets to the core

TUN is a Layer 3 virtual network interface. Once enabled, the client or mihomo core creates a virtual adapter and adds routes according to the configuration, causing IP packets within the selected scope to enter that interface. The core reads the source address, destination address, and protocol type from each packet, then combines that information with DNS mappings, connection sniffing, and the rules. When a proxy node handles forwarding, the core converts the original connection into the corresponding proxy-protocol connection; when a rule matches DIRECT, it connects to the destination through the physical network interface.

Because it involves a virtual interface, routing tables, and the network stack, TUN usually requires elevated privileges. A Windows client may require administrator privileges to install or start a service; macOS may ask for approval of a network extension or system credentials; Linux generally requires access to /dev/net/tun, the capabilities needed to configure routes, or a system service to perform these operations. The exact method depends on the client implementation, so the presence of a switch in the interface alone does not prove that TUN is working.

The TUN section of a mihomo configuration usually includes options for the stack type, automatic routing, interface detection, and DNS hijacking. The following snippet illustrates how these fields relate; in actual use, follow the configuration generated by the client and the documentation for the current core:

mixed-port: 7890
mode: rule

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

auto-route automatically sets the interception routes, while auto-detect-interface identifies the actual outbound interface and helps prevent the proxy node's own connection from being sent back into TUN. Supported stack types can vary by operating system and core version; common values include system, gvisor, and mixed. The stack type affects how packets are processed locally, but it cannot compensate for node quality or rule configuration.

Preventing proxy loops

When TUN covers too broad a range, make sure the connection from Clash to the proxy server leaves through the physical interface. If that connection is routed back to the virtual adapter, a proxy loop forms. Symptoms include every connection timing out after TUN is enabled, logs repeatedly establishing the same destination, or the system network becoming completely unavailable for a short period. Automatic routing and interface detection usually handle this, but multi-adapter, VPN, virtual machine, container, and manually routed environments may still require explicit exclusions.

DNS handling: can domain rules match accurately?

Proxy rules are often written using domain names, but the raw packets received by TUN primarily contain the destination IP. For rules such as DOMAIN-SUFFIX to work correctly, the core must associate the DNS result with the subsequent connection. DNS hijacking, fake-ip, and connection sniffing can all help solve this problem, but they serve different purposes.

In fake-ip mode, Clash DNS returns a temporary address from a reserved range for each domain and stores the mapping between the domain and that address. When an application subsequently connects to the temporary address, the core can restore the original domain, apply domain rules, and establish the real remote connection. Common default ranges belong to reserved address space intended for testing and are not public server addresses. This mechanism reduces cases where a domain is resolved locally to an IP first and then incorrectly classified by IP rules.

Some local-network device discovery, printing services, gaming platforms, and programs that depend on real DNS answers are not compatible with fake-ip. In those cases, use fake-ip-filter to exclude the relevant domains so they receive real resolution results. Do not expand the filter arbitrarily; excluding large numbers of ordinary domains weakens the association between domains and connections and may cause rule matching to fall back to IP-based checks.

redir-host mode generally returns the real IP and lets the core record the resolution relationship. It is more directly compatible with some applications, but domain mapping may be less stable when multiple domains share one IP, the DNS cache comes from another resolver, or an application bypasses Clash DNS. Connection sniffing can supplement the domain using the SNI in a TLS ClientHello or an HTTP Host header, but it cannot obtain a domain from every protocol and does not decrypt HTTPS content.

Preventing DNS requests from bypassing interception

1. Confirm that Clash DNS is enabled and check the listening address shown by the client.
2. When TUN is enabled, check whether the DNS hijacking rules cover ordinary queries on port 53.
3. Applications using encrypted DNS may connect directly to a specified server; routing and domain rules must continue to intercept those connections.
4. During troubleshooting, clear the operating system and browser DNS caches so that stale results do not affect the diagnosis.
5. When local-network domain resolution fails, check nameserver-policy, fallback, and fake-ip-filter instead of immediately disabling all rules.

In system proxy mode, when a browser submits a domain in a CONNECT request, Clash can obtain the destination name directly, so reliance on fake-ip is usually lower. However, if an application resolves the domain itself and submits only the IP address to a SOCKS proxy, domain information may be lost. SOCKS5 supports submitting a domain name, but whether an application uses that method is up to the application.

Use cases: choose the entry point based on coverage needs

For everyday web browsing and desktop software that supports system proxies, enable the system proxy first. It makes fewer network changes and is easy to revert to a direct connection by turning the switch off. For users who have just imported a subscription, this approach makes it easier to verify nodes, proxy groups, and rules before deciding whether to add the TUN layer.

TUN is a better fit when you need to intercept software without proxy settings, UDP applications, gaming platforms, background updaters, or multiple command-line programs. It reduces the need to enter proxy addresses in each application and lets connections from different network stacks pass through one rule system. Before using it, confirm that the client includes a core with TUN support. The most common current implementation is mihomo, a continuation of Clash Meta; option names and permission handling vary between clients.

Servers and development environments also require consideration of containers, remote access, and management traffic. If you change the default route remotely over SSH, an incorrect TUN route can immediately break the management connection. In these environments, keep a separate terminal available, schedule an automatic rollback, and explicitly exclude management subnets. Whether container traffic enters TUN depends on the host routes, network namespaces, and forwarding rules; a successful proxy connection from the host's browser is not enough to determine this.

Recommended gradual setup order

1. Import a valid subscription and choose a reachable node or proxy group.
2. Enable the system proxy in rule mode, then test the browser and common applications.
3. Review the connection logs to confirm that domain, direct, and proxy rules behave as expected.
4. Enable TUN only when a real coverage gap exists, and grant the client the required system permissions.
5. Test TCP, UDP, local-network access, DNS resolution, and recovery after system sleep separately.
6. Keep a working copy of the original configuration and retest one item at a time after changing routing or DNS options.

You generally do not need both entry points for “more complete” coverage. Many desktop clients keep the system proxy switch available after TUN is enabled. This is not necessarily an error, but it can make some applications use an explicit proxy while others use TUN, complicating troubleshooting. Unless the client documentation says otherwise, enable only one interception method first, confirm that it is stable, and then decide whether combining them is necessary.

Troubleshooting: check each layer from entry to outbound connection

If the network stops working after switching modes, follow the data path instead of changing multiple DNS, node, and rule options at once. First confirm that the Clash core is running and that the local mixed-port or another listening port is not already in use. Next identify the active entry point: does the system proxy address point to the correct port, or has the TUN virtual interface been created? Then check whether the request appears in the connection log.

Compare nodes only after that. If the same node works under the system proxy but fails under TUN, the problem is more likely to involve the virtual interface, routes, DNS, or permissions. If neither mode can establish a proxy connection, check the subscription status, proxy-group selection, node reachability, and local network. If only one destination fails, inspect the exact rule and proxy group it matched instead of treating a single-site issue as a failure of TUN as a whole.

Conclusion: coverage determines the mode, not the label

A system proxy is an application-layer entry point with straightforward configuration and a short troubleshooting path, making it suitable for programs that follow the operating system's proxy settings. TUN operates at the IP-routing entry point and can cover more TCP, UDP, and proxy-unaware applications, but it requires attention to permissions, virtual interfaces, routes, DNS mappings, and proxy loops. Both ultimately pass connections to the Clash or mihomo rule engine and do not change the quality of the nodes in the subscription.

The sensible order is to verify the basic configuration with a system proxy first, then enable TUN when there is a clear application-coverage need. When problems occur, check the application entry point, DNS, rules, proxy groups, proxy outbound connection, and physical network interface in that order. Changing one option at a time is usually faster for finding the cause than repeatedly switching nodes and network stacks.