How to Enable Clash TUN Mode: Full-Traffic Capture Explained and Configuration Steps

How TUN Mode Captures All Traffic

Clash's standard system-proxy mode mainly writes an HTTP or SOCKS proxy address to the operating system. Browsers and apps that follow system proxy settings hand their connections to Clash, but some games, command-line programs, store clients, and software with its own network stack may connect directly to the destination. In those cases, traffic from these programs may bypass the rule engine even when the system proxy is enabled.

TUN mode takes a different route. Clash Meta, whose core is now commonly known as mihomo, creates a virtual network interface and uses routing rules to send eligible IP traffic through it. The core reads each packet's destination information, then uses configured rules, proxy groups, and nodes to decide whether to connect directly, proxy the traffic, or reject it. To an application, this still looks like a regular network connection; no built-in HTTP proxy support is required.

“Full-traffic capture” describes how much traffic enters the core; it does not mean every connection must use the same proxy node. TUN sends traffic into Clash, while the operating mode and rules determine where it goes next. In rule mode, LAN addresses, mainland China websites, websites outside mainland China, and blocked domains can match different policies. In global mode, the core generally sends proxyable traffic to the global policy group. In direct mode, traffic entering the core may also be allowed through directly.

Version, Permission, and Configuration Checks Before Enabling TUN

First, confirm that the core used by the client supports TUN. Modern Clash Meta or mihomo cores generally offer more complete TUN, auto-routing, and DNS integration; older Clash cores, unmaintained GUI clients, or trimmed-down mobile builds may lack some fields. A configuration importing successfully does not mean the current core recognizes every TUN option it contains, so check the client’s core name, core version, and startup logs together.

System Permissions

Creating a virtual interface, changing the routing table, and setting DNS usually require elevated permissions. Windows clients may perform these operations through a service mode or administrator privileges; macOS may ask you to approve a network extension, VPN configuration, or helper service; Linux commonly involves root, CAP_NET_ADMIN, system services, and the required routing permissions. If a permission prompt is denied, the TUN switch may appear to turn on while the logs report that interface creation or route installation failed.

Grant permissions through the service installation, authorization, or network-extension entry provided by the client. Repeatedly restarting as an administrator can help determine whether permissions are the cause, but for long-term use, the client’s explicitly supported background-service setup is preferable.

Subscriptions and Local Overrides

A subscription mainly provides nodes, proxy groups, and rules; it may not include a TUN configuration suitable for the current device. Some GUI clients store TUN parameters in app settings and generate a runtime configuration, while others read the tun section directly from YAML. Manually editing a subscription-generated file may leave your changes overwritten at the next update. The reliable approach is to use the client’s override, merge, or configuration-patch feature and keep a copy of a configuration that starts successfully.

Network Environment

• Record the Wi-Fi, wired network, or mobile hotspot currently in use, and make sure no other VPN is enabled.
• Check whether the device is running a virtual machine, container network, game accelerator, or enterprise security application.
• Save the current DNS settings so you can restore them if domain resolution fails.
• Confirm that at least one node in the subscription connects successfully in standard system-proxy mode.
• Pause automatic configuration updates for a few minutes to prevent parameters from changing during troubleshooting.

Clash Meta and mihomo TUN Configuration Steps

With a GUI client, TUN can usually be enabled from the Network, Service Mode, or TUN settings page. Install any service component required by the client first, then enable TUN and check the logs for entries related to the virtual interface, routes, and DNS listeners. If the client lets you choose a network stack, begin with a broadly compatible option instead of changing several advanced parameters at once.

When maintaining a mihomo YAML configuration directly, start with the basic structure below. Supported fields and default values may vary by version, so follow configuration errors reported by the current core and the client’s documentation.

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

Basic Field Reference

system tends to use the system network stack, usually offering good performance and compatibility with system protocols; gvisor uses a user-space network stack, with different isolation and compatibility characteristics in some environments; mixed combines approaches by protocol. The best choice depends on the operating system, core version, UDP applications, and local security software. If web access works but game voice chat, UDP requests, or a particular program does not, switch only one stack option at a time and restart the core to compare the results.

