Clash TUN Mode vs. System Proxy: Traffic Entry Points, Coverage, and How to Choose

System proxy and TUN solve the same entry-point problem: how to send connections generated by a device into the Clash or mihomo core. Neither option directly determines whether a particular website uses the proxy or a direct connection. Once traffic enters the core, it is still matched according to the active mode, rule sets, proxy groups, and node status. Therefore, enabling TUN does not mean switching to Global mode, and enabling the system proxy does not mean every app will be intercepted.

Traffic entry points: system proxy reads settings, TUN receives network packets

How system proxy routing works

When the system proxy is enabled, the Clash client typically sets the operating system's HTTP, HTTPS, or SOCKS proxy address to the local loopback address and points it to the core's listening port. For example, if the core is running at 127.0.0.1:7890, a browser or desktop app that supports system proxy settings reads that configuration and actively sends requests to the port. When the client disables the system proxy, it restores the operating system settings that were in place before.

This method operates at the application layer. Traffic enters Clash only when an app reads the system proxy settings or explicitly uses the network interfaces provided by the operating system. Common browsers, office software, and many desktop clients usually work without extra configuration; programs with their own network stack, those that ignore proxy settings, or those limited to specific protocols may continue connecting directly. Command-line tools also differ: some read environment variables, while others require HTTP_PROXY, HTTPS_PROXY, or a SOCKS address to be specified separately.

How TUN mode works

TUN mode creates a virtual network interface and uses system routes to send matching IP traffic to that interface. The mihomo core reads packets from the virtual interface, identifies their destination addresses and protocols, and then uses the rules to decide whether to connect directly, reject the traffic, or forward it to a proxy node. Because the entry point is closer to the operating system's network layer, apps generally do not need to understand HTTP or SOCKS proxies or actively read the system proxy settings.

This makes TUN better suited to game launchers, terminal programs, some store apps, UDP-based software, and desktop applications that ignore system proxy settings. However, TUN coverage is still affected by the routing table, exclusions, core protocol support, and operating system limitations. Local network ranges, the default network adapter, virtual machine adapters, container networks, and other VPNs can all change the actual path, so the toggle alone cannot prove that traffic is being intercepted.

Four key differences: coverage, protocols, DNS, and permissions

App compatibility is not simply a matter of “browser versus non-browser”

Browsers usually follow the system proxy, but their behavior can also be affected by Secure DNS, QUIC, browser extensions, and enterprise policies. Some Chromium-based apps reuse the system network settings, while others include their own proxy options. A gaming platform may consist of a launcher, updater, sign-in component, and game process, with only some components reading the system proxy. In that situation, a webpage opening successfully does not prove that downloads, sign-in, and real-time communication are using the same path.

TUN mode can receive these connections at a lower network layer, so coverage is usually more complete. For UDP traffic, successful forwarding still depends on the node protocol, proxy server, routing rules, and core configuration. Enabling TUN only provides an entry point; it cannot add capabilities that the upstream node does not support.

DNS handling determines whether domain rules match reliably

With system proxy routing, DNS may be resolved locally by the app or sent through the proxy protocol for the core to handle. Behavior varies between programs. If a domain has already been resolved to an IP address before reaching Clash, the core may receive different information than it would from a domain-based request, which can change the rule-matching result. A browser's own encrypted DNS setting may also bypass the operating system's DNS path.

TUN is often used with mihomo's DNS module, dns-hijack, and Fake-IP or Redir-Host mode. When DNS requests enter the core first, the core can associate domain mappings with subsequent connections before applying domain rules. Fake-IP returns a virtual address used for local mapping; the core continues to resolve the real destination and select the proxy. Local network discovery, gaming platforms, and apps that depend on special DNS responses may need to be added to the Fake-IP exclusion list or switched to a DNS enhanced mode better suited to the environment.

Permissions and system changes differ

System proxy routing mainly changes the proxy address stored by the operating system and generally requires fewer permissions. TUN must create a virtual interface and adjust routes, so Windows clients commonly use administrator privileges or a background service, macOS may require approval for a network extension, and Android and iOS typically use the system VPN interface for interception. A permission prompt during first-time setup is a normal part of creating the network entry point.

Even after permission is granted, verify that the service actually started. A client showing TUN as enabled does not necessarily mean that routes were written, DNS hijacking succeeded, or the default interface was identified correctly. Interface creation, route setup, and listener errors in the mihomo logs are more useful than observing the toggle alone.

How to choose: match the setup to your device and app coverage

Everyday browsing and office work: start with system proxy

If your main needs are browser access, document synchronization, and desktop apps that follow the system proxy, system proxy routing is usually the more straightforward choice. It has less impact on the routing table, makes enabling and disabling predictable, and helps you determine whether an app actively uses the proxy. When something goes wrong, you can first check the local port, the operating system proxy address, and the proxy group without also dealing with virtual adapters and route conflicts.

Games, command-line tools, and independent network stacks: check TUN first

If an app explicitly ignores the system proxy or includes UDP traffic, an updater, child processes, or a separate sign-in component, TUN can serve as the primary interception entry point. Common examples include terminal package managers that do not read proxy variables, gaming platforms where downloads work but the game connects directly, store apps that cannot use the system proxy, and programs whose components follow different network paths.

Mobile devices: the system VPN interface usually serves the TUN role

