How to Enable TUN Mode in Clash: Virtual Network Adapters, Routing, and Setup

Check Whether You Need TUN Mode

Test your node and configuration with the system proxy first, then enable TUN. Consider routing traffic through a virtual network adapter only if your browser works but command-line tools, games, or apps that ignore system proxy settings still connect directly. TUN won't fix a broken node or make a node without UDP forwarding support handle UDP traffic.

TUN is a Layer 3 virtual network interface provided by the operating system. When an app's IP packets are routed to this interface, the kernel reads them, identifies the connection, and applies rules to choose between a direct connection and a proxy. This works at a different layer from a system proxy, which handles proxy requests from supported apps.

Check the Kernel, Configuration, and Permissions First

Use a maintained client with explicit TUN settings whenever possible. The YAML fields below use mihomo as an example; support varies across older Clash versions, kernel forks, and mobile clients. Check the client’s About page or kernel information to confirm which kernel is actually running. Don’t assume compatibility based on the app’s name alone.

1. Keep a working configuration. Export your current configuration and note the system proxy port, current mode, and selected policy. Subscription updates may overwrite edits made directly to a subscription file, so use the client’s override or configuration-merge feature when available.
2. Test your node. Enable the system proxy and open a website that you actually need to access through a proxy. A latency test returning a value in milliseconds does not prove that the target website or UDP traffic will work.
3. Pause other traffic-capture tools. Temporarily disconnect other VPNs, game boosters, and TUN clients. Follow your organization’s policies for security software and VPNs on managed devices; don’t remove them without authorization.
4. Check local access. Note the addresses of your router, NAS, and printer, such as 192.168.1.1. Test them again after enabling TUN so you don’t check only external connectivity.

The system proxy port and DNS listening port serve different purposes. For example, you might set the mixed proxy port to 7890 and have DNS listen on 127.0.0.1:1053. Use the values in your active configuration; don’t enter the proxy port as the system DNS address.

Enable the Virtual Network Adapter by Platform

Windows: Install the Service, Then Enable TUN

In a desktop client that uses mihomo, open Settings and look for Service Mode or Service Management. Install the service and confirm that it’s running. Windows User Account Control will usually prompt you during installation. Then return to the home screen or proxy settings and enable TUN Mode or Virtual Adapter Mode. Menu names vary by client and version.

1. Keep Rule Mode enabled and select a policy you’ve already tested.
2. Enable Service Mode, then enable TUN. If the client offers Auto Route and Auto Detect Interface, leave both enabled initially.
3. Check the logs for permission errors, virtual adapter creation failures, or route-add failures. If the toggle is on but the logs show errors, traffic capture has not succeeded.
4. Turn off the system proxy, reconnect your apps, and test your browser, terminal, and local network access.

If the client has no service mode, it may need to run as administrator; read its permission guidance first. Don’t run two instances of the client at once—one with standard permissions and one as administrator—as they can compete for ports and routes.

macOS: Approve the Helper or Network Permissions

Open the client’s TUN or network settings and follow the prompts to install a privileged helper, enter your administrator password, or approve the requested network permission. Clients may use different implementations. Approve a permission only when macOS actually prompts for it; don’t manually install extensions from unknown sources.

After enabling TUN, use ifconfig to check network interfaces and review the client logs to confirm creation. On macOS, utun interfaces may also be created by system services or other VPNs. Seeing utun0 or utun1 alone doesn’t prove that Clash TUN is working.

Linux: Check the TUN Device and Network Permissions

First, check whether /dev/net/tun is available. The kernel needs permission to create virtual network adapters and modify routes. Desktop clients typically get these permissions through a helper service; command-line setups need the service to be configured with the right permissions. Giving a regular user read/write access to a configuration file won’t resolve denied route operations.

test -c /dev/net/tun && echo "TUN device exists"
ip link show
ip rule show
ip route show table all
ip route get 1.1.1.1

These commands read system status and don’t change network settings. In Docker, LXC, or a restricted VPS, the host must also allow access to the TUN device and grant the required network capabilities. Being root inside a container does not automatically grant network-management permissions on the host. Before changing the default route on a remote server, make sure you have an out-of-band recovery method, such as console access.

Android and iOS: Use the System VPN Permission Prompt

On Android, compatible clients usually capture traffic through the system VPN service. The first time you connect, Android displays a VPN connection request; root is generally not required. With per-app proxying enabled, only selected apps are covered. Android typically allows only one standard VPN service to be active at a time, so connecting to another VPN may disconnect the current client.

On iOS, use the VPN configuration and connection options provided by the client, and add the configuration when prompted by the system. Desktop service installation steps don’t apply to iOS, and desktop TUN YAML should not be copied over as-is. Also check per-app exclusions, local network access, and background activity settings.

Configure mihomo TUN and DNS Hijacking

Merge the fields into your configuration, then reload it. The snippet below assumes you already have working nodes, policy groups, and rules; it is not a complete, standalone subscription. Keep only one copy of each top-level field, especially dns: and tun:.

mixed-port: 7890
mode: rule

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

Three Key Settings to Understand

