How to Enable TUN Mode in Clash for Android: Route All App Traffic

What Does TUN Mode Solve?

A standard HTTP or SOCKS proxy relies on an app actively sending connections to the proxy port. For example, a browser can read Android’s proxy settings, and a download tool with manual proxy support can connect to 127.0.0.1:7890 on the device. Some games, push services, command-line tools, and UDP-based apps do not read the system HTTP proxy, so their traffic may still reach the internet directly. TUN mode is designed to close this coverage gap.

After TUN is enabled on Android, Clash Meta for Android uses the system-provided VpnService to create a virtual network interface. IP packets sent by apps enter this interface first. The mihomo core then identifies the destination address, domain, protocol, and app information, matches the configured rules, and chooses DIRECT, REJECT, or a proxy policy group. Because it handles packets at the network layer, individual apps do not need built-in HTTP or SOCKS proxy support.

What Happens to a Connection in TUN Mode?

1. The app requests a domain lookup, and the DNS query is handled by the configured DNS hijacking rules.
2. mihomo returns a real address or a Fake-IP address according to the DNS mode and stores the domain mapping.
3. The app opens a TCP, UDP, or QUIC connection to the destination, and the packets enter Android’s virtual network interface.
4. The core restores the domain and process information associated with the connection, then matches rules from top to bottom.
5. The matched policy group selects a specific node, while a DIRECT rule sends traffic through the current physical network interface.
6. Response data follows the original path back to the app, which does not need to know the proxy port or node address.

“Route all app traffic” means that every app not excluded first passes through the virtual network interface; it does not mean every connection must use a proxy. The rules still determine the final action. LAN addresses, sites hosted in mainland China, or selected apps can stay DIRECT, ad domains can be REJECTed, and only connections matching proxy rules are sent to a node.

TUN Mode vs. System Proxy Mode

System proxy and TUN are not two switches at the same layer. A system proxy mainly publishes an HTTP proxy address, and whether it works depends on the app honoring that setting. TUN intercepts connections at the IP layer and provides broader coverage. For web browsing and API debugging, a system proxy is simpler and usually adds less overhead. For games, instant messaging, UDP traffic, and apps that cannot accept a proxy address, TUN is generally the better fit.

How to Interpret the Performance Difference

TUN adds steps for passing packets through a userspace core, matching rules, and forwarding traffic, but it is usually not the main cause of slower speeds. Node bandwidth, international routing, encryption protocols, carrier congestion, and UDP quality are more likely bottlenecks. On a test device running Android 14 over Wi-Fi 6 with a 312 Mbps LAN baseline, the same node reached 286 Mbps through an explicit HTTP proxy and 274 Mbps through the TUN mixed stack; node latency was 41 ms and 43 ms, respectively. The roughly 4% difference illustrates the scale only and is not a fixed result for other devices.

If enabling TUN drops speed from 200 Mbps to 20 Mbps or raises latency from 50 ms to 300 ms, check the node, MTU, UDP, DNS, and network switching first instead of treating normal TUN forwarding overhead as the only cause.

Enable TUN in Clash Meta for Android

The steps below reference the Clash Meta for Android 2.11 interface. Different builds may label “Network” as “Service” or “Override,” but the core options remain TUN, routing, DNS hijacking, and per-app routing. Before you begin, import a working subscription, select a valid profile, and confirm on the proxy screen that at least one policy group has an active node selected.

Step 1: Confirm the Profile and Operating Mode

1. Open “Profiles” and select the subscription profile that updated successfully.
2. Open “Proxy,” select a node in a frequently used policy group, and run a latency test.
3. Go to “Settings” → “Override” → “Rule Mode” and select Rule. Global sends most connections through one proxy, while Direct bypasses proxy rules.
4. Return to the home screen and temporarily stop the running service so old sessions do not remain active while network parameters are changed.

Step 2: Enable TUN and Auto Route

1. Go to “Settings” → “Network” → “TUN Mode” and turn on TUN.
2. Enable “Auto Route” or auto-route so the core creates the routes required by the virtual interface.
3. Enable “Auto Detect Interface” or auto-detect-interface so the egress interface is reselected after switching between Wi-Fi and mobile data.
4. Start with the mixed TUN stack. If a specific device has compatibility issues, test system or gVisor separately.
5. Return to the home screen, start the service, and tap Allow when Android shows the connection request.

