Clash TUN Mode: How It Works and How to Enable It

TUN Mode vs. System Proxy: Different Ways to Capture Traffic

Clash's system proxy and TUN mode solve the same first-step problem: getting an app's connections into the core. A system proxy gives apps a local HTTP or SOCKS proxy address. TUN creates a Layer 3 virtual network interface and uses operating-system routes to send eligible IP packets to the core. Neither is a proxy protocol, and neither replaces the proxy servers in your subscription.

Browsers usually follow the system proxy setting, but some games, command-line tools, and apps with their own network stack ignore it. Those programs may connect directly even while the browser uses the proxy. TUN does not require apps to understand HTTP proxies, but its coverage still depends on routes, exclusions, permissions, and protocol support.

Comparison	System proxy	TUN mode
How traffic enters	Apps connect to a local proxy port	System routes send IP packets to a virtual network interface
Typical entry point	For example, the local mixed port 7890	A TUN interface and its routes; apps don't need to specify a proxy port
UDP traffic	Usually not covered by the system HTTP proxy	Can be captured, but the outbound proxy must also support UDP
Permissions	Usually only requires changing the user's proxy settings	Desktop systems require the appropriate permissions; Android requires VPN authorization
Common limitations	Apps that ignore the setting bypass the proxy	May conflict with other VPNs, virtual adapters, or routing rules

How virtual adapters, routes, and outbound connections work

Take a TCP connection to a website. The app first gets the destination IP, then the operating system checks its routing table. With automatic routing enabled, packets that meet the capture criteria enter the TUN interface. The core reads the destination address and any available domain information, checks rules in order, then establishes a direct or proxied outbound connection.

App sends traffic: The app uses a regular network connection and doesn't need to specify 127.0.0.1:7890.
Route selection: Routes configured by the core determine which addresses enter the virtual adapter. Physical interfaces, local network routes, and exclusion rules also factor into the decision.
Protocol handling: The TUN protocol stack processes incoming IP traffic and passes it to the rules and outbound modules.
Choose an outbound route: The matching policy could be DIRECT, a reject policy, or a proxy group; traffic doesn't always use the same node.
Return traffic: The core sends responses back to the app and ensures the connection to the proxy server uses the physical network interface, avoiding a loop back into TUN.

So, “TUN is enabled” only confirms that part of the traffic entry configuration is active. An unavailable node, the wrong proxy group, a DNS timeout, or an incorrect outbound interface can still cause errors. When troubleshooting, check separately whether the virtual adapter was created, whether connections reach the core, and which outbound route was selected. Don't rely on the toggle's color alone.

DNS Hijacking and fake-ip: Preserving Domain-Based Rule Matching

Most apps resolve a domain before connecting to its IP address. If DNS queries bypass the core entirely, the core may see only the destination IP, leaving domain-based rules without a direct match. DNS capture sends queries to the core's resolver, where cached mappings or other domain-identification methods can provide information for routing decisions.

What port 53 capture can and can't do

In mihomo TUN configuration, dns-hijack can capture DNS traffic addressed to port 53. any:53 is commonly used for UDP DNS, and tcp://any:53 for TCP DNS. This isn't a universal way to intercept encrypted DNS: apps' built-in DoH usually uses HTTPS on port 443, while DoT usually uses port 853. Configuring port 53 won't automatically route those queries through the core's DNS resolver.

fake-ip is not a real server address

In fake-ip mode, eligible domains resolve to mapped addresses from a reserved range, such as 198.18.0.0/16. When an app connects to one of these addresses, the core uses the mapping to recover the domain, then applies rules and handles the actual outbound connection. This is a local mapping mechanism; it doesn't mean the remote website's real address has changed to that range.

Local network domains: Router admin pages, printers, and internal company services may require real DNS answers. Configure fake-ip-filter or domain-specific resolution rules as needed, alongside your internal DNS settings.
Cached addresses: After TUN is disabled, apps may keep using cached fake-ip addresses and temporarily fail to connect. Restart affected apps and, if needed, flush the system DNS cache.
Encrypted DNS in browsers: During troubleshooting, temporarily disable the browser's custom secure DNS setting to use a consistent resolution path. Once you identify the cause, decide whether to turn it back on.
IPv6: Working IPv4 doesn't guarantee IPv6 traffic is captured too. Check IPv6 support in the core, DNS, routes, and proxy node.

mihomo Configuration Example: Check Your Core Before Adding Fields

The snippet below is for mihomo cores that support these fields. Clash is a common name across the client ecosystem, but different clients bundle different cores, and configurations aren't necessarily interchangeable between builds of the original Clash. Check the core name in the client's About page or logs first, then see whether the client GUI overrides these fields.

This snippet demonstrates DNS and TUN only. It doesn't include nodes, proxy groups, or routing rules, so it can't be imported as a complete subscription. Merge the fields into the matching top-level sections of your existing configuration to avoid duplicate dns: or tun: keys.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query

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

Field	Purpose and checks
`listen: 127.0.0.1:1053`	Local DNS listening address. Port 1053 is not a proxy port, and the system won't use it automatically.
`stack: mixed`	Combines different protocol stacks for TCP and UDP in supported mihomo builds. If you run into compatibility issues, test other stacks as described in the documentation for your core version.
`auto-route`	Automatically configures routes for traffic capture. If you disable this, you'll usually need to manage routes yourself, so it's not a good default for initial troubleshooting.
`auto-detect-interface`	Automatically detects the outbound interface. If multiple network adapters are active, verify which one is actually being used.
`default-nameserver`	Resolves the hostnames of DNS upstreams. The upstream in this example must be reachable on your network; don't assume the example address is right for every network.

How to Enable TUN on Windows, macOS, and Android

Windows: Set Up the Service or Administrator Permissions First