Enable in This Order

1. Update to a stable core supported by the client, and confirm that the current configuration loads successfully.
2. Install or enable the system service, network extension, or virtual adapter component required by the client.
3. Enable TUN, starting with auto-routing and automatic outbound-interface detection.
4. Keep rule mode enabled and select a policy node that has already been confirmed to work.
5. Restart the core and check for configuration-field, permission, interface, or routing errors.
6. Test a browser, terminal commands, and an app that previously ignored the system proxy separately.
7. Once the basic connection is stable, enable strict routing or adjust the network stack.

After changing the configuration, fully reload the core. Saving YAML in a text editor while the client continues using an older runtime configuration is a common source of confusion. Use the configuration load time, core startup time, and current operating mode in the client logs to confirm that the new configuration is active.

How TUN Mode Works with DNS

TUN captures IP packets, while rule matching often depends on domain names. An app resolves a domain first and then connects to the returned IP; if the DNS query bypasses Clash, the core may see only the destination IP, limiting domain-based matching. A more complex case occurs when local DNS returns an unsuitable address while the network used by the proxy node resolves the domain to a different set of results. The result may be a working node but an inaccessible website.

mihomo’s DNS module can handle queries centrally and work with rule-based routing, Fake-IP, or Redir-Host modes. The structure below illustrates how the parts relate; choose resolver addresses according to the actual network and configuration source.

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-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

Fake-IP mode returns temporary addresses from a reserved range for domains and stores the domain mapping inside the core. When an app connects to the temporary address, the core can recover the original domain and apply domain rules. This preserves information for rule matching, but some apps that depend on real IPs, LAN discovery, device casting, or special authentication flows may need to be added to the filter list. Add filters one at a time based on a confirmed problem; broad wildcards can weaken domain mapping.

any:53 in dns-hijack mainly handles traditional DNS on port 53. App-level encrypted DNS, browser DoH, and fixed external resolvers may not follow the same path. During troubleshooting, temporarily disable the browser’s Secure DNS feature and let system queries enter Clash first to determine whether multiple DNS paths are running in parallel.

Avoid DNS Loops

When the core queries upstream DNS, that traffic must also use the correct outbound path. If the upstream DNS hostname depends on a resolution process that has not completed, or if routing rules repeatedly send queries back to the same listener, a resolution loop can occur during startup. With complex configurations, check the default resolvers, proxy-node hostname resolution, and reachability of direct upstream servers. Repeated DNS timeouts in the logs are often more informative than a browser error page.

How to Test Whether TUN Is Active

A switch changing to the On state is only the first step. Complete verification requires confirming that the virtual interface exists, routes have been installed, traffic can enter the core, rules match correctly, and DNS is not bypassing it. Use a progressive test sequence, with each step answering one question.

1. Check the startup logs: Confirm there are no configuration parsing errors, insufficient-permission errors, virtual-interface creation failures, or route-installation failures.
2. Check ordinary websites: Visit sites covered by direct and proxy rules, and watch which policies are matched in the connection list.
3. Test an app that ignores the system proxy: Disable the system proxy, leave only TUN enabled, and run a terminal download tool or the target app.
4. Watch the connection records: Check the domain, destination address, process information, and final policy to confirm that traffic actually passes through the core.
5. Test UDP: Run a short test with an app that genuinely relies on UDP to assess whether the current network stack is compatible.
6. Check the LAN: Open a router, NAS, or printer address and make sure private subnets are not being proxied by mistake.
7. Switch networks: Switch from Wi-Fi to a hotspot and check again whether the default interface and routes update automatically.

Connection records are the key to distinguishing “traffic was not captured” from “traffic was captured but matched the wrong rule.” If the target app produces no new connection at all, check the TUN interface, routes, app bypass settings, and permissions first. If a connection appears but uses the wrong policy, inspect rule order, domain detection, and proxy groups. If the policy is correct but the connection times out, continue with the node, DNS, MTU, firewall, and remote-service checks.

Assessing Rule Mode

