Clash TUN Mode Guide: Setup, Permissions, and DNS Hijacking

1. TUN mode captures traffic, but that doesn’t mean every connection uses a proxy

If your browser can connect but games and command-line tools don’t appear in Clash’s connection list, they may not be using the system proxy. A system proxy tells apps where to find an HTTP or SOCKS proxy. TUN mode creates a virtual network interface and uses routing to send IP packets to the core, so apps don’t need built-in proxy support.

The configuration fields in this guide are primarily for clients using the mihomo core. Clash is a common name in the client ecosystem, but not every product or legacy version with that name supports the same TUN features. Before making changes, note the client version, core name, and core version on the About or Core page. If you’re using an older Clash core, don’t assume mihomo options will work.

“All traffic” has limits. Excluded apps or subnets, IPv6 traffic that isn’t configured for capture, and routes reserved by another VPN can all bypass TUN. LAN access, multicast discovery, and system-reserved traffic shouldn’t automatically be treated as traffic that must go through a remote proxy. Check connection logs and actual routes to verify TUN; don’t rely on the toggle alone.

2. Before you start: check your proxy, permissions, and other VPNs

1. Make sure your existing configuration works. Import a subscription, select a configuration and working node, then use the system proxy to open a known-reachable HTTPS page. TUN won’t fix a node that can’t connect.
2. Save your current settings. Back up your configuration and note the original system proxy, DNS, TUN, and service mode settings. Don’t post subscription URLs, access tokens, or node passwords in public logs.
3. Temporarily disconnect other VPNs. This includes game boosters, corporate tunnels, and other proxy clients. They may also change the default route or DNS. On a managed device, check your organization’s policies first.
4. Check proxy protocol support. TUN can capture UDP traffic, but that doesn’t mean your selected node or server can forward it. Test games, voice calls, and QUIC separately.

On desktop, creating a network interface or adding routes usually requires administrator or root privileges, or a privileged helper process. Android uses system VPN authorization instead of desktop service mode and generally doesn’t require root access.

3. How to enable TUN and grant permissions on each platform

The desktop steps below follow the common layout of mihomo GUI clients such as Clash Verge Rev. Depending on the release, TUN mode may be called Virtual Network Adapter mode. If you can’t find the same setting, check the documentation for your version. Don’t download unofficial “universal driver” patches.

Windows: install the service, then enable the virtual adapter

1. Go to Settings → Service Mode and install or enable the service. Approve the request in the Windows User Account Control prompt. Some versions place the service setting under Settings → System Settings; follow the labels in your client.
2. Make sure the service status shows Running, then go to Settings → TUN Mode or Virtual Network Adapter Mode and turn it on. After the first start, wait for the adapter to initialize instead of repeatedly toggling the setting.
3. Check the logs for permission errors, interface creation failures, or route addition failures. Windows clients may use components such as Wintun; how driver files are supplied depends on the client.
4. Open the Connections page and run an app that doesn’t use the system proxy. Check whether it appears in the list, then verify its matched rule and policy group.

Service mode lets a managed background service perform privileged operations; it doesn’t guarantee that the proxy will start successfully. If the client says the service is installed but TUN still fails, check that the service is running, the core process has started, and security software isn’t blocking the network adapter component. Don’t treat permanently disabling the firewall as a fix.

macOS: authorize the helper service and check for a utun interface

1. In the client, go to Settings → Service Mode and install or repair the helper service. Enter your administrator credentials when prompted by macOS. Never enter your administrator password in a subscription import field or node settings.
2. Enable TUN mode and approve any required system permissions. The authorization prompt varies by client and macOS version.
3. In Terminal, run ifconfig to list interfaces and netstat -rn to view routes. macOS commonly uses utun interfaces for TUN connections.

macOS may already have several utun interfaces, so seeing one doesn’t prove that Clash is capturing traffic. Compare routes before and after enabling TUN, and check the client logs. Common macOS TUN implementations use system interfaces; don’t follow Windows Wintun installation instructions.

Linux: check the TUN device and network permissions

For a GUI client, use its built-in service mode where possible. If running mihomo directly, configure a systemd service and permissions according to your distribution’s documentation. To check whether the device exists, run:

ls -l /dev/net/tun
ip link show
ip route show
ip -6 route show

If /dev/net/tun is missing, check kernel TUN support, whether the module is loaded, and whether the device is mapped into your container. Creating interfaces and changing routes usually requires CAP_NET_ADMIN. A process running as root inside a container may still lack this capability. Don’t grant broad, permanent elevated permissions to the entire GUI client.

After enabling TUN, check ip rule show and the routing tables for conflicts with NetworkManager, container networking, or other VPNs. Some mihomo versions offer Linux-specific auto-redirect, but it isn’t required across platforms. Don’t add it indiscriminately on every device.

Android: allow the VPN connection, then check per-app settings

1. In an Android client that uses mihomo, import your configuration and tap Start or Connect on the home screen.
2. The first time you connect, allow the VPN in Android’s Connection request dialog. Android clients usually create a virtual interface through VpnService, so there’s no need to install a desktop driver.
3. Check Access Control or Per-App Proxy under the client’s Settings. If Only proxy selected apps is enabled, apps that aren’t selected won’t be captured.
4. If the connection drops when the app goes into the background, check background restrictions under Settings → Apps → [client] → Battery. Menu names vary by Android version and device.

Android typically allows only one active VPN based on VpnService per user profile. Starting another VPN, ad blocker, or game booster may replace the current connection. Always-on VPN and Block connections without VPN are system-wide settings; if misconfigured, they can cut off network access. Consider enabling them only after basic testing is complete.