• auto-route: Lets the kernel set up the routes needed to capture traffic. When disabled, you usually need to maintain routes yourself, so don’t toggle it casually while troubleshooting for the first time.
• auto-detect-interface: Automatically identifies the network interface used for external connections, helping proxy traffic avoid routing back into TUN. Check the actual outbound interface in multi-adapter setups, with other VPNs, or in networks with custom routes.
• dns-hijack: Sends specified DNS traffic entering TUN to the built-in DNS handler. The example covers standard UDP 53 and TCP 53; it does not automatically decrypt or capture every app’s built-in DoH or DoT traffic.

stack: system selects the system network stack. mihomo offers other stack options, but support and behavior depend on the kernel version and platform. Start with the client’s recommended default. If you hit a compatibility issue, change the stack on its own and test again; don’t change routing, DNS, and MTU at the same time.

Fake-IP Addresses vs. Real Destination Addresses

Fake-IP mode assigns domains addresses for internal mapping, such as addresses in the 198.18.0.1/16 range. The kernel uses this mapping to recover domain information and apply rules. A result in this range doesn’t mean the website’s server is actually there or that DNS resolution failed.

The example uses two IPv4 DNS upstreams to illustrate the configuration structure. Choose reachable resolvers that fit your routing needs. dns.ipv6: false tells this DNS module not to return AAAA records; it does not disable IPv6 in the operating system or guarantee that all IPv6 traffic is captured. Apps may use their own encrypted DNS, cache results, or connect to hard-coded IP addresses through a different path.

Confirm That Traffic Is Actually Going Through TUN

Turn off the system proxy before testing so you can tell the two traffic-capture paths apart. If your terminal has HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY set, avoid those variables during the test too; otherwise, a successful request proves only that the explicit proxy works.

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

In Windows PowerShell, use curl.exe to run the actual curl program. Here, --noproxy "*" bypasses curl’s explicit proxy settings, but not the operating system’s TUN routing. This makes it useful alongside the client’s connection panel when checking traffic capture. The example site is for a basic HTTPS check; test again with a destination you actually use.

1. Check the connection panel. Find the connection you just made and verify the destination domain or IP, the matched rule, and the final policy.
2. Test direct connections. Access your router or NAS to confirm local network connectivity and make sure the traffic isn’t mistakenly routed through a remote node.
3. Test proxied destinations. Check an app that needs a proxy and confirm that it matches the expected policy.
4. Test UDP separately. Verify with an actual voice call, game, or other UDP-based app. A successful HTTP request or normal node latency does not prove that UDP works.

Reconnect after changing modes. Browsers with persistent connections, game sessions, and downloads may keep using an existing connection. If you only toggle a setting without starting a new connection, cached results can give you the wrong impression.

Troubleshoot No Internet After Enabling TUN

Start by Identifying the Failing Layer

Check permissions, routes, DNS, and policies—in that order

Start with the logs. If you see permission denied or a similar operation-denied message, fix the service permissions first. If a port is already in use, check whether the kernel is running more than once. Switching nodes repeatedly is unlikely to help at this stage.

Next, check the outbound interface and routes. TUN sends app traffic to the kernel, but the kernel must still be able to reach the physical network when connecting to a proxy server. If proxy traffic is routed back into TUN, it can create a loop. On devices with multiple network adapters, check the actual default outbound interface. If needed, specify an outbound interface as described in the documentation for your kernel version. Don’t delete all system routes.

Then check DNS. Use nslookup example.com to view the result, and interpret it alongside the DNS server shown by the command and the kernel logs. A Fake-IP address is an expected internal mapping; timeouts, connection refusals, and unreachable upstreams are signs to investigate. If your browser uses Secure DNS, compare browser and system resolution separately.

Finally, check the matched rule and policy. In Rule Mode, an overly broad direct-connection rule may bypass the proxy. The selected policy group may also still point to DIRECT. Temporarily switching to a known-working policy can help isolate the issue, but restore your original routing afterward and check which rule the new connection actually matches.

Change MTU Only When the Symptoms Point to It

Consider changing the MTU only if connections are established but larger transfers stall, or the problem reliably occurs on certain networks. Note the current value, then temporarily test mtu: 1400 and, if needed, 1280. Change only one setting at a time. These are troubleshooting values, not universally optimal settings for every broadband, mobile, or tunnel connection.

Disable TUN and Restore Network Access

Turn off TUN in the client, then exit the client normally so the kernel can remove its automatic routes. If the system proxy was also enabled, turn it off separately; disabling TUN does not restore system proxy settings.

• Check whether another proxy client or VPN is still running.
• Restore any manually entered system DNS addresses to their previous settings. If DNS was set to automatic before, switch it back to automatic.
• If the network is still unstable, reconnect to Wi-Fi or Ethernet, then check the default route. Restart the system if needed.
• For remote devices, use a recovery console you prepared in advance. Don’t blindly run commands that flush routes or reset the firewall.

When enabling TUN again, start with the simplest setup: a working node, Rule Mode, and one TUN client. Restore custom DNS, per-app exclusions, and other network tools one at a time, testing after each change. This helps identify which setting affects the result instead of repeatedly reinstalling the client.