On mobile operating systems, a manually configured Wi-Fi proxy usually applies only to the current wireless network, and whether an app follows it still depends on the app's implementation. Cellular networks do not use this Wi-Fi proxy setting either. For device-wide interception, clients compatible with Clash or mihomo generally establish the tunnel through the system VPN interface. After the VPN indicator appears in the status bar, also confirm in the client logs that connections are actually being processed by the rules.

Development environments, virtual machines, and containers: confirm the routing boundary first

Virtual machines and containers typically have their own adapters, gateways, or network namespaces. If TUN is enabled on the host, whether guest traffic enters that interface depends on the relationship between bridging, NAT, and the default route. When a container connects to the host's loopback address, 127.0.0.1 refers to the container itself, not the Clash port on the host. In these environments, first map the path between the host, virtual adapters, container bridge, and egress adapter, then decide whether to use TUN, a LAN listener, or an application-level proxy.

Do system proxy and TUN need to be enabled together?

In most cases, troubleshooting is easier when you choose one primary entry point. If TUN reliably intercepts the target apps, the system proxy is not required; if you use only a browser and standard desktop apps, there is no need to keep TUN enabled just for broader coverage. Some clients allow both to run at once, and the core may handle local connections and route exclusions, but complex environments can introduce bypasses, loops, or uncertainty about the actual entry point.

When both must be enabled, make sure the system proxy points to the current core port, necessary local addresses are excluded from TUN, and the logs show that each connection is received only once. When switching interception methods for testing, disable the old entry point before starting the new one to avoid stale system proxy settings or old routes affecting the result.

Setup order: validate the configuration first, then expand coverage

1. Update the subscription. Confirm that the configuration loads successfully and that proxy nodes and proxy groups are visible, so a subscription error is not mistaken for an interception failure.
2. Choose the routing mode. For everyday use, start with Rule and verify that the default proxy group has an available node. Global and Direct are useful for short-term diagnosis but should not be the sole basis for deciding whether TUN is working.
3. Test the system proxy first. Enable the system proxy, use a browser known to follow the system settings to visit the target site, and check whether the Clash connection log shows the domain, matched rule, and proxy group.
4. Identify apps that are not being intercepted. If a particular program produces no connection records, check whether it has its own proxy setting, requires environment variables, or uses UDP and an independent network stack.
5. Enable TUN next. Complete the system permission prompt and check the virtual interface, automatic routes, default adapter detection, and DNS settings.
6. Restore other networking tools one at a time. Validate the setup in a single-network environment first, then start other VPNs, virtual machines, or security software to isolate the source of route conflicts.

The following is a common basic TUN structure in a mihomo configuration. Different clients may generate these fields through their graphical interfaces; supported options depend on the core version integrated by the client.

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
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

auto-route writes the required routes automatically, auto-detect-interface identifies the current default egress, and dns-hijack sends matching DNS requests into the core. The available values and implementation of stack vary by core version, operating system, and client packaging. Do not copy the entire block over client-generated settings without understanding the current version.

On the system proxy side, the main item to verify is the listening port. When the configuration uses mixed-port, one port can accept common HTTP and SOCKS proxy connections. The port written to the system settings must match the value actually listened to by the core. If the configuration port is changed while the operating system retains the old port, apps that follow the system proxy will usually lose connectivity all at once, while apps intercepted by TUN may continue to work.

Troubleshooting: isolate the problem across four layers—entry point, DNS, rules, and egress

Layer 1: is traffic entering the core?

Open the client's connection list or live log, then launch the target app. If no new connections appear at all, first check the system proxy address, TUN service status, the app's own proxy settings, the routing table, and the firewall. Do not change nodes first: nodes only affect connections that have already entered the core and been assigned to a proxy policy.

Layer 2: is the domain resolving correctly?

If connection records contain only IP addresses, domain rules do not match, or the app times out during domain resolution, check whether the DNS module is enabled, whether TUN DNS hijacking is working, whether the browser uses its own Secure DNS, and whether Fake-IP exclusions are too broad. Local network domains and device discovery protocols may also need to retain the local resolution path.

Layer 3: are the rule and proxy group correct?

When traffic appears but takes an unexpected path, inspect the final matched rule, proxy group, and node. Rules are usually matched in the order defined by the configuration, so a broad rule placed first can override a later, more specific rule. Updating a subscription may also rebuild proxy groups and change the selection, so verify the currently selected node again.

Layer 4: are the node and physical network reachable?

Only after a rule matches a proxy but the connection times out should you move to egress checks. Verify the node status, whether the node protocol supports TCP or UDP, restrictions on the target port imposed by the current network, and whether the default egress adapter is correct. After switching from wired networking to Wi-Fi, or from Wi-Fi to a mobile hotspot, TUN may need to detect the default interface again.

Conclusion: use the smallest coverage needed for the current device

System proxy routing relies on apps actively reading the operating system settings, making it simple and well suited to browsers and standard desktop software. TUN receives network packets through a virtual interface and offers broader coverage for apps that ignore the system proxy, use UDP, or contain multiple network components, but it also adds checks for permissions, routes, DNS, and virtual adapter conflicts.

There is no need to commit permanently to one mode. Start with the system proxy to validate the subscription, nodes, and rule chain; if the target app does not enter the core, enable TUN to expand coverage. Whichever entry point you use, confirm through connection logs that traffic has entered the core, then verify DNS, rules, proxy groups, and the actual egress. Checking these four layers is more effective for finding the specific fault than simply toggling settings.