4. Choosing a stack: system, gvisor, or mixed

stack is an option for the network stack that handles traffic inside TUN. It isn’t a proxy protocol or a node type. Common mihomo values include system, gvisor, and mixed; availability depends on the core build and platform.

Don’t assume any stack is the one-size-fits-all “best setting for gaming.” Keep the client default to start. If a specific app has connection issues, change one option at a time, restart TUN, and test again. Use the same approach with MTU: start with the default and adjust only when there’s a clear sign, such as large transfers stalling or tunnel encapsulation issues. Don’t set it to 9000 just because latency was high once.

5. DNS hijacking: capture queries on port 53

Apps resolve domain names to IP addresses before connecting. If DNS queries don’t follow the expected resolution path, domain-based rules may not work as intended, results may be unexpected, or connections may time out. TUN’s dns-hijack option forwards matching traditional DNS requests to the core’s DNS module. Here, “hijacking” means redirecting traffic locally—not altering a remote website.

mihomo configuration snippet

This example enables IPv4 TUN, automatic routing, and capture of UDP and TCP traffic on port 53. It isn’t a complete subscription and can’t replace your entire configuration. Back up your settings first, then apply the example using your client’s override or merge feature. If your configuration already has tun or dns fields, merge the contents instead of adding duplicate top-level YAML keys.

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

• auto-route: lets the core configure the routes needed for traffic capture. It doesn’t guarantee coverage of excluded routes or routes taken over by other software.
• auto-detect-interface: automatically selects an outbound interface. Check the result when using multiple network adapters, a hotspot, or a corporate VPN.
• any:53 and tcp://any:53: match traditional UDP and TCP DNS queries, respectively. Matching still depends on whether the traffic enters TUN.
• 127.0.0.1:1053: the local DNS listening address. System DNS settings usually can’t accept an address with port 1053; this example relies on TUN to forward queries.
• nameserver: the example specifies two traditional DNS upstream servers. Choose servers based on network reachability, privacy requirements, and your routing design; these servers won’t suit every network.

Fake-IP returns reserved addresses as part of its mapping mechanism

With this configuration, DNS may return a mapped address in the 198.18.0.0/16 range, which the core then associates with the domain name. This isn’t the destination website’s real public IP address. If LAN device discovery, a particular game, or an internal domain doesn’t work, add the specific domain to fake-ip-filter or use another DNS mode supported by your client instead of removing the entire DNS configuration.

Android Private DNS also needs to be considered separately. If an app bypasses the core’s DNS and uses a different resolution path, check its connections and routing results. IPv6 also needs end-to-end configuration: this example doesn’t configure IPv6 capture, so it can’t be taken as proof that IPv6 is covered. Before enabling dual-stack, check the core, routes, DNS responses, and node capabilities.

6. Verify in three steps: interface, connections, and DNS

1. Check the interface and routes. The logs should show TUN starting successfully, not retrying repeatedly. On Windows, check changes with route print; on macOS, use netstat -rn; on Linux, use ip route show. Different implementations may create split or policy-based routes instead of replacing the default route.
2. Confirm that apps outside the system proxy reach the core. Turn off the app’s own proxy settings, start a new connection, and check Clash’s Connections page. On desktop, you can temporarily disable the system proxy and test with TUN alone. Don’t change managed settings on a corporate device without authorization.
3. Check DNS resolution and rule matches. Look up a domain that isn’t cached and compare the logs, DNS response, and resulting connection. In Fake-IP mode, a mapped address is expected. Focus on whether the connection succeeds and matches the intended policy.

For example, run the following command to test an HTTPS request. This checks the connection path; it isn’t a speed test or a claim about measured performance:

curl --noproxy "*" -I --connect-timeout 10 https://example.com

--noproxy "*" bypasses curl’s usual proxy settings so you can observe the TUN path. In Windows PowerShell, use curl.exe explicitly to avoid differences with command aliases. After testing, check the connection list for the destination domain, matched rule, and outbound policy. A successful command alone doesn’t prove that traffic went through a remote proxy.

7. Common problems and safe recovery

No websites load after enabling TUN

Turn off TUN first and check that your regular network access returns. Then check service permissions, the active configuration, DNS upstream reachability, and other VPNs. If DNS still fails with TUN off, look for leftover manual DNS or system proxy settings and restore the state you recorded before making changes. Avoid reinstalling the client while also changing nodes, stack, and DNS—you’ll make it harder to identify the cause.

Websites work, but games or voice calls still fail

First check whether the relevant process appears in the connection list, then confirm that the node supports UDP. A browser loading a page usually proves only that some TCP or HTTPS traffic works. On Android, check whether per-app rules exclude the game. On desktop, check whether the game is bound to a specific network adapter or whether another game booster has added routes.

A LAN printer, NAS, or corporate domain stops working

First determine whether the destination should connect directly or use a corporate VPN route. Then adjust the relevant rules, DNS resolution policy, or TUN route exclusions. DIRECT in a rule is different from a route exclusion: the core still processes DIRECT traffic before sending it directly, while an exclusion keeps specified traffic out of TUN. Public DNS usually can’t replace corporate DNS required for internal domains.

Network access doesn’t return after quitting the client

Reopen the client, turn off TUN normally, and exit so it can clean up. Then check the system proxy, DNS, and any remaining service processes. Take extra care when managing a remote server: changing the default route can disconnect SSH. Arrange console or out-of-band access beforehand, and don’t experiment over your only management connection.