Clash TUN Mode Explained:How Virtual Adapters Capture All Traffic

TUN vs. the System Proxy

Your browser works, but command-line tools time out. Websites load, but games or desktop apps still connect directly. When this happens, check where traffic enters the network stack before switching nodes. The Windows system proxy only tells apps that honor the setting to send requests to a specified HTTP proxy. Apps that ignore the system proxy won't automatically route through Clash just because the setting is enabled.

TUN adds a virtual network adapter at the network layer and uses routes to send matching IP packets to the core. Apps don't need to understand HTTP proxies or offer proxy settings. The core receives the traffic and applies your rules to send it direct, through a proxy, or reject it.

How a Virtual Adapter Captures Connections

Think of a connection as a four-step process. First, check whether the traffic reaches the core. Then see which rule it matches. Only after that should you investigate node performance. Seeing a virtual adapter appear does not prove that traffic is being captured.

1. The app sends a request. It sends TCP or UDP data to a destination IP address. If it uses a domain name, it must resolve that name first.
2. Windows selects a route. When the client enables automatic routing, it adds routes that send matching traffic to the TUN interface. More specific routes, excluded addresses, and other VPNs can affect the result.
3. The core identifies the traffic and matches a rule. It uses information such as DNS mappings to identify the domain, then applies rules based on the domain, IP, or process. If it can't recover the domain, domain-based rules may not match.
4. The connection goes out. Direct traffic leaves through the physical adapter; proxied traffic is forwarded through the selected node. The client must keep its own outbound connections from looping back into TUN.

TUN does not replace your physical network adapter. Wi-Fi and Ethernet still provide the actual network connection; the virtual adapter sends selected traffic to the core for processing. If a node doesn't support UDP, enabling TUN won't add UDP forwarding. Whether games, voice chat, and QUIC work depends on the node protocol, server configuration, and network conditions.

Before You Start: Client and Service Mode

Set Up a Working Connection First

• Import a subscription from a trusted source, then select the profile you intend to use in the client. Downloading the subscription file alone isn't enough.
• Open your proxy group and select a node manually. First, use the system proxy to confirm that your browser can connect.
• Note the current listening port. 7890 is a common example, but use the value shown in your client rather than copying someone else's port.
• Temporarily exit other VPNs, accelerators, and proxy clients to avoid multiple virtual adapters changing routes at the same time.
• Save your current configuration, DNS settings, and VPN details. If you're connected remotely, don't switch routes without a plan; do this on the local machine whenever possible.

Service Mode Is Not the TUN Switch

In older versions of Clash for Windows, service management is usually accessed with the gear button next to General → Service Mode. Open the management window, click Install, and approve the Windows permission prompts. Button locations and status labels can vary between archived builds. If you can't find the option, check which version you're using instead of repeatedly installing drivers from unknown sources.

Service mode lets a background process perform privileged operations; the TUN switch controls traffic capture by the virtual adapter. After installing the service, make sure it's running before enabling TUN Mode. These features aren't interchangeable, and you don't need to run the entire GUI as an administrator all the time.

In other clients, look in settings for the actual controls labeled “Service Mode,” “System Service,” or “TUN Mode.” Don't downgrade just to follow a guide for an older interface. If service installation fails, note the full error and core logs, then check permissions, security software logs, and leftover services. Don't disable system security protections as a first step.

mihomo TUN Settings and DNS Hijacking

The following is a sample of mihomo fields, not a complete subscription you can import on its own. It contains no nodes, proxy groups, or routing rules, so it can't replace your existing configuration. Older versions of Clash for Windows may not support every field shown. If your client generates TUN and DNS settings through its interface, use that interface or its override feature to avoid losing changes when the subscription updates.

mode: rule
mixed-port: 7890

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

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

What Each Key Setting Does

• auto-route: Lets the core configure the routes needed to capture traffic. Creating the adapter without the right routes can still leave app traffic outside TUN.
• auto-detect-interface: Attempts to identify the outbound interface automatically. With multiple adapters, a corporate VPN, or wired and wireless connections in use, check the logs to confirm which interface traffic actually uses.
• stack: mixed: Uses a mixed network stack in mihomo. Stack support and implementation depend on the core version. If a particular app has compatibility issues, consult the documentation and compare other available options.
• dns-hijack: Sends DNS traffic within the capture scope that targets the specified ports to the built-in DNS server. UDP 53 and TCP 53 are listed separately; this does not detect all encrypted DNS traffic.
• listen: 127.0.0.1:1053: Makes the built-in DNS server listen on port 1053 at the local loopback address. This does not mean you should enter a Windows DNS server address with a port attached.
• fake-ip: Assigns synthetic addresses to domain names so the core can associate later connections with those names. The example address pool, 198.18.0.1/16, is not a node address.

The two upstreams in this example are plain DNS addresses, included only to illustrate the field structure. They aren't suitable for every network and don't provide encrypted DNS. For a real setup, consider upstream reachability, resolving node domains, split DNS, and internal corporate domains. For more details, see the configuration reference. Don't treat this sample as a one-size-fits-all best practice.

Why DNS Affects Rule Matching

Domain-based rules need domain information. If an app resolves names over an encrypted connection or reuses a cached result to connect directly to an IP, the core may not get the domain mapping it needs. DNS hijacking on port 53 does not automatically cover DoH over HTTPS or DoT over TLS. Browser Secure DNS, built-in app resolvers, and Windows encrypted DNS settings can all change how names are resolved.