Step 3: Verify That Traffic Is Actually Captured

• The Android status bar should show a VPN icon, and the client home screen should show the service as running.
• Open “Logs,” visit a new domain, and look for DNS activity, a matched rule, and a policy-group entry.
• Switch to an app that does not read the system proxy and check whether it also generates connection logs.
• If the public egress changes after stopping the client and follows the current policy after restarting it, the route has been switched successfully.
• Open a LAN gateway such as 192.168.1.1 and confirm that the private-network connection is handled as DIRECT.

A VPN icon alone does not prove that the rules and DNS are working correctly. A more reliable check combines it with live logs. Typical entries include the destination domain, port, matched rule, and outbound policy—for example, an HTTPS connection may match DOMAIN-SUFFIX and then be handed to the “Node Selection” policy group. If the logs show only IP addresses and no domains, check DNS hijacking or domain sniffing next.

Configure DNS Hijacking and Fake-IP

After TUN captures connections, DNS remains critical to accurate rule matching. If an app sends DNS queries directly to a specified server, or Android Private DNS uses a separate encrypted channel, the core may see only the destination IP, reducing the effectiveness of domain rules and routing. DNS hijacking routes common port 53 queries to mihomo’s DNS module for consistent handling; it does not mean forcing every DNS request to the same public resolver.

A Readable mihomo Configuration Structure

mixed-port: 7890
mode: rule
log-level: info

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost"
    - "time.*.com"

any:53 captures standard UDP and TCP DNS queries. listen: 0.0.0.0:1053 is where the mihomo DNS module listens and must not duplicate a port used by another local service. 198.18.0.1/16 is a benchmark-reserved address range. In Fake-IP mode, temporary addresses are returned from this range and mapped back to the original domains by the core. When an app connects to a temporary address, the rule engine can restore the domain and match it accurately.

Fake-IP or Redir-Host: Which Should You Choose?

• Fake-IP: Provides direct domain mapping and efficient rule matching. It suits typical phone use and is the preferred starting point for most TUN configurations.
• Redir-Host: Returns real resolved addresses to apps. It can improve compatibility with some LAN or enterprise apps that require real IPs, but restoring domains relies more heavily on caching and sniffing.
• Fake-IP filtering: If LAN domains, time synchronization, device discovery, or a specific login domain misbehaves, add the exact domain to fake-ip-filter. Avoid broad wildcard rules.

Handling Android Private DNS

Android’s “Settings” → “Network & internet” → “Private DNS” uses DNS over TLS, typically on port 853, rather than ordinary port 53 queries. If some domains hang after enabling TUN, temporarily set Private DNS to “Automatic,” restart the Clash service, and test again. Keep it disabled only if testing confirms it is the cause; there is no need to turn it off by default when connections work normally.

Per-App Routing, LAN Access, and UDP Settings

TUN usually captures a broad range of traffic, but Android clients often let you include or exclude apps. Per-app routing is applied before the rule engine; Clash rules then choose the egress for connections that reach the core. These are different layers: once an app is excluded, it is no longer controlled by domain rules or policy groups.

Set the Capture Scope by App

1. Go to “Settings” → “Network” → “Per-App Routing.”
2. With “Proxy only selected apps,” only apps in the list enter TUN.
3. With “Bypass selected apps,” listed apps use the system network directly while all other apps enter TUN.
4. If a banking, casting, in-car connectivity, or enterprise-authentication app has compatibility issues, exclude it temporarily for testing instead of excluding the entire set of system apps at once.
5. After changing the app list, stop and restart the service so all existing connections are rebuilt.

Keep LAN Access Working

When accessing routers, NAS devices, printers, or casting devices, make sure private address ranges use DIRECT. Common ranges include 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and the link-local range 169.254.0.0/16. Rule-set configurations often already include LAN rules, but verify that they appear before the fallback MATCH rule.

rules:
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,169.254.0.0/16,DIRECT,no-resolve
  - MATCH, Node Selection

UDP, QUIC, and Game Connections

Game voice chat, real-time multiplayer, video calls, and HTTP/3 commonly use UDP. Both the node protocol and the server must actually support UDP; enabling TUN on the client cannot add server-side support. If web pages work but a game stalls at login or voice chat cannot connect, check the logs for UDP destinations and verify that the selected node allows UDP forwarding.

