How to Enable Clash TUN Mode: Full-Traffic Routing Explained and Platform Setup

How TUN Mode Captures Traffic

Standard system proxy mode relies on the operating system publishing an HTTP or SOCKS proxy address to applications. Browsers, some download tools, and software that follows system network settings hand connections to Clash automatically. Game clients, command-line programs, standalone updaters, and applications with their own network stacks may connect directly to the destination instead. As a result, connections can bypass the proxy port even when the client shows “System proxy enabled.”

TUN mode creates a virtual network interface and uses routing rules to send selected traffic through it. The Clash core reads IP packets from the virtual interface, reconstructs the connection destination, and then applies the proxy rules in the configuration to choose DIRECT, REJECT, or a proxy policy. Return traffic follows the same path back to the application, so the application usually does not need to know about the local proxy port or support HTTP or SOCKS separately.

Here, “full-traffic capture” describes how much traffic enters Clash; it does not mean the GLOBAL proxy mode. After enabling TUN, you can still use Rule mode: send LAN addresses DIRECT, proxy specific domains, reject ad domains, and handle everything else with the fallback rule. Only switching the operating mode to Global makes all processable connections use the selected proxy policy.

TUN primarily handles Layer 3 IP traffic. Domain matching also depends on DNS results and the core’s domain-mapping mechanism. Whether UDP, QUIC, and IPv6 work fully depends on the client’s core, proxy protocol, system permissions, and configuration. Modern mihomo cores generally provide comprehensive TUN support, but desktop clients expose these options differently.

Checks Before Enabling TUN

First, make sure the current subscription works normally. Select a reachable proxy, visit a website with only the system proxy enabled, and verify that the rule list matches the expected policies. If the subscription fails to parse, the proxy is unreachable, or the rules are invalid, enabling TUN will only broaden the failure; it will not fix the underlying connection.

1. Confirm the client core: Check the client’s core information or About page. Newer mihomo cores support options such as TUN, automatic routing, and DNS hijacking; older Clash cores or lightweight clients may omit some of them.
2. Back up the current configuration: Export the active configuration file, or note the subscription name, proxy mode, and DNS settings. When editing YAML, keep indentation consistent and never use tabs for indentation.
3. Check the permission model: Windows commonly uses Service Mode or administrator privileges to manage the virtual interface. macOS may request administrator authorization, while Linux usually needs root access or network-management capabilities granted to the process.
4. Quit other VPNs: Running multiple virtual-interface tools on the same system can create conflicts over the default route, DNS, and firewall rules. Mobile platforms also generally allow only one system VPN tunnel to be active at a time.
5. Record your LAN environment: If you need access to printers, NAS devices, development machines, or a company intranet, note their address ranges and test these direct connections after enabling TUN.

mihomo TUN Configuration Parameters

Most graphical clients provide a TUN switch and generate basic parameters automatically. If you maintain YAML manually, start with a minimal configuration and add options such as strict routing and MTU adjustments only as needed. The structure below is common, but the fields actually supported depend on the core version integrated into the client.

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

enable and stack

enable controls whether TUN is active. stack determines how the core handles network traffic; common mihomo values include system, gvisor, and mixed. The system stack usually offers direct performance, while the gVisor userspace network stack may provide better compatibility in some environments. mixed combines TCP and UDP handling. If the client provides a recommended value, keep its default first; switch and test individual values only when a specific application cannot connect or UDP behaves abnormally.

auto-route and auto-detect-interface

auto-route lets the core add the required routes automatically and direct system traffic to the virtual interface. auto-detect-interface identifies the physical egress interface, preventing the proxy server’s own connection from re-entering TUN and creating a loop. If all connections stop after switching between wired, wireless, and mobile-hotspot networks, restart TUN so the core can detect the egress interface again.

dns-hijack and DNS configuration

dns-hijack with any:53 captures traditional DNS queries on port 53, making name resolution more consistent with Clash rules. It cannot directly intercept DoH or DoT built into an application because encrypted DNS uses different ports and protocols. DNS queries may also fail if DNS hijacking is configured without enabling the core DNS module, so verify dns.enable along with the nameserver, fallback, and policy-resolution settings.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

