What TUN Mode Actually Does

In everyday language, TUN mode means the proxy core creates a virtual network interface (often named something like utun, Meta, or tun0) and asks the operating system to send traffic through it. Clash then reads packets from that interface, classifies them with your rules, and forwards them to the correct outbound (DIRECT, a remote node, REJECT, and so on). From an application's perspective, nothing special is required: it opens a normal socket, and the OS transparently steers the flow into Clash's pipeline. That is why people call it a transparent proxy in the consumer VPN sense — not the Linux iptables REDIRECT sense alone, but the user-visible outcome: traffic is intercepted without per-app SOCKS or HTTP settings.

By contrast, system proxy mode (also called mixed port / HTTP & SOCKS on a local port) only affects programs that honor the OS proxy variables or manual browser settings. Many games, terminal tools, and background updaters ignore those variables. TUN closes that gap by sitting lower in the stack, closer to the IP layer, so more traffic types — including UDP for DNS, QUIC, and some games — can be governed by the same rule file. Modern Clash derivatives based on the mihomo core have invested heavily in TUN stability, IPv6, and DNS integration; if you are migrating cores, treat TUN as a first-class feature rather than an experimental toggle.

TUN vs System Proxy: When Each Wins

Choosing between TUN and system proxy is not about which one is "stronger" — it is about compatibility surface and operational cost. System proxy mode is lightweight: it does not require administrator rights on every platform, it is easy to turn off for a single misbehaving app, and it interacts predictably with corporate VPNs that also install virtual adapters. TUN mode, on the other hand, changes the default route for much of the machine's traffic. That gives you consistent rule enforcement, but it also means you must understand routing loops, split tunneling, and DNS capture or you can accidentally break all connectivity.

• Prefer TUN when you need UDP coverage, want games or CLI tools proxied without environment variables, or rely on domain-based rules for traffic that does not respect proxy settings.
• Prefer system proxy when you share a work laptop with strict MDM policies, run another VPN that already owns the routing table, or want the smallest possible privilege footprint.
• Use both thoughtfully: some users enable TUN for day-to-day browsing and gaming while keeping a quick toggle to fall back to system proxy when a remote desktop session misbehaves — your client should expose that switch clearly.

For a deeper look at how individual rule lines are evaluated once traffic reaches the core, see our detailed guide to Clash rule-based splitting; TUN only changes how packets arrive, not how rules match.

TUN Stacks: system, gVisor, and mixed

The tun.stack option decides how userspace reads and injects IP packets. The system stack uses the operating system's own TUN implementation and is usually the most CPU-efficient. The gvisor stack brings a userspace network stack that can improve compatibility with exotic protocols at the cost of higher CPU use. mixed combines characteristics of both and is widely recommended on current mihomo releases for balanced compatibility and stability, especially when you cannot predict the full set of applications on the machine.

# Example: recommended starting point (mihomo / Clash Meta family)
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true

Auto-Route, Strict-Route, and Bypassing the Tunnel

auto-route: true lets the core install routes so that traffic selected for the tunnel actually reaches Clash. auto-detect-interface: true helps pick the correct upstream WAN interface on multi-homed machines (Wi-Fi plus Ethernet, or tethering). strict-route: true is particularly important: it reduces the chance that applications find a path around the TUN interface by following more specific routes. Turning strict routing off can make debugging easier in niche lab setups, but for most users it is an invitation to silent leaks where some packets never touch the proxy chain.

You will still need explicit rules (and sometimes fake-ip-filter entries) for local subnets, LAN discovery, and intranet hostnames. A common pattern is to place DOMAIN-SUFFIX and IP-CIDR lines for private ranges ahead of the catch-all MATCH rule. Getting this wrong does not just affect "security" — it breaks printers, Chromecast, and NAS access in confusing ways, so iterate carefully.

DNS Hijack and Why It Matters for TUN

Transparent IP forwarding is only half of the story. Applications often resolve domain names before they connect; if DNS bypasses Clash, your rules may never see the meaningful domain — only an IP that landed in the wrong bucket. That is why TUN setups usually pair with DNS hijacking: Clash intercepts outgoing DNS queries (typically UDP/53 and sometimes TCP/53) and feeds them into its internal DNS module, which respects fake-ip or redir-host-style logic depending on your YAML.

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

