Clash TUN Mode vs. System Proxy: Traffic Coverage, DNS Paths, and Use Cases

“System Proxy” and “TUN Mode” in a Clash client are not two rule modes, nor do they determine which node a connection ultimately uses. They address an earlier question: how application traffic enters the Clash or mihomo core. Once traffic reaches the core, it proceeds through domain sniffing, DNS, rule matching, policy-group selection, and outbound connections.

System proxy operates through the proxy interface provided by the operating system. Browsers and desktop applications that support system proxy settings read the proxy address and actively hand requests to Clash. TUN mode creates a virtual network interface and uses system routes to send IP packets into the core, covering more applications that have no proxy settings. Both modes can use the same subscription and rules, but their coverage, DNS paths, permission requirements, and failure patterns differ.

Request paths in the two modes

System Proxy: Applications Connect Directly to the Local Proxy Port

When System Proxy is enabled, a graphical client typically points the operating system’s HTTP, HTTPS, or SOCKS proxy address to a local listening port, such as 127.0.0.1:7890. After reading this setting, the browser connects to the local Clash port instead of connecting directly to the destination website. The core receives the target hostname or address, then uses the current rules to choose DIRECT, REJECT, or a proxy policy group.

This path depends on application support. Most major browsers and desktop programs that read system network settings can use the proxy normally, but the following traffic may bypass System Proxy:

• Software that implements its own network stack and explicitly ignores the operating system’s proxy settings.
• Games, voice applications, synchronization tools, and other programs that use UDP directly without SOCKS or in-app proxy support.
• Terminal programs that read only environment variables such as HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY.
• Virtual machines, containers, or subsystems with separate network environments that cannot use the host’s loopback address as their own proxy address.
• Applications that use hard-coded addresses, private protocols, or their own secure DNS channel.

Therefore, enabling System Proxy does not mean every process is covered. It is closer to a connection directive that applications can read than to forced redirection of every packet on the system.

TUN: System Routes Send Packets to a Virtual Interface

TUN mode creates a virtual layer-3 network interface. The system sends matching IPv4 or IPv6 packets to that interface according to the routing table, while cores such as mihomo reconstruct the connection through a user-space network stack, apply rules, and establish the outbound connection. Applications generally continue to believe they are connecting directly to the destination address, without needing separate HTTP or SOCKS proxy support.

A typical path can be simplified as: application connection → operating-system route selection → TUN virtual interface → Clash core → rules and policy groups → direct or proxied outbound connection. Because its entry point is at the IP layer, TUN provides broader coverage for UDP, command-line programs, some game launchers, and software that ignores System Proxy. Broader coverage does not mean every connection is automatically proxied; the final action still depends on the rules. LAN traffic, reserved addresses, and specific processes can still be configured for direct access.

Why the DNS path changes the result

Many issues such as “the node connects but the website does not open,” “domain rules do not match,” or “DNS stops working when Clash is closed” actually originate in the DNS path. To determine whether DNS passes through Clash, do not rely solely on the DNS toggle in the interface. Confirm where the application sends queries, which resolver the system uses, whether port 53 is being intercepted, and whether the browser has enabled its own encrypted DNS.

Local resolution may occur under System Proxy

When an application sends a domain through HTTP CONNECT or SOCKS, Clash can see the destination hostname and apply domain rules. However, not every connection preserves the hostname. Some programs resolve the name through the system DNS first and then pass the IP address to the proxy; others use the browser’s built-in DNS over HTTPS. As a result, the system resolver, browser resolver, and Clash DNS may all be active at the same time.

If a request has already been resolved to an IP address before entering the core, domain-rule matching may be less effective. The core may recover some HTTP, TLS, or QUIC host information through sniffing, but sniffing does not work for every protocol and should not be treated as a substitute for correcting a DNS configuration.

TUN commonly works with DNS hijacking

TUN configurations often send ordinary UDP or TCP queries on port 53 to the core’s DNS module. The exact mihomo fields vary by version and client wrapper; a common structure is shown below. In practice, follow the configuration generated by the current client:

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

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

fake-ip returns a mapped address from a reserved range to the application, allowing the core to preserve the relationship between the domain and the connection. After the packet enters TUN, the core uses the original domain to match rules and connect to the actual destination. Some LAN devices, connectivity checks, game platforms, and services that depend on real address responses are not suitable for fake-ip. Add them to a filter list or use another enhanced mode supported by the client.

DNS hijacking primarily targets traditional queries on port 53. When an application accesses a DoH or DoT service directly, those queries appear as ordinary HTTPS or encrypted connections and are not automatically converted into Clash DNS requests merely because dns-hijack is configured. You can use rules to control the outbound path for known resolver services, or disable the application’s secure DNS so resolution follows a unified system-and-core path.

Permissions, Routes, and Platform Differences

System Proxy usually changes the current user’s network proxy settings; disabling it restores the previous values. TUN must create a virtual interface, add routes, adjust DNS, or call a system service, so it requires more permissions. Depending on the client, these actions may be completed through administrator elevation, a privileged helper service, or a network extension.

Windows

On Windows, enabling TUN usually requires administrator privileges or a preinstalled service running with the appropriate permissions. If the interface says TUN is enabled but traffic still uses the original network, check whether the virtual adapter was created, whether the default route was added, and whether security software or the firewall is blocking the core process. After sleep, network changes, or an abnormal exit, also verify that the system DNS and routes have been restored.

macOS

On macOS, the implementation may use a system network extension, virtual interface, or authorized helper process. System authorization is normally required the first time it is enabled. Management policies on company devices may restrict network-extension installation. If browsers work but terminal or UDP applications do not, first confirm whether System Proxy or TUN is actually enabled instead of immediately switching nodes.

Linux

