TUN Mode vs. System Proxy: How Traffic Interception Works at Different Network Layers

The Core Difference: Proxy Settings and Virtual Adapters Operate at Different Layers

Both system proxy mode and TUN mode can send traffic into the Clash Meta (mihomo) core, but they use different entry points. A system proxy registers an HTTP, HTTPS, or SOCKS proxy address with the operating system, such as 127.0.0.1:7890. After reading this setting, an app actively forwards its requests to the local proxy port. TUN mode creates a virtual network interface and uses routing rules to send matching IP packets into the core.

This difference determines how much traffic is covered. Browsers, system updaters, and many desktop apps usually read the system proxy, so enabling it is often enough. Some game launchers, command-line programs, UDP-based communication apps, and applications with their own network stacks may ignore the system proxy. In those cases, TUN is more likely to capture the traffic.

How the System Proxy Delivers Requests to mihomo

Apps must actively read the proxy address

When you enable the “System Proxy” switch in the client, it writes the local proxy address to the operating system. In Windows 11, check the current setting under “Settings” → “Network & internet” → “Proxy”. On macOS, open “System Settings” → “Network” → the current network interface → “Details” → “Proxies” to review the HTTP, HTTPS, and SOCKS entries.

Assume mihomo uses 7890 as its mixed port. After reading the system settings, the browser sends requests to 127.0.0.1:7890. The core obtains the domain, destination address, and connection details, then matches rules from top to bottom and ultimately selects DIRECT, REJECT, or a policy group. The system proxy only “delivers the request”; it does not change the rule mode, node selection, or DNS strategy.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH, node selection

mixed-port accepts both HTTP and SOCKS requests. Its common default is 7890, but different clients may assign 7897, 7899, or another port. When checking the configuration, use the actual listening port shown by the client rather than relying on the example port.

Which Programs May Bypass the System Proxy

• The app implements its own connection logic and explicitly ignores the operating system’s proxy settings.
• The command-line tool does not read environment variables, and HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY has not been configured.
• A game or real-time communication app mainly uses UDP, which a system HTTP proxy cannot carry.
• A sandbox, virtual machine, container, or subsystem has its own network environment and cannot directly inherit the host’s proxy address.
• The app supports only SOCKS while the system has registered only an HTTP proxy, or it reads only HTTP when the opposite is configured.

Command-line programs are a common example. If curl still connects directly after you enable the system proxy, explicitly specify the local proxy first to verify the path:

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

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

If an explicit proxy works but the command without one does not, the mihomo port and rules are probably working. The issue is likely whether the program reads the system proxy. There is no need to immediately change the node or subscription.

How TUN Captures TCP, UDP, and DNS Traffic

Virtual Interface and Automatic Routing

After TUN mode starts, the client creates a virtual network interface. mihomo can use auto-route to add routes that direct target traffic to this interface. The app still believes it is connecting directly to the destination server, but the packets first enter mihomo. The core reconstructs the connection target, matches the rules, and sends the traffic through a direct or proxied outbound.

Using fields available in the mihomo v1.19 series as an example, a basic configuration may include the following. GUI clients usually manage these fields automatically, so check whether the client overwrites the configuration during subscription updates before editing it by hand.

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

• enable controls whether the TUN interface is enabled.
• stack selects the network-stack implementation. mixed combines different processing methods and is a suitable starting point for general use.
• dns-hijack sends matching DNS requests to the mihomo DNS module for processing.
• auto-route automatically adds the required routes, reducing the need to maintain the routing table manually.
• auto-detect-interface attempts to identify the current default outbound interface, such as Wi-Fi or an Ethernet adapter.
• strict-route enforces routing more aggressively, reducing the chance of traffic bypassing TUN. It may also reveal conflicts with corporate VPNs and virtual-machine networks.

TUN captures packets that system routing sends to the virtual interface. It does not mean that every connection on the device is covered in every situation. Connections created by the core itself, reserved LAN addresses, explicitly excluded routes, traffic already captured by another VPN, and special services restricted by the operating system may still take different paths.

Why DNS Is a TUN Troubleshooting Priority

Apps usually resolve a domain before opening a connection. If the DNS query uses the local network while the subsequent TCP connection enters TUN, the resolved location may not match the proxy exit, rules may see only an IP address, or a polluted result may be cached. After enabling TUN, verify that mihomo’s DNS module, dns-hijack, and rule configuration are aligned.

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  fallback:
    - tls://8.8.8.8:853

In fake-ip mode, temporary addresses are assigned from a reserved range, and the core restores the original domain from the mapping. Some LAN device discovery, printer services, older games, and software that depends on real DNS results may not work well with fake-ip. Use fake-ip-filter to exclude the relevant domains, or switch to another enhanced mode if the client supports it.

Balancing Compatibility, Performance, and Permissions

Coverage Is Not the Only Metric

The main advantage of a system proxy is predictable behavior. The app connects to a local port, and mihomo logs can usually show the requested domain, matched rule, and policy-group result directly. After the system proxy is disabled, the operating system restores its previous settings, with less impact on the routing table and virtual interfaces. This approach is usually suitable for everyday web browsing, code hosting, and regular desktop software.

TUN’s main value is compatibility and unified interception. It can handle TCP apps that do not read proxy settings and cover many UDP scenarios. The trade-off is that traffic passes through a virtual interface, network-stack conversion, and routing decisions, so troubleshooting must also account for drivers, permissions, DNS, and other networking software.

Measure Performance Under Consistent Conditions