fake-ip mode returns mapped addresses from a reserved range for domains, allowing the core to retain domain information and match rules. Some LAN devices, game login services, or programs that depend on real DNS responses may not work well with fake-ip. Add the affected domains to the filter list or use another enhanced mode if the client supports it. Do not change the fake-ip range arbitrarily and then reuse the same range for LAN routing, or address conflicts may occur.

strict-route and MTU

strict-route tightens routing constraints and can reduce traffic bypasses on some systems, but it can also expose conflicts among corporate VPNs, virtual-machine interfaces, and special routes. Start with the client default and enable it only after basic connectivity is stable. MTU controls the size of individual packets. If websites load but uploads stall, some sites repeatedly time out, or a game disconnects after login, test values between 1400 and 1500, changing only one parameter before reconnecting.

Windows, macOS, Linux, and Mobile Platform Setup

Windows: Service Mode and the Virtual Interface

Windows desktop clients usually place TUN in the Settings page, Service Mode page, or a network switch on the main screen. Install the service component provided by the client first, then approve the installation with administrator privileges. Service Mode lets a background service create the virtual interface and modify routes, so the entire client process does not need elevated privileges every time it starts.

1. Close other VPNs, game accelerators, and security tools that may be controlling network traffic.
2. In the client settings, install or enable Service Mode or the system service.
3. Select Rule mode and confirm that the subscribed proxies work, then enable TUN Mode.
4. Accept the system permission prompt and wait for the virtual interface to finish creating.
5. Test websites, command-line tools, the target application, and LAN resources in sequence.

If the switch immediately resets, check whether the service is running and whether the client log reports failures creating the interface, writing routes, or accessing the driver. Hyper-V, WSL, and virtual-machine software add virtual switches and interfaces, but their presence does not automatically indicate a conflict. Use the routing table and actual egress path to diagnose the issue instead of deleting every virtual adapter.

macOS: Authorization and utun Interfaces

macOS clients usually establish TUN through a system network extension or a privileged helper process. The first activation may prompt for an administrator password, VPN configuration approval, or network-extension authorization. After approval, the corresponding VPN status may appear in System Settings, and running ifconfig in Terminal may show a new utun interface.

If TUN is connected but carries no traffic, first check whether another VPN is still enabled, then confirm that the client is not sending the proxy server’s own connection back through the virtual interface. Macs managed with a corporate network configuration profile may be restricted by administrator policies. Those restrictions must be handled within the organization’s device-management scope; repeatedly reinstalling the client usually will not change the policy result.

Linux: Permissions, Routes, and Forwarding

Linux requires /dev/net/tun and permission for the process to create interfaces and modify routes. Running as root is useful for short-term testing, but long-term deployments are better served by explicitly granting the required capabilities through a systemd service, container permissions, or capabilities. Minimal systems, containers, and restricted servers must also have the TUN device enabled in the kernel.

ls -l /dev/net/tun
ip addr show
ip route show
ip rule show

These commands can confirm the device node, virtual interfaces, default route, and policy routes. Common Linux issues also include nftables and iptables rules running together, overlapping Docker bridge ranges, existing policy routes on the server, and a firewall that does not permit TUN traffic. Save the current network rules before troubleshooting; never clear the firewall or default route directly on a remote server, or you may lose the management connection.

Android and iOS: System VPN Tunnels

Mobile clients usually use Android VPNService or Apple Network Extension to create a local VPN tunnel. The interface may label this feature “VPN,” “Enhanced Mode,” or “TUN.” The first connection requires system VPN approval. Android may support per-app proxying or app exclusions depending on the client; the exact options on iOS and iPadOS depend on the implementation and system permissions.

Mobile operating systems generally allow only one standard VPN configuration to be active, so a Clash client cannot share the tunnel with a corporate VPN or another proxy tool. Battery-saving policies may also suspend a background client, causing the connection to drop after the screen has been locked. Allow the client to run in the background and avoid enabling multiple network tools that modify DNS at the same time.

