How to Enable Clash TUN Mode: Full-Traffic Interception Explained and Configuration Checks

What Problems Does TUN Mode Solve?

A conventional system proxy relies on applications actively reading the proxy settings configured in the operating system. Browsers, some download tools, and common desktop applications can usually hand HTTP or HTTPS requests to Clash this way. Game launchers, command-line programs, standalone updaters, and apps with their own network stacks may connect directly to the destination instead. Even with the system proxy switch enabled, those connections bypass Clash.

TUN mode creates a virtual network interface and adds the corresponding routes to the operating system. IP packets that meet the routing conditions first enter the virtual interface, where Clash or the mihomo core identifies the destination, applies the rules, and selects either a direct or proxy route. Because it handles traffic at the network-layer entry point, it generally covers more applications than a system proxy.

“TUN interception” and Clash “Global” mode are not the same setting. TUN determines whether traffic can enter the core; Rule, Global, and Direct modes determine how the exit is selected after it gets there. After enabling TUN, you can still use Rule mode to send mainland China addresses directly and route selected domains through a proxy. Global mode can also be enabled temporarily for troubleshooting.

How the Virtual Interface Captures Traffic

When an application opens a connection, the operating system first consults the local routing table. With TUN and automatic routing enabled, the client adds routes pointing to the virtual interface while preserving paths to the LAN, default gateway, and essential system addresses. Once a packet reaches the TUN interface, the core reconstructs the connection details and passes the destination to the rules engine.

1. The application requests a domain lookup, and the DNS query enters the system resolver or Clash DNS module.
2. The operating system uses the routing table to send the destination connection to the virtual network interface.
3. Clash matches the connection by domain, destination IP, port, process information, or rule set.
4. The matched proxy group selects a specific proxy node or direct exit.
5. The outbound connection leaves through the physical network interface, and returned data is passed back to the application through the virtual interface.

DNS and routing must stay consistent throughout this path. If an external DNS resolver returns the address directly while the rules depend on domain classification, the core may see only the resolved IP and fail to match the intended domain rule. With mihomo’s enhanced Fake-IP mode, the DNS module returns a controlled virtual address for the domain and stores the domain-to-connection mapping internally. When the application connects to that address, the core can restore the original domain before applying domain rules.

Fake-IP is not the right choice for every environment. LAN device discovery, some games, enterprise intranet domains, and programs that rely on the real address may need to be added to an exclusion list. If the client supports it, you can also switch to Redir-Host. Choose based on whether domain-rule detection remains reliable and whether local network services stay reachable.

Check the Core, Subscription, and Permissions First

First confirm that the client’s core supports TUN. The widely used mihomo core provides TUN, automatic routing, interface auto-detection, and support for multiple protocols, but graphical clients do not expose identical controls. Some place TUN under Settings or Service Mode, while others require a system service to be installed first. Older clients that are no longer maintained may ship with an earlier core, so their configuration fields and operating-system compatibility can differ.

1. Update and Load a Valid Subscription

TUN changes only the traffic entry point; it cannot repair an invalid node. Before enabling it, manually update the subscription, confirm that the current configuration has loaded, and choose a reachable node in the proxy group. Test browser access through the system proxy first. If the regular proxy cannot establish a connection either, check the subscription URL, node status, proxy-group selection, and local network before proceeding.

2. Prepare System Permissions

Creating a virtual network interface and changing routes typically requires elevated privileges. A Windows client may require a service component or administrator privileges during initial setup; macOS may request approval for a network extension or VPN configuration; Android clients generally use the system VPN interface and display a VPN connection confirmation. After granting access, return to the client and verify the TUN status instead of relying only on the system dialog.

3. Record the Existing Network Settings

Before enabling TUN, note any active VPN, virtual-machine interfaces, corporate security clients, DNS tools, and default gateway. When multiple programs modify the default route or DNS, the one started later may override the earlier configuration. During troubleshooting, keep only one traffic-interception tool active, confirm the basic connection, and then restore the other programs one at a time.

How to Enable Clash TUN Mode

Interface labels vary between clients, but the underlying process is largely the same. The sequence below applies to common desktop clients using the mihomo core. If the client offers a graphical switch, use it first. Before editing YAML directly, confirm that the client will not overwrite that section when saving its settings.

1. Launch the client and update the current subscription, confirming that the configuration loads without parsing errors.
2. On the proxy or proxy-group page, select a reachable node and keep the operating mode set to “Rule.”
3. Open Settings and find the option for TUN, virtual network interface, or traffic interception.
4. If the interface asks you to install Service Mode, an auxiliary service, or a network extension, complete the installation and system authorization first.
5. Enable TUN and automatic routing. If interface auto-detection is supported, enable it as well.
6. Check the client’s status area and confirm that TUN is running, rather than stuck at “Awaiting authorization” or “Startup failed.”
7. Turn off the system proxy for an end-to-end test and check whether applications that previously ignored the proxy can still connect according to the rules.

The mihomo configuration snippet below illustrates the relationship between the fields. The fields that actually work depend on the client’s built-in core version; configurations generated by a graphical client should be verified against its interface and logs.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

enable controls whether TUN starts; auto-route lets the core add the required routes automatically; auto-detect-interface identifies the current physical outbound interface; and stack selects the network-stack implementation used by TUN packets. Some clients offer options such as system, gVisor, or mixed, with support varying by platform and core version. In most cases, start with the client default and switch only when troubleshooting a specific UDP, performance, or compatibility issue.

The public DNS servers in the example are shown only to illustrate the field structure. In practice, use a resolver reachable from your local network, or configure DoH or DoT according to your subscription and client documentation. The key requirements are a stable path to the resolver and consistency with the rule-matching path.

