How to Enable Clash TUN Mode on Windows: Virtual Adapters, Traffic Routing, and Service Mode

System Proxy vs. TUN: Different Traffic Entry Points, Same Routing Rules

Your browser works, but your terminal or game launcher cannot connect. A common reason is that these apps do not use the Windows system proxy settings. A system proxy provides an address such as 127.0.0.1:7890 and lets each app decide whether to use it; it does not automatically route every connection on your PC through Clash.

TUN creates a virtual network interface and routes matching IP traffic into the core. Apps do not need to support HTTP or SOCKS proxies for their connections to be captured. This guide covers Windows 10 and Windows 11 with Clash clients using the mihomo core. Fields, drivers, and menus may differ in older Clash cores, so do not assume every setting applies.

Before You Start: Subscription, Core, and Network Baseline

Avoid importing a subscription, switching nodes, changing DNS, and enabling TUN all in one go. First establish a working baseline so you can identify which layer is causing a problem.

1. Check the client and core versions. Look under Settings → About or in the client’s core information panel. Confirm that the client is running mihomo; do not infer its capabilities from the client’s name alone.
2. Verify your subscription. Update the configuration and select a reachable node. Temporarily enable the system proxy, then visit one site that requires a proxy and one that connects directly.
3. Note the local port. For example, the mixed port might be 7890. This is an HTTP/SOCKS entry point, not a virtual adapter port or a DNS listening port.
4. Note other networking components. These may include a corporate VPN, game booster, another proxy client, or virtual interfaces created by Hyper-V, WSL, or Docker.
5. Plan how to recover. Know where the TUN toggle is. If you are working over Remote Desktop, make sure you have local access or another management channel before changing routes, so you can recover if the connection drops.

For an initial test, quit other proxies and game boosters, leaving only the network connections you need. On a managed work device, check your organization's network policies first. Do not disable security software, the firewall, or required access controls just to make the toggle turn green.

Install Service Mode, Then Enable the TUN Adapter

Step 1: Give the Core the Permissions It Needs

Creating a TUN interface and changing routes on Windows require appropriate permissions. A common approach is to install the background service provided by the client, which handles tasks that need elevated privileges. Service mode addresses permissions and background management; it does not improve node performance or enable TUN automatically.

1. Open Settings in the client and look for Service Mode or Clash Service. Some clients put this under Settings → Clash Settings. Menu names vary by version, so follow what your client actually shows.
2. Click Install or Install Service and approve the Windows User Account Control prompt. Do not move the client’s installation folder during setup.
3. Wait until the client shows Installed or Running. If it asks you to restart the core or client, save your configuration first, then restart.
4. If installation fails, check the installation logs and security software records first. Running the client as an administrator temporarily can help identify a permissions issue, but do not repeatedly install driver packages from unknown sources.

To help check the service, you can run the following read-only command in PowerShell. Service names vary by client, so use the results only as a clue and verify them against the client logs and the service executable path.

Get-Service | Where-Object {
  $_.Name -match 'clash|mihomo|verge' -or
  $_.DisplayName -match 'clash|mihomo|verge'
} | Format-Table Status, Name, DisplayName -AutoSize

Step 2: Enable TUN and Keep Rule Mode

1. Find TUN Mode in the client settings or on the home screen. If it is in a subpage, open that page and enable the virtual adapter.
2. For your first test, keep the client’s recommended stack and enable automatic routing. Do not change the MTU, interface name, or interface binding at the same time.
3. Keep Rule mode enabled and use the node or policy group you just verified.
4. Check the logs for messages confirming that the interface was created and routes were configured successfully. A lit toggle alone does not prove that traffic is being captured.

Press Win + R, enter ncpa.cpl, and open Network Connections to check for a new interface. Its name depends on the client or configuration; it may not be called “TUN.” Do not change its sharing settings or manually assign it a default gateway.

DNS Hijacking and fake-ip: Why DNS Needs Checking

Traffic entering TUN does not guarantee that DNS is handled as expected. An app may still send DNS queries to your router, or a browser may use Secure DNS over HTTPS. If the core cannot associate a destination IP with a domain, domain-based routing rules may not match as intended.

mihomo’s dns-hijack can send specified DNS traffic passing through TUN to its built-in DNS module. A common configuration intercepts UDP 53 and TCP 53. This does not capture every type of DNS traffic: DoH typically uses HTTPS on port 443, while DoT typically uses port 853; neither is ordinary DNS on port 53.

mihomo Configuration Field Example

This snippet illustrates the configuration fields; it is not a complete subscription and includes no nodes, policy groups, or routing rules. If your existing configuration already has tun: or dns:, merge the settings into those sections. Do not paste duplicate keys at the same level.

tun:
  enable: true
  stack: system
  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
    - 1.1.1.1

• auto-route: Lets the core set up the routes needed to capture traffic. If disabled, you must plan the routes yourself, so it is not recommended for initial troubleshooting.
• auto-detect-interface: Attempts to identify the outgoing interface. With multiple adapters or a corporate VPN, you may still need to select the correct interface manually; detection is not guaranteed to work in every environment.
• stack: system: Uses the system network stack. If your client recommends another stack, start with its default. Switching stacks is mainly a compatibility troubleshooting step, not a guaranteed way to improve speed.
• listen: 127.0.0.1:1053: The local listening address for the built-in DNS server. The standard Windows DNS address field does not accept a port, so you cannot use this as a system DNS address with a port appended.
• fake-ip: Assigns mapped addresses to domains so connections can be associated with their domain names. The 198.18.0.0/16 range in this example is an expected mapping range, not the real address of a remote website.