Creating a TUN interface and writing routes on Linux requires root privileges or the relevant capabilities, such as granting a service network-management permissions. Command-line deployments must also handle default-route detection, policy routing, systemd startup ordering, and coordination between DNS managers. NetworkManager, systemd-resolved, and container networking may all modify routes or resolver settings, so clearly identify which component owns the final state.

Containers and virtual machines are common boundaries. After TUN is enabled on the host, whether guest traffic passes through that interface depends on bridging, NAT, forwarding rules, and route design. A browser test on the host alone cannot prove that container traffic has entered Clash.

How to choose the right use case

When to prefer System Proxy

• You mainly use browsers, code editors, and desktop software that supports System Proxy.
• You want minimal network changes, easy toggling, and simpler fault isolation.
• The current account cannot install a virtual interface or modify routes.
• The LAN, VPN, virtual-machine, or corporate-network environment is complex, and you need to avoid additional route conflicts.
• You only need a small number of applications to use the proxy and can specify an HTTP or SOCKS address within each application.

Development tools need separate verification. Git, package managers, Docker clients, and terminal download tools do not necessarily read the graphical interface’s System Proxy setting. Follow each tool’s documentation to configure proxy environment variables, or enter the local SOCKS/HTTP listening address directly. System Proxy is best when you want coverage to remain visible and controllable at the application layer.

When to prefer TUN

• The application ignores System Proxy or provides no proxy-settings interface.
• You need to handle UDP, game connections, command-line programs, or traffic that mixes multiple protocols.
• You want domain resolution, rule matching, and application connections to follow a more consistent path.
• You need to process global network traffic by process, destination subnet, or complex rules, and the client core supports the required capabilities.
• You can manage administrator privileges, system services, route restoration, and LAN bypass rules.

TUN is better suited to environments where applications cannot be controlled but the system network can be. It is not a speed-boost switch. Latency and throughput still depend mainly on the node route, congestion, transport protocol, MTU, DNS response time, and destination service. If speed drops after enabling TUN, check for routing loops, an incorrect IPv6 path, an MTU mismatch, or DNS fallback delays instead of immediately blaming the virtual adapter.

Can both modes be enabled at once?

Many clients allow System Proxy and TUN to be enabled simultaneously. This can cover both applications that explicitly read proxy settings and other traffic, but it adds troubleshooting variables. Some connections may first enter the local proxy port, whose outbound traffic is then affected by TUN routing. Mature implementations usually configure interface exclusions and process bypasses to prevent loops, but client-service failures, manual routes, or an external VPN can still invalidate those safeguards.

There is no need to keep both enabled simply to “cover more” in daily use. Choose one entry point based on the application types involved. If System Proxy meets the need, a single entry point is easier to maintain; test TUN only when an application actually ignores the proxy.

Troubleshoot in layers: entry point, DNS, rules, and outbound

When switching proxy modes causes a problem, verify the data path layer by layer instead of repeatedly changing nodes. The sequence below narrows the possible cause.

1. Confirm that the core is running. Check the client status, local listening ports, and recent logs. If the core has not started, neither System Proxy nor TUN can forward traffic effectively.
2. Confirm that traffic enters the core. Visit a test site or make one clearly defined request, then check whether the destination appears in the connection list. No record usually means the application did not read System Proxy, or the TUN route is not active.
3. Confirm the DNS request path. Compare system resolution results, the client’s DNS logs, and the browser’s secure DNS settings. Do not draw a conclusion from a single web-based test.
4. Confirm the rule match. Check which rule matched the destination connection and which policy group handled it. Rules are generally evaluated from top to bottom; the first matching rule determines the action.
5. Confirm the policy-group selection. A policy-group name showing “Proxy” does not mean its internal node is available. Check the currently selected node, latency test results, and failure logs.
6. Confirm the outbound interface. With TUN enabled, especially check that the core selected the correct physical network adapter and is not sending the proxy server connection back into TUN.

Under System Proxy, test the results both “without a proxy” and with a “local proxy explicitly specified.” The port below is only a common example; replace it with the listening port currently shown by the client:

curl https://example.com
curl --proxy http://127.0.0.1:7890 https://example.com
curl --proxy socks5h://127.0.0.1:7890 https://example.com

Hostname resolution in socks5h is handled by the SOCKS proxy, making it useful for comparison with local resolution. If an explicitly specified proxy works but ordinary requests fail, the problem is most likely that System Proxy or the environment variables are not being read. If both requests enter the core but match different rules, check whether the request carries a domain name or an already resolved IP address.

Under TUN, first check that the system has the expected virtual interface and routes, then see whether a request appears in Clash connection records. If TCP works but UDP does not, verify support for the UDP path in the core, node protocol, rules, and destination service. If a LAN printer or router administration page becomes unreachable, check that private subnets remain DIRECT and that automatic routing has not covered the local network.

Bottom line: start with the smallest necessary coverage, then expand

For browsers and standard desktop applications, System Proxy is usually the most direct starting point. It requires fewer permissions, has a clear connection entry point, and makes it easier to tell whether an application has read the proxy settings. For command-line programs, add environment variables or the tool’s own proxy configuration as needed.

Enable TUN when applications ignore proxy settings, UDP is required, a more consistent DNS path is needed, or you want routing to cover more processes. After enabling it, also check administrator privileges, the virtual interface, automatic routes, physical-egress detection, DNS hijacking, LAN bypasses, and IPv6 behavior.

Both modes ultimately send connections into the same Clash or mihomo rule system. System Proxy answers “will the application hand traffic to the core?”, while TUN answers “will the system send packets to the core?” Identify whether the fault is in the entry point, DNS, rules, or outbound path before changing the corresponding configuration; this avoids blaming every connection problem on the node or subscription.