How to Enable TUN Mode in Clash: Virtual Adapters and Full-Traffic Routing

System Proxy vs. TUN: Different Traffic Entry Points

If your browser connects but command-line tools, games, or other apps don't appear in Clash's connection list, start by checking how their traffic enters the network. A system proxy simply provides apps with a proxy address, such as 127.0.0.1:7890. Apps must adopt that setting to send requests through the local proxy. Programs that connect directly, read only environment variables, or use their own network settings may bypass the system proxy.

TUN is a Layer 3 virtual network device. The operating system uses its routing table to send IP packets to the virtual adapter, where mihomo reads them, identifies connections, and applies routing rules. Since apps don't need to support HTTP or SOCKS proxies, TUN is better suited to capturing TCP and UDP traffic from apps that would otherwise connect directly.

Before You Start: Check the Kernel, Subscription, and Permissions

Clash is often used as an umbrella term for a family of clients and kernels, but not every build supports the same TUN options. The YAML examples in this guide are for mihomo, commonly known as the Clash Meta kernel. Older Clash versions, other forks, and mobile clients may use different fields or configuration screens, so don't assume compatibility based on the product name alone.

1. Check the kernel. Look for mihomo in the client's About screen, kernel information, or runtime logs. If there's no TUN option in the UI, first confirm that the client supports it instead of adding a large set of unknown settings.
2. Test your subscription first. Confirm that at least one node works with the system proxy enabled and that your policy group has a valid node selected. TUN addresses how traffic enters the client; it won't fix an invalid subscription or node authentication errors.
3. Note your current settings. Record the system proxy port, current DNS settings, active VPN, and LAN subnets. Keep a way to access the machine locally during initial setup, and don't change the default route in a remote SSH session.
4. Prepare system permissions. Windows usually needs service mode or administrator privileges. On macOS, install the privileged helper when prompted by the client. On Linux, the process needs access to /dev/net/tun and permission to manage network settings.

Quit other VPNs that use virtual adapters before testing Clash TUN. Multiple clients adding default routes or changing DNS can cause traffic to switch paths repeatedly. If you need to run them together, first verify each one separately, then configure excluded routes and egress interfaces one at a time.

gvisor, system, and mixed Network Stacks

tun.stack selects the network stack used to process virtual adapter traffic. It's not a node protocol setting and won't turn a Trojan node into a VLESS node. Common mihomo values are gvisor, system, and mixed; support depends on the kernel build you're using.

• gvisor: Processes connections with a user-space network stack. It can be useful as a comparison when troubleshooting compatibility, but that doesn't guarantee greater stability on every system.
• system: Uses the operating system's network stack to process connections. Performance and compatibility depend on the OS, drivers, and network environment, so don't assume it's faster on every device.
• mixed: Combines both approaches in mihomo: TCP uses system, while UDP uses gvisor. This stack combination is unrelated to mixed-port, which accepts both HTTP and SOCKS requests.

When to Switch Network Stacks

Change one setting at a time, then restart the kernel and create a fresh test connection. If websites work but voice chat or games don't, first check whether the node supports UDP and whether the rules match, then compare network stacks. If no connections appear in the panel, check permissions and routes first; switching between gvisor and system repeatedly is unlikely to reveal the cause.

mihomo TUN Configuration: Set Up Routing and DNS Together

The snippet below must be merged into an existing configuration; it is not a complete subscription. It doesn't define nodes, policy groups, or routing rules, so it can't replace a working full configuration. If the file already has top-level tun or dns sections, merge the fields instead of adding duplicate keys that may be overwritten by the parser.

mixed-port: 7890
allow-lan: false
mode: rule

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

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

The two upstream DNS addresses in this example are specific configuration examples, not recommendations for every network. Choose resolvers that are reachable from your network and meet your requirements. If your subscription already includes a complete DNS policy, keep its upstream resolvers and domain-routing design, and add only the TUN fields you need.

auto-route and auto-detect-interface

auto-route: true lets the kernel add routes that direct traffic into TUN. auto-detect-interface: true detects the active egress interface so proxy connections can leave through the physical network instead of looping back into TUN. With multiple adapters, VM bridges, corporate VPNs, or simultaneous Wi-Fi and Ethernet, auto-detection can still pick the wrong interface; check the logs to confirm.

Don't just look for 0.0.0.0/0 in the routing table. Different platforms may capture traffic with more specific routes, separate tables, or policy-based routing. Check both route lookup results and the client's connection logs to confirm that TUN is working.

dns-hijack, port 1053, and fake-ip

dns-hijack sends matching DNS traffic to mihomo's built-in DNS resolver. The example any:53 handles common UDP queries on port 53. If you also need to handle TCP port 53, add tcp://any:53 if your kernel supports it. This isn't a catch-all for every DNS protocol and won't automatically detect or hijack DoH requests sent by browsers over HTTPS.

127.0.0.1:1053 is an example DNS listening address; it doesn't mean you should enter an address with a port in your system DNS settings. Most operating systems accept only an IP address for DNS. TUN traffic capture, the DNS listening port, and system DNS settings are separate things.

fake-ip assigns virtual addresses to domains, while the kernel keeps track of which domain belongs to each connection. The example address pool, 198.18.0.1/16, is in a reserved range for testing; getting an address from this range doesn't mean DNS is broken. For LAN services that need real DNS answers, configure an appropriate fake-ip-filter and DNS routing instead of excluding every domain.