Verify Interception with DNS, Routing, and Rules

A switch showing Enabled does not mean every part of the path is working. Verify the setup in layers: start with the client logs, then check DNS and routing, and finally test the specific application. This helps distinguish a virtual interface that never started from a rule selecting the wrong exit or a restriction imposed by the target application.

Check the Client Logs

After starting TUN, look for permission errors, interface-creation failures, route-write failures, or port conflicts in the logs. Then open the target application; its connections should appear there. No log entry usually means the traffic never entered TUN. If entries appear but connections fail, continue by checking rule matches, node status, and DNS.

Check Domain Resolution

Run a system DNS query and confirm that it returns a result. In Fake-IP mode, some ordinary domains may resolve to virtual addresses within the configured range; this is part of the mapping process and does not mean the destination server’s real address has changed. If every domain times out, check the DNS listener, upstream resolver, firewall, and other DNS software.

Check Rule Matches

Find the test domain in the connection list or logs and confirm that it matched the expected rule and proxy group. In Rule mode, the final rule usually handles connections not matched earlier. If that rule points to Direct, the connection will still leave through the local network even though TUN has captured it.

Test TCP, UDP, and LAN Separately

Browser access mainly tests TCP and DNS, so it does not cover every scenario. Also test an application that requires UDP, and access a router administration page, printer, or other LAN service. If external connections work but LAN services are unreachable, check whether automatic routing incorrectly captured private addresses and whether the client offers a private-address bypass option.

Common Conflicts and Recovery Order

Most TUN problems occur at one of four layers: permissions, DNS, routing, or application conflicts. Follow a consistent troubleshooting order instead of reinstalling the client immediately. Retest after each step and watch for changes in the logs.

TUN Is Enabled but the Device Cannot Connect

First disable TUN and confirm that the basic network connection returns. Then check the selected proxy node and final rule. If both Direct and proxy connections fail, check whether DNS points to an address that is currently unreachable. Once the basic connection is restored, restart the client and enable automatic routing. If the problem persists, temporarily exit other VPNs, virtual-machine network tools, and standalone DNS programs.

It Stops Working After a Restart or Network Change

After switching from wired networking to Wi-Fi, connecting to a hotspot, or waking the device, the default outbound interface may change. Interface auto-detection reduces manual configuration, but the client may still need to rebuild TUN. Turn TUN off and on again, then confirm that the new default gateway was detected. Devices that switch networks frequently should also avoid hard-coding an interface name that no longer exists.

LAN Devices Cannot Be Reached

Printers, NAS devices, and router administration pages typically use private addresses or local domains. Check that the rules allow these addresses to connect directly and that routing is not sending LAN traffic to the proxy exit by mistake. Local domain services may also depend on local DNS or multicast discovery. If necessary, add the relevant domains to the Fake-IP exclusions while preserving the local resolution path.

Some Applications Loop Connections or Fail to Sign In

Start by checking the destination domain and exit in the connection logs. If the application depends on a real IP, LAN loopback, or special UDP behavior, create a more precise Direct rule for the domain or process. Place it before broad rules so it is not matched earlier by a domain suffix or rule set. Re-establish the connection after making changes; existing connections do not always adopt the new policy automatically.

The Network Does Not Recover After Closing the Client

First confirm that both the client process and its service have exited, then disable the system proxy or VPN configuration. The operating system usually removes temporary routes created by the client. If problems remain after an abnormal exit, disable and re-enable the physical network interface, or restart the system to rebuild the network state. Restore the basic connection before launching the client again, and avoid switching several interception tools while stale state remains.

How to Combine TUN, the System Proxy, and Operating Modes

If you use only a browser and desktop programs that explicitly support proxy settings, a system proxy is simple and the troubleshooting scope is small. Enable TUN when you need to capture games, terminal tools, store apps, or other software that ignores the system proxy. Some clients allow the system proxy and TUN to run together, but that does not mean both are required. During testing, turn off the system proxy and use TUN alone to assess coverage.

For everyday use, the usual combination is “TUN interception + Rule mode.” TUN sends traffic into the core, while Rule mode splits it by domain, address, and rule set. Global mode is useful for briefly determining whether a failure is caused by the rules, but keeping it enabled long term bypasses fine-grained routing. Direct mode can confirm whether an application can reach the destination over the local network.

On mobile devices, TUN is often implemented through the system VPN interface, which normally allows only one system-level VPN connection at a time. As a result, enabling a Clash-based client may disconnect another VPN app. Desktop systems may support multiple virtual interfaces, but the default route, DNS, and interface priority can still conflict. A stable setup usually designates one primary interception tool.

Complete Post-Setup Checklist

• The subscription is updated and the current configuration loads normally.
• A reachable node is selected in the proxy group, and the final rule behaves as expected in Rule mode.
• System service, network extension, or VPN permissions have been granted.
• TUN shows as running, with no interface-creation or route-write errors in the logs.
• DNS queries complete successfully, and domain rules can identify and match their targets.
• After the system proxy is disabled, applications that ignore proxy settings still produce connection logs.
• TCP, UDP, and LAN access have each been tested separately.
• After a network change or device wake-up, the default outbound interface is still detected correctly.
• Other VPNs, virtual machines, and DNS tools do not modify the current routes again.
• The basic network connection returns after TUN is disabled and the client is closed.

After these checks, the TUN path can be divided into four clear stages: system permissions create the virtual interface, routing sends packets into the core, DNS supplies target information that rules can identify, and the proxy group selects the final exit. When something fails, locating the issue stage by stage is more effective than repeatedly reinstalling configurations or switching nodes.