Clash TUN Mode Setup Guide: Virtual Adapter Basics and Taking Over Global Traffic Correctly

What a System Proxy Can't Catch, TUN Can

First, let's clarify a distinction that often gets blurred: system proxy and TUN mode solve the same problem at two different layers. A system proxy works by modifying the proxy configuration that the operating system or browser reads — the HTTP/HTTPS proxy address field under Windows' "Network & Internet" settings, for example, or environment variables like HTTP_PROXY/HTTPS_PROXY. If a program follows this convention and actively reads the proxy setting, its traffic gets forwarded to the port Clash is listening on. But if a program doesn't read it — or uses a hardcoded connection method, common in some game clients, command-line tools, certain UWP apps, and system update services — the system proxy simply has no effect on it.

TUN mode takes a different approach: instead of "persuading" programs to use a proxy, it creates a virtual network adapter inside the operating system's network stack, then points the system's default route at that virtual adapter. This means all outbound traffic — whether from a browser, a background service, or a program that has no concept of proxy settings — first passes through this virtual adapter, where Clash (or the Clash Meta / mihomo core) reads, parses, and routes it in user space according to your rules. This is what's meant by "global traffic takeover": the target here is the network layer of the entire device, not the application-layer settings of any single app.

One common misunderstanding worth clearing up: TUN mode isn't "a more powerful system proxy" — it's an entirely different implementation. A system proxy operates at the application-layer protocol level (HTTP/HTTPS CONNECT), while TUN operates at the network layer (IP packets), so it can handle any TCP/UDP-based traffic, including games, VoIP, and DNS queries themselves. That's why certain scenarios — proxying UDP traffic, or uniformly handling every program on a device — are only achievable with TUN mode.

How the Virtual Adapter "Intercepts" Traffic: Three Key Steps

Understanding how TUN mode works makes it much easier to troubleshoot issues down the line. The whole process breaks down into three steps:

1. Creating the virtual adapter: the client calls low-level system interfaces (the Wintun driver on Windows, the utun interface on macOS) to create a virtual network adapter named something like Clash or utun, and assigns it a private IP range.
2. Adjusting the routing table: the client redirects the system's default route, or a subset of routing rules, to point at this virtual adapter — while keeping direct routes to Clash's own process and the local gateway intact, to avoid traffic looping back on itself.
3. User-space forwarding and routing: once the operating system feeds packets into the virtual adapter, the Clash core reads these IP packets in user space, reassembles them into actual TCP/UDP sessions, and then decides — based on rules in the config file (domain matching, IP range matching, GeoIP, etc.) — whether to send them direct, through a specific proxy node, or block them outright.

This also explains why TUN mode requires elevated system privileges — modifying the routing table and creating a virtual adapter needs administrator rights on Windows, and sudo or system extension approval on macOS. This isn't the software "overreaching"; it's simply what the virtual adapter technology itself requires access to at the OS level.

Complete Steps for Enabling TUN Mode on Windows

The interface layout varies slightly between Windows clients, but the core toggle and sequence of steps are consistent. Here's the general workflow:

1. Confirm the client's core is Clash Meta or mihomo (some older Clash Premium cores don't support TUN — update the client or switch cores if needed).
2. Open the client's main interface, find the "Proxy Settings" or "Network" panel, and locate the TUN Mode toggle. The first time you enable it, the system will usually prompt you to install the Wintun driver — click to allow it.
3. If the client offers a "Service Mode" option, it's worth installing alongside TUN. Service mode keeps TUN-related operations running persistently in the background as a Windows service, so you don't need to relaunch the client with admin rights every single time to enable TUN, and it also prevents the TUN adapter from misbehaving after a user logs out.
4. Once you flip the TUN toggle, the client will prompt to restart with administrator privileges — confirm, and expect a brief 1–2 second route-switch delay on first launch.
5. Switch to the "Proxy Mode" panel and confirm you're in Rule mode rather than global direct — that way, traffic taken over by TUN gets processed according to your subscription's routing rules, instead of going entirely through the proxy or entirely direct.

