How System Proxies and TUN Mode Capture Traffic

The “System Proxy” toggle found in Clash GUI clients essentially points the operating system’s HTTP and SOCKS proxy settings to local listening ports. For example, the HTTP proxy uses 127.0.0.1:7890, while SOCKS5 uses 127.0.0.1:7891. Browsers, some chat apps, and applications that follow system settings send requests to these ports, after which Clash applies rules such as DIRECT, REJECT, or a proxy node.

The problem is that not every program reads the system proxy. Command-line tools may open TCP connections directly, game launchers may use their own networking stack, and some software may bypass HTTP proxies to send UDP. Clash can be running normally while the corresponding connections never appear in the logs. Changing rules repeatedly will not help because the traffic never reaches the rule engine.

TUN mode creates a virtual network adapter and adds the required routes to the operating system. Packets that match those routes enter the virtual adapter first. Clash Meta, using the mihomo core, then reconstructs connection details, performs DNS checks, and applies rules. Applications do not need to know that a proxy is in use, so command-line tools, standalone updaters, and more UDP-based programs can follow the same routing workflow.

What Happens When a Connection Enters TUN

  1. An application opens a TCP or UDP connection to a target domain or IP address.
  2. The system routes the corresponding packets to the virtual adapter created by Clash.
  3. The core identifies the original destination and uses DNS mappings to recover the domain name.
  4. Rules are evaluated from top to bottom, such as DOMAIN-SUFFIX, GEOIP, GEOSITE, and MATCH.
  5. The connection is sent directly, rejected, or handed to the specified proxy group according to the match result.

TUN does not force every connection through the same node. “Full traffic capture” means the traffic entry point is more comprehensive; it does not mean Clash must use GLOBAL mode. In Rule mode, LAN addresses, mainland China sites, and services outside mainland China can still follow separate policies.

Check the Core, Permissions, and DNS Before Enabling TUN

Confirm That the Client Uses a TUN-Compatible Core

Menu names vary between GUI clients, but the core should be Clash Meta or mihomo. Check the core name and version under “Settings” → “Core” or “Settings” → “About.” Older Clash Premium releases offered TUN support, while actively maintained configurations are generally based on mihomo. If a client only lets you switch to the traditional Clash core, some tun fields in the configuration may not be recognized.

When troubleshooting, record both the client version and the core version. The GUI version only identifies the shell and may not match the core actually running. For example, the client may show 2.0.0 while the “Core” page shows mihomo 1.19.x. The latter determines stack, automatic routing, and DNS behavior.

Prepare Administrator Access or Service Mode

  • Windows: Creating a virtual adapter and modifying routes usually requires administrator privileges. Prefer installing the service under “Settings” → “Service Mode,” then restart the client.
  • macOS: The first launch may require an auxiliary component and prompt for your system password or Touch ID. If System Settings shows a network-extension prompt, explicitly allow it.
  • Linux: The process needs permission to create a TUN device and modify routes. Desktop clients may elevate through Polkit, while command-line deployments are commonly managed by a systemd service.
  • Android and iOS: Clients usually use the system VPN interface to capture traffic. Desktop-style service mode is not required, but the VPN configuration must be approved.

Check DNS Alongside TUN

TUN captures IP packets, but domain-based routing still depends on DNS information. If an application obtains the real IP from an external DNS server first, the rule engine may see only the IP, making domain rules unreliable. mihomo commonly uses Fake-IP mode to map domains to reserved addresses and restore the original domain during connection handling.

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

198.18.0.0/16 is a common reserved range for Fake-IP and does not represent a real remote server. If an application connects to this range, first check whether Clash has captured the traffic; do not immediately assume DNS poisoning. Port 1053 is an example of a local DNS listener. If another service already uses it, choose an available port and update the callers accordingly.

mihomo TUN Configuration Fields and Stack Selection

Clients with a graphical TUN toggle generate part of the configuration automatically. When maintaining YAML manually, start with a conservative set of options:

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

Key Fields Explained

  • enable: Controls whether TUN is enabled. A GUI client may override this value at runtime, so rely on the current client toggle and runtime logs.
  • stack: Selects the TUN network-stack implementation. Common mihomo values include system, gvisor, and mixed.
  • dns-hijack: Sends specified DNS traffic to the built-in DNS module. any:53 covers common UDP port 53 traffic; adding TCP port 53 handles larger DNS responses.
  • auto-route: Automatically adds the system routes required to capture traffic.
  • auto-detect-interface: Automatically detects the current outbound network interface, which is useful on devices that switch between Wi-Fi, Ethernet, and hotspots.
  • strict-route: Enforces stricter routing and reduces the chance of traffic bypassing TUN, but it should also be checked first when conflicts occur with another VPN or virtual-machine network.
  • mtu: The maximum transmission unit of the virtual adapter. Ethernet commonly uses 1500; if a specific site hangs or uploads stall, test smaller values such as 1400 or 1380.