How to Confirm That TUN Is Capturing Traffic

The switch state alone is not enough to confirm that the full path is working. Reliable verification should check the virtual interface, client logs, rule matches, and actual application connections. Use this order:

1. Check whether a new TUN, utun, or client virtual interface appears, and confirm that it is enabled.
2. Open the client’s connection list, use an application that previously ignored the system proxy to make a request, and check for the corresponding destination or process record.
3. Check the rule-match result. LAN addresses should go DIRECT under LAN or private-address rules, while the target site should enter the expected policy group.
4. Temporarily disable the system proxy while keeping TUN enabled, then test browser and command-line connections. If the client still records the connections, traffic is entering the core through more than just the system proxy.
5. Test TCP, UDP, IPv4, IPv6, and DNS separately. Not every proxy supports UDP or IPv6 equally, so distinguish node limitations from TUN failures.

On Windows, use route print or PowerShell’s Get-NetAdapter to inspect interfaces. On macOS, use route -n get default and ifconfig; on Linux, use ip route and ip rule. Compare the changes before and after enabling TUN rather than assuming the configuration is correct merely because a default route is present.

Common Conflicts and Step-by-Step Troubleshooting

No applications can connect after enabling TUN

First disable TUN and confirm that system networking recovers, then check the proxy itself. Next, look for interface-creation failures, incorrect default-interface detection, routing loops, or DNS timeouts in the log. If the device has both wired and wireless connections, temporarily keep only one physical egress active and enable TUN again. Set the interface manually only after automatic detection fails, and update the setting if the interface name changes.

Websites load, but games or voice chat cannot connect

This usually calls for checking UDP. Confirm that the selected proxy and protocol support UDP, that the policy group is not using a TCP-only path, and that the client records the relevant UDP session. If the application uses QUIC, temporarily disable QUIC in the application for comparison. Ultimately, identify the cause by checking node capabilities, rule matches, and TUN-stack compatibility.

NAS devices, printers, or the router become unreachable

Check whether private addresses are being sent to the proxy by mistake. Common LAN ranges include 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, although corporate networks may use other ranges. Make sure LAN routes are allowed DIRECT and that the fake-ip range does not overlap the actual network. If access fails by hostname but works by IP, focus on local DNS resolution and fake-ip filtering.

Connections fail after sleep or switching Wi-Fi

After the network returns, the physical egress interface and default route may have changed while TUN retains its old state. Stop TUN, wait for the system to receive a new IP address and DNS settings, then enable it again. If this happens frequently, upgrade to a stable core version supported by the client and check that automatic interface detection is enabled. On mobile devices, also review background-execution and battery-saving restrictions.

Conflicts with Docker, virtual machines, or a corporate VPN

Compare the address ranges and route priorities used by each virtual interface. If a Docker bridge, virtual-machine NAT, corporate VPN, and TUN all claim the same range, the system may send traffic to the wrong interface. Possible fixes include changing the local virtual range, adding explicit DIRECT routes for the corporate network, disabling unused network components, or switching between tools when they cannot run together. Do not broadly change DNS, routes, MTU, and firewall settings at once, or it will be difficult to tell which change helped.

Frequently Asked Questions About TUN Mode

Recommended Order for a Stable Setup

First make sure the subscription, proxy nodes, and Rule mode work normally with the system proxy, then install the required service and enable TUN. For the first test, keep only automatic routing, automatic interface detection, and basic DNS settings. Confirm that browsers, command-line tools, UDP applications, and LAN resources follow the rules. Only then adjust stack, strict-route, MTU, or fake-ip filters in response to an observed issue.

TUN’s main benefit is bringing application connections that would not normally use a proxy into a unified rule set. Stability depends on routing, DNS, permissions, and proxy-node connectivity working together. Troubleshoot in four layers: whether the virtual interface exists, whether traffic enters the core, whether rules match, and whether the node can transmit. Checking each layer is more effective than repeatedly switching every option.