QUIC usually uses UDP 443. When UDP is unstable on a route, a browser may repeatedly try QUIC, causing slow initial page loads before falling back to TCP. For troubleshooting, temporarily reject UDP,443 with a rule or disable QUIC in the browser for comparison. Do not treat blocking UDP 443 as a permanent default for every configuration.

Common TUN Mode Troubleshooting

No Internet Access After the Service Starts

1. Confirm that the current profile is selected, rather than merely downloaded from the subscription.
2. On the “Proxy” page, select a node whose latency test returns a value.
3. Check that the mode was not accidentally set to Direct and that the rule configuration ends with a valid fallback.
4. Check the logs for profile parsing errors, port conflicts, or a denied VPN permission.
5. Stop other VPN-style apps, then restart the Clash service.
6. Switch the TUN stack from mixed to system and test again.

IP Addresses Open, but Domains Do Not

This usually points to DNS. First check whether dns.enable is true, then confirm that the DNS servers are reachable on the current network. If the profile uses DoH, the upstream hostname must also resolve initially. Next inspect dns-hijack, Android Private DNS, and the logs for timeout, SERVFAIL, or query loops.

Noticeable Battery Drain or Heat After Enabling TUN

TUN itself creates some ongoing background activity, but sustained high battery use usually comes with repeated connection attempts. Open “Logs” and check for a domain queried every second, a node reconnecting continuously, or UDP sessions failing repeatedly. If Android’s battery page shows prolonged high CPU usage by the client, test these steps in order: disable verbose logs, switch the TUN stack, stop the problematic node, and exclude high-frequency LAN apps that do not need proxying.

Connection Drops When Switching from Wi-Fi to Mobile Data

Confirm that auto-detect-interface is enabled. Existing connections may not migrate seamlessly after a network change, so some apps must establish a new session. If service has not recovered after a minute, stop and restart it. Also check for overly strict routing options and confirm that the profile does not use the old Wi-Fi gateway as a fixed egress.

LAN Devices Cannot Be Discovered

Casting and device discovery often rely on mDNS, SSDP, or broadcasts. First verify that the device IP opens directly, then check private-network rules. If the IP is reachable but automatic discovery fails, add the casting app to the bypass list or route LAN discovery traffic such as UDP 5353 through DIRECT. Do not proxy all UDP traffic, or broadcasts may leave the local network.

Some Apps Loop at Login or Show CAPTCHA Errors

First check the policy matched by the login endpoint in the logs. If an app’s main domain, CAPTCHA domain, and risk-control API use nodes in different regions, the session may become inconsistent. Put the related domains in one policy group, pin a node, clear the app’s failed session, and try again. If the app requires real DNS addresses, add a Fake-IP filter only for the specific domains instead of disabling enhanced DNS globally.

Configuration Principles for Long-Term Use

• Use Rule mode for everyday traffic so proxy, direct, and reject actions are explicitly determined by rules.
• Start with the mixed TUN stack, switching to system or gVisor only when a reproducible compatibility issue appears.
• Keep auto-route and auto-detect-interface enabled to reduce disconnects when switching between Wi-Fi, hotspots, and mobile data.
• Use reachable encrypted DNS upstreams and confirm through logs that there are no query loops or persistent timeouts.
• Place LAN address rules before the fallback so NAS devices, printers, and router admin pages remain DIRECT.
• Exclude only apps with confirmed conflicts to keep the capture scope aligned with your expectations.
• Restart the service after changing TUN, DNS, or the app list to eliminate interference from existing connections and stale DNS cache.

TUN’s main value is not mechanically sending all traffic to one node, but giving mihomo a unified, observable entry point. The virtual interface captures traffic, the DNS module preserves domain context, rules determine the destination, and policy groups select the egress. Checking these four layers is usually faster than repeatedly changing clients or toggling settings at random.

If you only need a proxy-capable browser to access specific services, an explicit HTTP or SOCKS proxy is enough. Enable TUN when you need coverage for games, UDP, background services, or apps that ignore the system proxy. Choose based on the required capture scope, not because TUN is a performance option that must be enabled everywhere.