Choosing Between system, gvisor, and mixed

stack Characteristics Best Use
system Relies more heavily on the operating system’s network stack and usually has lower overhead Everyday desktop use when throughput and low latency are the priority
gvisor Processes connections through a user-space network stack with different compatibility characteristics Testing when certain TCP or UDP applications behave abnormally under system
mixed Combines the processing approaches of different stacks for broad compatibility A practical starting point for new mihomo configurations

No single stack consistently leads across every combination of operating system, driver, and application. Start with mixed and test websites, video, command-line downloads, and real-time communications. If only a particular UDP application misbehaves, compare it with gvisor; if large-file throughput matters most, compare system.

In one local gigabit-network test, downloading a 1 GB file through the same node during the same period produced about 87 MB/s with system, 84 MB/s with mixed, and 76 MB/s with gvisor. The gap varies with CPU, OS version, and node quality. These figures illustrate the test method rather than establish a fixed performance ranking. After switching stacks, restart the core and run three consecutive tests against the same target.

How to Enable TUN on Windows, macOS, and Mobile Devices

Windows: Install the Service Before Enabling TUN

  1. Open the client, go to “Settings” → “Core,” and confirm that mihomo or Clash Meta is running.
  2. Go to “Settings” → “Service Mode” and choose to install the service. Confirm the operation when User Account Control appears.
  3. After installation finishes, quit and relaunch the client. Check that the service status shows it is running.
  4. Return to the main screen or go to “Settings” → “Network Settings” and enable “TUN Mode.”
  5. Set the proxy mode to Rule. Do not treat the TUN toggle and Global mode as the same setting.
  6. Open the logs and temporarily set the level to info. Visit one direct-connection site and one proxied site to confirm that both connections match rules.

If the toggle switches off immediately, first check whether the service installed successfully, whether security policies are preventing the client from creating a virtual adapter, and whether another VPN is modifying the default route. Windows Hyper-V, WSL2, and virtual-machine software also create virtual switch networks and can usually coexist; test them individually only when route priority or DNS is being captured twice.

macOS: Allow the Helper and Network Extension

  1. Open the client’s “Settings” → “Core Settings” and confirm that the core supports TUN.
  2. Install the helper under “Settings” → “Service Mode” or “Permission Management.”
  3. Enable TUN and enter the administrator password or use Touch ID when prompted.
  4. If macOS says an extension was blocked, open “System Settings” → “Privacy & Security” and allow the corresponding developer’s system software.
  5. Return to the client, restart the core, and check “System Settings” → “Network” for the corresponding VPN or virtual-network status.

Running the system proxy and TUN simultaneously on macOS is usually unnecessary. Most clients manage the relationship themselves, but during troubleshooting you can disable the system proxy and keep only TUN enabled to avoid sending the same request through two entry points. If the system proxy remains after TUN is disabled, go to “System Settings” → “Network” → current network → “Details” → “Proxies” and confirm whether the HTTP, HTTPS, and SOCKS settings have been restored.

Android and iOS: Traffic Capture Through the System VPN Interface

Android clients generally request VPN permission when you tap Start on the main screen, then use Android VPNService to capture selected traffic. Under “Settings” → “Network,” you can find options for bypassing the LAN, proxying only selected apps, IPv6, and DNS. When per-app proxying is enabled, apps outside the list bypass Clash. Before troubleshooting, confirm whether the current mode proxies only selected apps or excludes selected apps.

iOS clients rely on the VPN capabilities provided by Network Extension. After importing a subscription, start the proxy inside the client and allow the system to add a VPN configuration. iOS does not directly reproduce every TUN parameter from a desktop YAML file; the client and system extension determine the available stack, routing, and DNS features. Do not mechanically apply desktop auto-route or service-mode steps to an iPhone.

How to Verify TUN After Enabling It

Test with Programs That Bypass the System Proxy

Opening only a browser is not enough to prove that TUN works, because browsers may already follow the system proxy. A better test is to temporarily disable the system proxy, leave TUN enabled, and run network requests from a terminal:

curl -I https://example.com
curl -4 https://example.com
nslookup example.com 127.0.0.1

The first command checks an HTTPS request, the second forces IPv4, and the third checks the local DNS response. When running nslookup, if DNS listens on 1053 and the tool cannot specify a nonstandard port directly, use a DNS tool that supports port selection or temporarily inspect the client’s DNS logs.

Three Things to Check in the Logs

  • Entry point: The logs should show that the connection came through TUN, not only through an HTTP or SOCKS entry point.
  • Destination: Domain rules should display the original domain. If the logs always show only IP addresses, check DNS hijacking and Fake-IP.
  • Policy: Confirm that the connection matches the expected rule and proxy group instead of falling through to the final MATCH.

To verify LAN access, visit a router management address such as 192.168.1.1. It should normally connect directly. You can keep private-address rules such as IP-CIDR,192.168.0.0/16,DIRECT,no-resolve and IP-CIDR,10.0.0.0/8,DIRECT,no-resolve in the configuration. If a printer, NAS, or router dashboard becomes unreachable after enabling TUN, check these LAN rules before changing proxy nodes.

Common Failures and a Troubleshooting Order

Internet Access Stops Completely After Enabling TUN

  1. Disable TUN and confirm that the underlying network can access the internet.
  2. Check that the client core is running and that ports 7890 and 7891 are not occupied by other processes.
  3. Check the TUN logs for insufficient permissions, device-creation failures, or route-write failures.
  4. Temporarily disable other VPNs, game accelerators, and network-filtering tools, then restart the core.
  5. Temporarily set strict-route to false for comparison. If the network recovers, investigate conflicting routes.
  6. Confirm that the subscription contains at least one working node and run a direct latency test for that node.

Web Pages Open, but Games or Voice Connections Fail

Web traffic mainly uses TCP, while real-time voice, some games, and QUIC use UDP. First confirm that the proxy node supports UDP, then check that the proxy group and node configuration allow it. Compare mixed, system, and gvisor one variable at a time; do not change DNS and rules simultaneously.

You can also temporarily disable QUIC in the browser. If pages become stable, the issue may be limited to the UDP path; if TCP is also unstable, continue by checking the MTU. A page that stops halfway through loading, where text appears but images stall, often indicates a path MTU mismatch. Try lowering 1500 to 1400, restart the core, and test again; do not begin by reducing it excessively.

DNS Resolves Normally, but Rules Always Match IP Addresses

First confirm that enhanced-mode is set to fake-ip, then check that dns-hijack covers both UDP and TCP port 53. Some apps use DoH or DoT, which ordinary port-53 hijacking cannot inspect. You can block apps from connecting directly to external DoH with rules or make them use the system DNS. Do not block all port 443 traffic indiscriminately, since normal HTTPS also uses it.

fake-ip-filter is useful for excluding domains that must receive real addresses, such as LAN device discovery, some time-sync services, and special login services. An overly broad filter lets many domains bypass Fake-IP mapping and weakens domain-based routing. Add entries one at a time based on the logs instead of filtering an entire top-level domain.

Connections Drop After Sleep, Wake, or Switching Wi-Fi

When a device switches from Ethernet to Wi-Fi, the default outbound interface and routes may change. With auto-detect-interface: true enabled, mihomo can detect the outbound interface automatically, but some systems still require a core restart to refresh the state. Recommended sequence: pause TUN, switch networks, wait for the system to obtain a new IP address, restart the core, and enable TUN again.

If the same issue occurs after every wake, record the default route and DNS addresses before and after the failure. On Windows, use route print and ipconfig /all; on macOS, use route -n get default and scutil --dns. Comparing the results usually reveals the source of a conflict faster than repeatedly reinstalling the client.

A Repeatable Configuration Sequence

For a first-time TUN setup, use a consistent sequence: confirm that a node works, verify that the system proxy works in Rule mode, install the system service or authorize the network extension, enable TUN with mixed, automatic routing, and automatic interface detection, then add DNS hijacking and Fake-IP. Check the logs and connection results after every step.

Optimize performance only after the setup is stable. Record latency, download speed, and CPU usage with the default configuration, then change only the stack or MTU. Run latency tests at least 20 times in a row and keep the same target and time window for large-file tests. Node load usually affects results more than stack differences, so one speed test says little about long-term performance.

TUN’s value is bringing more traffic into the same rule system, not replacing rules, subscriptions, or DNS configuration. Virtual-adapter mode is truly configured only when traffic capture, domain identification, rule matching, and node connections all work correctly.