Rules are matched from top to bottom and normally stop after the first match. TUN does not change this basic order. If a domain that should use a proxy matches a direct rule, check whether it entered the rule engine as a domain, destination IP, or process information. Broad IP-CIDR or GEOIP rules, as well as an earlier direct rule, can override later, more specific handling. A fallback rule usually belongs at the end of the rule list.

Common Conflicts and a Layered Troubleshooting Order

The Entire Network Goes Offline After Enabling TUN

Disable TUN first and confirm that basic network access returns immediately, then review the core logs. A complete outage is commonly caused by the core failing after interface creation, an incorrect default route, an unresponsive DNS service, or incomplete permissions. For recovery testing, disable strict-route, keep auto-route and auto-detect-interface enabled, and temporarily exit other VPNs. If the device is connected through both wired and wireless networks, confirm that the core identifies the interface that can actually reach the internet.

The Browser Works, but Games or Voice Chat Fail

Browsers mainly use TCP and HTTPS, while games, real-time voice chat, and some instant-messaging features use UDP. Check whether UDP connections enter the core, whether the node supports the required transport, and whether the current TUN network stack suits the app. Test system, gvisor, and mixed one at a time. Avoid changing DNS, nodes, and rules together, or you will not know which change helped.

The LAN Becomes Inaccessible After Enabling TUN

Confirm that private address ranges are still handled directly and check whether strict routing changed the outbound path for local subnets. Common private ranges include 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, but devices may also use link-local addresses, IPv6 LAN addresses, or specific multicast protocols. If the device IP opens directly but its hostname does not work, the issue is more likely local DNS, mDNS, or Fake-IP filtering.

Conflicts with Other VPNs, Virtual Machines, or Containers

Multiple networking tools may create virtual interfaces and modify the default route. Corporate VPNs, game accelerators, virtual-machine bridges, Docker, and container subnets can all overlap with TUN auto-routing. Exit other traffic-capture tools first and confirm that Clash TUN works alone, then restore them one by one. If two tools must coexist, define which interface handles each subnet and prevent both from treating the other’s virtual subnet as the default route.

TUN Stops Working After Sleep or a Network Change

After a laptop resumes from sleep, roams between Wi-Fi networks, or switches hotspots, the default interface and gateway may change. Although auto-detect-interface is intended to identify the outbound interface, the client may not rebuild routes immediately after every system event. Restart the core before reinstalling the client; if a core restart restores connectivity, inspect the client’s network-change listener, background permissions, and service status.

The TUN Configuration Disappears After a Subscription Update

This usually means the parameters were stored in the subscription-generated file, which the client downloaded and replaced during the update. Move TUN and DNS parameters to the client’s supported override layer, merge configuration, or separate global settings. Afterward, update the subscription manually once and restart the core. Confirm that the parameters remain present before considering the storage location correct.

Narrow the Problem by Layer

The point of layered troubleshooting is to preserve comparable results. Change only one variable at a time, restart the core afterward, and record the first clear error in the logs. Reinstalling the client immediately erases some evidence and cannot explain whether the issue came from permissions, routing, DNS, or the node.

Recommended TUN Settings for Daily Use

Once the basic setup works, there is no need to keep adding parameters. Auto-routing, a clear DNS plan, understandable rules, and stable nodes are generally easier to maintain than a large collection of experimental options. On devices used only for browsers and standard desktop software, the system proxy usually covers the main needs. Enable TUN when command-line programs, games, or specific apps cannot follow the system proxy.

For devices that use TUN long term, periodically review field changes after core upgrades and keep a working configuration before upgrading. When something breaks, first compare the core version, network stack, and DNS behavior before and after the upgrade. Client setting names may vary, but the underlying setup can still be understood through five areas: interface, routing, DNS, rules, and nodes.

The goal is not to force every connection through a proxy mechanically. It is to reliably send the connections that need to be captured into the rule engine, then choose direct access, proxying, or rejection according to their purpose. With this distinction clear, the differences between TUN, global mode, and rule mode become easier to understand, and node failures are less likely to be mistaken for virtual-adapter problems.