On the same Windows 11 24H2 device, using the same node, mihomo v1.19.x, rule mode, and DNS settings for 100 HTTPS requests, the median connection time between system proxy and TUN may differ by only a few milliseconds. In one local test, the median was 184 ms with system proxy and 189 ms with TUN. After switching to another distant node, both exceeded 420 ms. This suggests that the node route and destination server usually affect latency more than the interception method.

For testing, keep the node, rules, DNS, target URL, and network interface fixed, and record 50 to 100 results for each mode. Comparing only the peak from a single speed-test page can easily mistake caching, congestion, or server load for TUN overhead.

• Unexpected web or download speeds: compare direct access, system proxy, and TUN on the same node first.
• Unexpected game latency: check whether UDP is being captured and whether the rules send the game servers to the expected policy group.
• Unexpected CPU usage: inspect the connection count, log level, rule size, and DNS query volume instead of looking only at the TUN switch.
• Unexpected battery drain while idle: check background connection frequency, LAN broadcasts, and whether the client keeps rebuilding the virtual interface.

Permission Differences Across Platforms

On Windows, creating a virtual network adapter, adding routes, or installing network components usually requires administrator privileges. macOS asks you to allow a network extension or VPN configuration. Linux commonly requires CAP_NET_ADMIN and permission to create TUN devices and modify policy routes. On Android and iOS, GUI clients usually use the system VPN interface for similar interception, so the status bar displays a VPN indicator.

Successful permission approval does not guarantee correct routing. When switching from Wi-Fi to Ethernet, from a home network to a hotspot, or after waking the device with a different default interface, automatic detection may need to be rebuilt. If the connection works after boot but breaks after changing networks, disable TUN, wait 3 to 5 seconds, then enable it again and check the default interface in the logs.

Choose System Proxy or TUN by Use Case

When to Prefer System Proxy

1. You mainly use browsers, email, chat apps, and standard development tools.
2. You want a quick way to determine whether a request reaches mihomo.
3. A corporate VPN is running on the device, and you do not want two tools competing for the default route.
4. You only need a few apps to use the proxy while other apps keep their existing network paths.
5. Your current account cannot conveniently be granted permission to create a virtual adapter or use a network extension.

If an app provides its own proxy settings, you can enter 127.0.0.1 and the actual mixed port without enabling the system-wide proxy. This limits the impact to one app and is useful for debugging browser settings, download tools, or development environments.

When TUN Is a Better Fit

1. The app explicitly ignores the system proxy but still needs to follow the rules.
2. You need to capture UDP, such as traffic from some games, voice apps, or real-time communication services.
3. You want command-line tools, desktop apps, and background services to follow one consistent rule set.
4. The app cannot accept an HTTP or SOCKS proxy address.
5. You need domain-based rules for connections that would otherwise expose only a direct IP, and the supporting DNS configuration is already in place.

Many clients allow the system proxy and TUN to be enabled at the same time. This usually does not give the same connection a double benefit; instead, it adds another decision path: apps that support the system proxy connect to the local port first, while other traffic is captured by TUN. For an initial setup, enable only one method at a time, verify stability, and then decide whether combining them is necessary.

How to Troubleshoot Network Loss, Proxy Leaks, and Failed Connections

System Proxy Troubleshooting Steps

1. Confirm that the mihomo core is running and that the client status is not “Core stopped”.
2. Check that the local listening port, such as 127.0.0.1:7890, matches the value entered in the system proxy settings.
3. In Windows, open “Settings” → “Network & internet” → “Proxy” and verify the address and port. On macOS, check which protocols are enabled on the network proxy page.
4. Use curl --proxy to make an explicit request and distinguish a “local port failure” from an “app did not read the proxy” issue.
5. Temporarily set the client log level to info or debug and check whether the request appears and which rule it matches.
6. Switch to rule mode and select a clearly working policy group so that a mode issue is not mistaken for a port issue.

If web pages stop opening after the client exits, the usual cause is that the system proxy still points to a local port that is no longer listening. First disable the manual proxy in the operating system, then restart the client. The GUI client’s “Restore system proxy” function can also clear leftover settings.

TUN Troubleshooting Steps

1. Disable the system proxy and keep only TUN enabled to reduce the number of variables.
2. Confirm that the client has administrator privileges, network-extension authorization, or the required Linux network-management capability.
3. Check whether the virtual interface was created successfully and whether the logs report a route-add failure.
4. Check that the default outbound interface is identified as the Wi-Fi adapter, Ethernet adapter, or mobile hotspot currently in use.
5. Temporarily quit other VPNs, game accelerators, and virtual-network software that may modify routes.
6. Test an IP address and a domain separately. If the IP works but the domain fails, check DNS first.
7. Test a LAN address, such as the router’s management page. If it is unreachable, inspect private-network rules and strict-route settings.
8. Disable TUN, wait for the routes to recover, then enable it again. This avoids leaving a stale interface state after repeated toggling.

If the logs show a connection but the destination is unreachable, focus on the rule result, node status, and DNS. If the app’s connection does not appear in the logs at all, focus on system routes, interface conflicts, and whether the app is using another network environment. This split diagnosis provides more information than deleting the configuration immediately.

Conclusion: Start with the Smallest Necessary Interception Scope

System proxy mode suits most browsers and desktop apps: its configuration entry points are clear, permission requirements are low, and problems can be checked layer by layer from “app settings → local port → rules → node”. TUN is better for UDP, command-line programs, and software that ignores proxy settings. It captures broader traffic through a virtual adapter and routing, but also expands troubleshooting to DNS, interface selection, and route conflicts.

In practice, enable the system proxy in rule mode first and verify that the subscription, nodes, policy groups, and DNS all work. Then enable TUN only for apps that genuinely bypass the system proxy. The broader the interception scope, the more important it is to maintain clear configuration boundaries and a consistent troubleshooting order.