Using any:53 is broader than pinning to a single resolver IP; it helps on laptops that switch resolvers between café Wi-Fi and home DHCP. Pair this with a well-tested dns section: enable the DNS module, list trustworthy upstreams, configure fallback for poisoned environments, and tune fake-ip-filter so local domains, NTP, and certain game CDNs do not receive imaginary addresses from the fake-ip pool. Misconfigured DNS is the number one cause of "everything worked until I enabled TUN" support threads.

Fake-IP vs Real IP in the TUN Workflow

With enhanced-mode: fake-ip, Clash answers DNS queries from a dedicated pool (commonly 198.18.0.1/16) so it can decide routing at connection time with full domain knowledge. That plays extremely well with domain-based rules. The trade-off is complexity: you must maintain filters for domains that should not use fake responses — think +.lan, +.local, captive portal check hosts, and streaming endpoints your provider instructs you to pin to DIRECT. If something breaks, temporarily switching enhanced-mode to normal is a valid bisection step to confirm you are fighting DNS rather than routing.

Permissions and Elevation by Operating System

Creating a TUN device is a privileged operation everywhere. Windows users typically run the helper or service as Administrator, or rely on a signed helper binary shipped with a GUI client. macOS prompts for approval when a component needs to install a network extension; third-party clients usually wrap this in a one-time setup wizard. On Linux, granting CAP_NET_ADMIN to the binary is a popular alternative to running the daemon as root:

sudo setcap cap_net_admin=ep /usr/local/bin/mihomo

If you refuse to grant any privilege, you are effectively choosing system proxy mode — which is fine, but you should not expect identical coverage. Document the privilege model for your own machines so future you is not surprised after a kernel or client update.

Troubleshooting: Loops, Leaks, and Partial Connectivity

Symptom: No Internet Immediately After Enabling TUN

Check for a DNS loop: the resolver you rely on might be routed back into Clash before it can answer. Mitigations include ensuring the core's own control plane and your real resolvers are reachable on DIRECT paths, widening fake-ip-filter, and verifying that dns.enable is actually true. On Windows, also confirm no other shim is capturing DNS on the same hook order.

Symptom: Sites Load but Streaming or Games Fail

You might be splitting TCP and UDP differently across outbounds, or UDP might be blocked by a node that only supports TCP HTTP proxies. Inspect whether the rule that matches the traffic sends it to a UDP-capable profile. Sometimes switching stack as noted earlier fixes QUIC or VoIP edge cases.

Symptom: LAN Devices Disappear

Add explicit DIRECT rules for RFC1918 ranges and multicast-friendly domains before aggressive proxy rules. Some discovery protocols bind to interface indexes — overly strict routing can starve them even when IP routing looks fine on paper.

CPU, Battery, and When to Tune

TUN adds per-packet work in userspace. On modern laptops the overhead is usually negligible compared to encryption on the wire, but on routers or single-board computers you might watch CPU spikes during large downloads. If profiling shows the userspace stack as hot, consider system stack, reduce logging verbosity, or offload heavy binary downloads to hours when contention does not matter. Battery-powered devices also benefit from clients that coalesce DNS updates and avoid constant rule-provider reloads.

Putting It Together With the Rest of Your Stack

TUN mode shines when the rest of the configuration is disciplined: fresh GeoIP and GeoSite data, sane subscription hygiene, and a rule set that you actually understand rather than one you pasted from a random gist. Our documentation hub walks through feature concepts that pair naturally with TUN, including strategy groups and remote rule providers. If you are also new to desktop setup, the Windows-focused tutorial covers client-level toggles that mirror what you will see on other platforms.

Choosing a Client That Makes TUN Manageable

Raw YAML power is useless if flipping TUN on feels like defusing a bomb. A well-designed Clash client hides the sharp edges: one-click TUN, clear status for DNS mode, quick escape hatches when the tunnel misbehaves, and visible core version information so you know you are on a maintained mihomo branch. Compared with piecing together obsolete binaries and hand-editing routes, that polish is not vanity — it is what keeps you safe when deadlines hit and the network must not die.

→ Download Clash for free and experience the difference on Windows, macOS, Android, iOS, or Linux — pair it with the TUN settings above and iterate calmly until your routes, DNS, and rules line up.