The example DNS servers use standard DNS. Whether they are reachable depends on your network, and queries are not encrypted. In practice, stick with a DNS setup you have already verified. Resolving node server names, internal corporate domains, and DNS for routing rules may require separate configuration; changing these two server addresses will not solve every DNS issue.

Apply the Configuration and Clear the Cache

Use the client’s override, extension configuration, or TUN/DNS settings where possible. Avoid editing files that get overwritten whenever the subscription updates. Apply the changes, restart the core, then clear the Windows DNS cache from Command Prompt:

ipconfig /flushdns

Then fully quit and reopen the app you are testing. Browsers may keep their own DNS cache. If results still differ, temporarily turn off the browser’s Secure DNS for a comparison test, note the results, and restore your preferred setting afterward. You do not need to permanently disable all encrypted DNS to use TUN.

Verify Traffic Capture: Check the Terminal, Games, and Connection Logs

Terminal Test: Bypass Explicit Proxies While Keeping TUN Enabled

In Windows PowerShell, run curl.exe explicitly to avoid environments that interpret curl as a different command. Turn off the client’s system proxy first, then run:

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

--noproxy "*" tells this curl request not to use an explicit proxy, including common proxy environment variables. It does not bypass system routing or TUN. This test is useful for checking whether an app that does not support or use the system proxy can reach the core through TUN. An HTTP response only means the request got a response; it does not tell you which node was used.

• Open the client’s Connections page and filter this request by destination domain, destination IP, or process.
• Check the matched rule and policy chain. If the result is DIRECT, the current policy calls for a direct connection; that does not necessarily mean TUN has failed.
• Turn off TUN and run the same command again for comparison. If a site already connects directly, it is normal for both tests to succeed.
• To test the proxy route, use a destination that you know requires a proxy and are allowed to access. Also confirm that the applicable rule selects a proxy policy.

To inspect interfaces and routes, you can run the following read-only commands. Use the output to observe changes; do not manually add routes based on interface numbers from another PC.

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status -AutoSize
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object InterfaceIndex, DestinationPrefix |
  Format-Table InterfaceIndex, DestinationPrefix, NextHop, RouteMetric -AutoSize

Game Testing: Distinguish TCP Login from UDP Gameplay

The launcher, login, downloads, and gameplay may use different domains and protocols. If login works but joining a match fails, check gameplay UDP rather than relying on a browser speed test. TUN can route UDP connections into the core, but the selected node, transport protocol, server, and configuration must also support UDP forwarding.

1. Fully quit the game and launcher. With TUN enabled, relaunch them so new connections use the current routes.
2. In Connections, check the game’s TCP and UDP entries, destination addresses, and matched rules.
3. Check whether LAN, destination IP, or process rules route game traffic to DIRECT.
4. Compare with a node known to support UDP. A successful node latency test does not prove that the game’s UDP connection works.

TUN is not a dedicated game-acceleration route. Cross-region routing, node congestion, game server location, and anti-cheat compatibility can all affect performance; enabling TUN does not guarantee lower latency. Follow the relevant service rules in managed gaming or work environments.

Common Issues: Troubleshoot Permissions, Routes, DNS, and Policies in Order

WSL, Docker, and other VPNs do not behave like ordinary desktop apps

WSL 2, containers, and virtual machines may use their own virtual switches, NAT, or mirrored networking. A host app entering TUN does not mean a guest environment follows the same route. Test DNS, the default route, and connection logs separately inside each environment. A successful Windows browser test alone does not show what traffic is being captured.

If your network only stops working after connecting to a corporate VPN, check whether both are changing routes or DNS. Do not enable strict routing to forcefully override another network; it can affect access to your LAN and other interfaces. On a multi-adapter system, first identify the internal routes you need to preserve, then choose interface binding and bypass rules accordingly.

Recovery Steps When You Cannot Connect

1. Turn off TUN and wait for the interface and routes to revert, then test a regular direct connection.
2. If you are about to quit the client, turn off the system proxy too, so Windows does not keep pointing to 127.0.0.1:7890 after the listener has stopped.
3. Restore any DNS or override settings you changed, then restart the client core.
4. If the problem persists, save the logs and interface details, then restart Windows. Do not start by uninstalling all network adapters or resetting the entire network stack.

Post-Setup Checklist

A working TUN setup should meet all four conditions: the interface is created, apps reach the core, the right rules match, and everyday network access still works. Check each item below before setting the client to launch with Windows.

• Permissions: The background service is running, and the core logs show no repeated interface creation or permission errors.
• Traffic capture: With the system proxy off, you can still find test terminal requests on the client’s Connections page.
• Routing policy: Proxy-bound traffic matches the expected policy group, while direct destinations and LAN resources follow the intended routes.
• DNS: Common domains resolve correctly, and internal domains are not mistakenly sent to public resolvers.
• Protocols: Test UDP apps individually; do not use TCP download speeds as a substitute for game testing.
• Recovery: After turning off TUN and quitting the client, the system proxy and network access are in the expected state.

If only one app has problems later, check its connections and rules first instead of immediately replacing the whole configuration. For basic ports, subscriptions, and routing rules, see the Clash guide. To check configuration fields, consult the protocol reference.