How to Enable TUN on Windows, macOS, and Linux

Client menus use different names, so the steps below describe the relevant features. If the UI offers TUN, network stack, and DNS capture settings, use those controls first. Many clients regenerate their configuration at runtime, so edits to generated files may be lost on the next launch. Subscription updates can also overwrite manual changes; use the client's persistent overrides or merge feature.

Windows: Service Permissions and Virtual Adapters

1. Import your subscription and confirm that the system proxy can reach the services you need. Then temporarily turn off other VPNs.
2. Open the service mode setting in the client and install and start the service as prompted. If the client uses another privilege mechanism, follow its instructions to grant administrator access.
3. Enable TUN, choose a network stack supported by your kernel, and apply the settings. If you're prompted to install a driver or authorize a network device, make sure the prompt is from the client you're using.
4. Open PowerShell and check for a new virtual adapter and IPv4 routes. Also check the client logs for permission errors, device creation failures, or failed route additions.

Get-NetAdapter
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Format-Table DestinationPrefix,InterfaceAlias,NextHop,RouteMetric

The adapter name depends on the client and configuration; it doesn't have to be Clash. Seeing the adapter confirms that the device was created, but doesn't prove that app traffic is matching a proxy policy.

macOS: Helper Tools and utun Interfaces

1. Confirm that your client and kernel support TUN, then install the privileged helper required by the client.
2. Enable TUN or the equivalent virtual adapter feature in the client, and approve any system authorization prompts.
3. Use the commands below to inspect interfaces, routes, and system DNS, then compare the results with those from before enabling TUN.

ifconfig
netstat -rn -f inet
scutil --dns

macOS may have several utun interfaces, created by other VPNs and system features too. Don't assume an utun interface belongs to Clash, and don't manually remove every interface of this type. Compare before-and-after results and check routes and logs to identify which component owns it.

Linux: TUN Devices and Network Permissions

Desktop clients usually use a service process to obtain elevated privileges. For command-line setups, the process needs at least the permissions required to create a TUN device and manage routes, which often involves CAP_NET_ADMIN. Check other permissions against your kernel features, service restrictions, and runtime environment. Don't blindly apply a generic capabilities list.

test -c /dev/net/tun && echo "TUN device available"
ip link show
ip rule show
ip route show table all
resolvectl status

resolvectl is for systems using systemd-resolved; its absence doesn't indicate a TUN problem. Running inside a container also requires the host to provide a TUN device and suitable network permissions. Simply switching to root inside the container may not be enough. Run the first test locally to avoid interrupting a remote connection with route changes.

Android and iOS: System VPN Permissions

Android clients usually capture traffic through the system VPN API, so you don't need to follow desktop steps for installing a network adapter driver. Import a compatible configuration, select VPN or virtual adapter mode, and allow the system VPN prompt the first time you connect. If per-app proxying is enabled, make sure the target app is included; excluded apps won't be captured just because the desktop example sets auto-route.

iOS clients usually use the system's Network Extension capabilities. First confirm that the app supports the configuration format, then add a system VPN configuration and authorize the connection. Don't assume every desktop mihomo TUN field applies to iOS, or that every app accepting Clash subscriptions runs the mihomo kernel.

Mobile devices generally can't run two ordinary VPN tunnels of the same type at once. If the connection drops immediately, check for another VPN, on-demand connection rules, and system background restrictions before repeatedly changing node protocols.

Verify Traffic Capture: Connections, DNS, and UDP

Rule Out the System Proxy First

Temporarily turn off the client's system proxy while leaving TUN enabled. Send a new request from an app that doesn't normally use a proxy, then check its process, destination, matched rule, and outbound policy in the connection panel. You can also run the command below to make curl bypass explicit proxies. This rules out explicit proxy use for that request, but doesn't prove by itself that TUN captured it.

curl --noproxy '*' -I https://example.com

If the page loads and you can find the request in the connection log, check which policy matched. A DIRECT match is a valid rule outcome, not evidence that TUN failed. Existing long-lived connections may keep using their original route after you switch nodes, so establish a new connection when testing.

Test DNS and UDP Separately

• DNS: Use a system lookup tool to query a domain that isn't cached, then check the kernel logs. If the browser uses Secure DNS, its queries may not use the system's UDP port 53 path.
• UDP: Check the connection list while using an actual voice, gaming, or QUIC app. A website loading over TCP 443 doesn't prove that UDP 443 works.
• IPv6: On dual-stack networks, test IPv4 and IPv6 separately. If only IPv4 is captured, some apps may prefer an IPv6 route that bypasses TUN.
• LAN: Test your router's admin page, printers, and internal domain names. Add explicit rules for destinations that need a direct connection; some networks may also require route exclusions.

No Internet After Enabling TUN? Troubleshoot by Layer and Restore Access

To restore access, first turn off TUN in the client, then quit the client normally. Check whether the system proxy still points to 127.0.0.1:7890. If the proxy process has stopped but the system proxy is still enabled, your browser may report connection errors. That's a separate issue from stale TUN routes.

Next, restore the DNS settings you recorded and disconnect and reconnect to your current network. If routes are still incorrect, check whether the background service is still running; restart the system if needed to restore network connectivity. Don't bulk-delete unfamiliar routes or adapters: they may be in use by a corporate network, VM, or another VPN.

For help organizing your configuration, see the Clash configuration guide. Still choosing a client? Read the Clash client selection guide and compare platform and kernel support.