Control Panel → Network and Sharing Center → Change adapter settings
You should see a virtual adapter named Clash / Mihomo, status "Connected"

If no matching virtual adapter shows up in the network adapter list after enabling TUN, it's most likely that the Wintun driver failed to install or was blocked by security software. Try manually restarting the client once with admin rights, or temporarily disable your third-party security software's driver-blocking feature and try again.

Enabling TUN Mode on macOS: System Extension Approval Is the Key Step

macOS enforces a much stricter review process for creating network extensions at the system level, so enabling TUN mode on macOS typically involves an extra "system extension approval" step:

1. Toggle on TUN mode in the client's settings. The first time you do this, the system will show a "System extension blocked" prompt.
2. Go to "System Settings → Privacy & Security," find the notice at the bottom allowing the corresponding system extension for the client, and click to allow it.
3. Some macOS versions require a restart before the system extension takes effect — restart, then reopen the client.
4. Toggle TUN on again; the client will request an administrator password to create the utun virtual interface and modify the routing table. Enter the password to confirm.
5. Once it's enabled, you can run ifconfig or networksetup -listallnetworkservices in Terminal to check for a utun-series interface.

ifconfig | grep utun
# You should see output similar to
utun5: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500

Verifying TUN Is Actually Working: Don't Just Trust the Toggle

The toggle switching to "on" doesn't necessarily mean traffic is actually being taken over as expected. Here are two reliable ways to verify it. The first is checking whether DNS resolution is being hijacked — under TUN mode, DNS queries themselves should also be processed by the Clash core, which is what makes domain-based rules match correctly:

nslookup example.com
# Check the responding server address in the output
# If it shows the DNS listening address configured in the Clash core
# (such as a fake-ip range like 198.18.0.2)
# it means DNS queries are being intercepted by TUN, rather than hitting the system's native DNS directly

The second method is to watch the connections panel or traffic panel directly in the client. With TUN enabled, you should see connection records show up in that list even from software that doesn't read browser proxy settings — the built-in Weather app, certain command-line tools, and so on. If you open a program that definitely doesn't support system proxy settings and it still has no network access at all, or its traffic never shows up in the panel, TUN isn't actually taking over traffic — go back and check whether the routing table has been claimed by other software, or whether service mode is running properly.

Also be aware that under fake-ip mode, some local network access and LAN device discovery features may be affected. If you need normal access to LAN devices at the same time, it's worth setting a dedicated direct rule for your local IP range in the config file, or using fake-ip-filter to exclude the relevant domains and address ranges, so local network access doesn't get incorrectly routed through a proxy.

Common Issues After Enabling TUN

• Network drops immediately after enabling: usually a routing table conflict — close any other software that might create a virtual adapter, then restart the client and re-enable TUN.
• Some apps can't connect, throwing certificate errors: if the client also has MitM (man-in-the-middle inspection) features enabled, you need to separately install and trust Clash's generated root certificate — this is unrelated to TUN mode itself. Try disabling MitM-related options in settings first to isolate the issue.
• On Windows, you have to reopen with admin rights after every reboot: this means service mode wasn't installed correctly — go back to the settings panel and reinstall the service component.
• Other devices on the LAN can no longer discover each other: check whether local network ranges (such as 192.168.0.0/16, 10.0.0.0/8) are set to direct in your rule list, and manually add rules if needed.

In short, TUN mode solves the inherent blind spots of system proxies. It relies on the virtual adapter and routing table adjustments at its core, and requires two extra steps beyond enabling a system proxy — driver installation and permission approval. Once you understand these three steps — creating the adapter, adjusting the route, and user-space routing — most specific error messages map directly to one of these steps for troubleshooting, instead of just blindly reinstalling the client.