Leave TUN disabled for now and confirm that your current subscription can reach the target site through the system proxy. If that already fails, troubleshoot the node or subscription first.
Look for service mode, service installation, or permission settings in the client. Clients with background service support usually require one-time administrator authorization. Other implementations may require running the client with elevated privileges; follow the client's instructions.
Turn off automatic connections for other VPNs, enable “TUN mode” in the client, and check the logs for interface creation, route addition, or DNS listener errors.
Temporarily disable the system proxy, then test both a regular app and one that normally ignores system proxy settings. This helps distinguish TUN capture from the system proxy working as expected.

In Windows 11, check the system proxy under Settings → Network & internet → Proxy. For troubleshooting, use route print to view routes and PowerShell's Get-NetAdapter to list network adapters. The virtual adapter's name depends on the client, so don't rely on one fixed name to decide whether setup worked.

macOS: Check Helper Permissions and the Network Route

Confirm that both the client and its core support TUN. Install or authorize any required privileged helper when prompted. The system proxy toggle is not the TUN toggle.
After enabling TUN, check the client logs and system routes. In Terminal, run ifconfig to view interfaces and netstat -rn to view routes.
Test again after switching between Wi-Fi, Ethernet, and a mobile hotspot. If the old outbound interface is still selected, restart the core or re-enable TUN, then check interface detection again.

The system proxy is usually under System Settings → Network → current network service → Details → Proxies. Seeing a utun interface doesn't prove it belongs to the current client; other network services can create similar interfaces. Check when it appeared and compare that with the logs.

Android: VPN Authorization Provides the Traffic Entry Point

Android clients typically use the system VpnService to create a virtual network interface. The first time you connect, Android prompts you to authorize the VPN. Without authorization, the client can't establish this traffic capture path. This doesn't grant the client root access or confirm that the subscription is connected successfully.

Import a subscription, choose an available policy, tap the client's connect button, and approve the system VPN request.
Check the app routing or bypass list to make sure the target app isn't excluded. Some clients also distinguish between “proxy only selected apps” and “bypass selected apps.”
In system settings, check for always-on VPN and options such as “Block connections without VPN.” Names vary by manufacturer, and these settings may prevent another client from connecting.
If the connection drops when the screen turns off, check background activity and battery optimization restrictions. Repeatedly changing DNS won't fix a process being stopped by the system.

Usually, only one VPN service can be active at a time for the same Android user or work profile. Firewalls and filtering tools that use a VPN interface can replace or conflict with proxy clients. Desktop YAML TUN fields may not be a valid configuration method for an Android client; use the settings provided by the client instead.

No Internet After Enabling TUN: Troubleshoot Each Step

Change one setting at a time and keep a copy of the original configuration. First determine whether all apps fail, only one domain fails, or only UDP features fail; each points to a different troubleshooting path.

Symptom	Check first	What to do
Toggle immediately turns off or interface creation fails	Permissions, service status, and interface conflicts	Check the first error in the logs, confirm the service has started, and retry with other VPNs temporarily disabled.
Can't access domains	DNS upstream and capture path	Check for DNS timeout errors. Run `nslookup example.com` to see the system's query result, but don't treat it as proof of the browser's DNS resolution path.
Web pages work, but voice chat or games fail	UDP support on the outbound route, rules, and MTU	Confirm that the node protocol and server support UDP. Check connection logs first, then adjust the MTU using the documentation for your core version.
Can't reach a printer, NAS, or internal domain	Local network routes and internal DNS	Check the actual subnet, direct-routing rules, and TUN route exclusions. Avoid sending the entire local network through a remote node.
Connection appears, but uses the wrong outbound route	Mode, matched rule, and proxy group	Check the connection log for the matched rule and full policy chain. Look for a `DIRECT` match or an incorrect fallback policy.
Still can't connect after disabling TUN	Leftover proxy settings, DNS cache, or routes	Exit the client, check the system proxy settings, restart affected apps, and verify that routes have been restored.

Excluding local traffic and using DIRECT are different operations

Setting an internal address to DIRECT in your rules means the connection enters the core and is then routed directly. Excluding a subnet at the TUN routing layer may keep its traffic from reaching the core at all. These are different mechanisms. With a corporate VPN, first find out how your company's subnets and DNS are configured; don't blindly apply an exclusion list covering every private address.

Check MTU and Dual-VPN Conflicts Later

Investigate path MTU only if large responses, uploads, or specific UDP sessions get stuck. Lowering the MTU alone won't fix unreachable DNS or a failed node. Two VPNs that both modify the default route can also create loops or shift traffic to the wrong interface. Verify that each works independently before attempting an advanced routing setup.

Post-Setup Checks and How to Roll Back

Verify traffic capture: With the system proxy off and TUN still enabled, test the target app and check whether its connection appears in the logs.
Verify routing: Visit one destination that should connect directly and one that should use a proxy. Check the matched rule and policy chain in the logs. An outbound IP lookup can help, but it doesn't show whether every app is being captured.
Verify DNS: Check that resolution succeeds, that it uses the expected fake-ip or real-address mode, and that internal domains remain accessible.
Verify required features: Test the voice chat, games, or other UDP features you need. ping uses ICMP, so its result alone can't prove whether TCP or UDP proxy connections are working.
Verify recovery: Turn off TUN and check that your regular connection works again. On Windows, you can run ipconfig /flushdns to flush the system DNS cache, then restart apps that may be holding old addresses.

If you only need a proxy in your browser and other apps that follow system proxy settings, the system proxy is usually easier to monitor and maintain. Enable TUN if you need to cover programs that ignore proxy settings or handle UDP traffic consistently, and keep a tested rollback configuration. A stable setup is one where the traffic entry point, DNS, rules, and outbound route are easy to explain—not one with more toggles enabled.