For troubleshooting, temporarily disable custom Secure DNS in the test app and compare results using system DNS. Turn it back on when you're done. Don't conclude that DNS is leaking from a single lookup, and don't use resolving every domain to fake-IP as a success criterion. Local device names, internal corporate domains, and some specialized apps may need exceptions or dedicated upstreams configured according to the client documentation.

Enable TUN: Change One Setting at a Time

1. Confirm the basic proxy works. Keep rule mode enabled and select a node you've verified can connect. Leave TUN off for now to rule out subscription or node issues.
2. Install and start the service. Do this through the client's service management controls and confirm the service is running. If it fails to start, resolve permission issues or remove leftover services before changing anything else.
3. Enable TUN. Check the logs for errors such as insufficient permissions, interface creation failures, route errors, or a DNS port conflict. If an error appears, turn TUN off and save the logs.
4. Turn off the system proxy for an isolated test. This helps confirm whether TUN is capturing traffic; it doesn't mean you can't use both at once. Otherwise, a working browser may still be using the HTTP proxy.
5. Start a fresh test connection. Fully exit and reopen the test app, or make a new request. Existing long-lived connections and cached DNS results may still use the old route.
6. Inspect connection details. Check the destination, matched rule, and policy chain in the client's connection list. After testing, decide whether to keep the system proxy enabled for everyday use.

If you only browse the web and the system proxy meets your needs, there's no need to enable TUN just for broader coverage. Capturing more traffic also means dealing with compatibility issues involving local network discovery, corporate networks, sleep and wake, and switching between adapters.

Verify on Windows: Adapter, Routes, and Connections

Don't rely on the switch color alone. Check the virtual interface, route changes, and actual connections, and compare the results. The commands below show the current state; they don't modify adapters or remove routes.

Step 1: Check Interfaces and Routes

Open PowerShell and run the commands below with TUN off, then again with it on. Compare the new interfaces and routes; don't assume the virtual adapter has a particular fixed name.

Get-NetAdapter -IncludeHidden |
  Format-Table Name, InterfaceDescription, Status, ifIndex

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

Get-DnsClientServerAddress -AddressFamily IPv4

A new interface is a clue, not proof. TUN may use multiple routes to cover address ranges rather than one familiar default route. Also check for more specific routes added by other VPNs. If the traffic uses IPv6, the IPv4 output above alone cannot confirm that all traffic is captured.

Step 2: Make a Request Without an Explicit Proxy

With the system proxy turned off, run the request below. --noproxy "*" tells curl not to use an explicit proxy, including one set through environment variables. It does not bypass the operating system's TUN routes.

curl.exe --noproxy "*" -I --connect-timeout 10 https://example.com/

An HTTP response confirms only that the request succeeded; it doesn't prove that it went through a proxy, since the destination may also be reachable directly. Open the client's connection list right away, find the request by domain or address, and check the matched rule and final DIRECT or node policy. If the request disappears too quickly, check the client logs as well; whether connections appear there depends on your logging settings.

Step 3: Test the App That Needs TUN

Restart an app that previously ignored the system proxy, make a network request, and check whether it appears in the connection list. A browser test can't replace a UDP test for a game, and a successful TCP request doesn't confirm that voice chat works. To verify the remote exit, use a trusted IP lookup service and compare it with the connection details. Don't rely only on a webpage's reported location to judge the whole system.

Test IPv6 separately too. Check the client's IPv6 and routing settings, whether Windows has an IPv6 address, and whether the destination has an AAAA record. Don't claim all IPv6 traffic is captured without testing it, and don't disable IPv6 system-wide as a default fix.

Common Problems and Troubleshooting Order

Troubleshoot local network issues layer by layer. Setting a private address range to DIRECT only changes the outbound policy after traffic reaches the core; it does not make that range bypass the virtual adapter entirely. Devices that rely on broadcast, multicast, or other discovery protocols may also need route exclusions. Use your actual subnet rather than assuming every home network uses 192.168.1.0/24.

If DNS changes still return an old result, save any necessary information, then run ipconfig /flushdns to clear the Windows DNS cache and restart the test app. This won't clear every browser's internal cache or fix an upstream or routing problem. Repeatedly running network reset commands is not a troubleshooting strategy.

Turn TUN Off and Restore Settings

If a test fails, turn off TUN first, then exit the client normally or stop the relevant service. In Windows 11, check “Settings → Network & internet → Proxy → Manual proxy setup” for a leftover local proxy. In Windows 10, check the corresponding options under “Settings → Network & internet → Proxy.” If your organization configured the proxy, don't overwrite its settings.

• After disabling traffic capture, confirm that regular websites and local network devices work as they did before testing.
• If you changed DNS manually, restore the value you recorded. Don't automatically switch everything to automatic DNS.
• Check the interfaces and routes again to confirm that no other VPN or proxy is still capturing traffic.
• When reporting an issue, include your OS version, client and core versions, the time of the error, and redacted logs. Remove subscription URLs, access tokens, and node credentials.

To confirm that TUN is configured correctly, check three things: the app you want to capture reaches the core, its connection matches the expected rule, and your network returns to normal when you exit. Testing the traffic entry point, DNS, rules, and outbound path separately makes issues easier to pinpoint than repeatedly switching nodes.