Clash TUN Mode vs. System Proxy: How Traffic Routing Works

The key difference: Apps connect to a proxy, or the OS routes traffic through a virtual adapter

A system proxy depends on app support; TUN relies on OS routing. That’s the starting point for understanding how much traffic each can cover. A system proxy typically adds a local HTTP proxy address to the OS network settings. Apps that honor this setting connect to Clash’s local listening port, where the core applies its rules. Programs that ignore system settings, use their own proxy configuration, or open network connections directly may bypass this route.

TUN creates a layer 3 virtual network interface that sends IP packets matching its routing conditions to the core for processing. Apps don’t need to know the local proxy address, so TUN can cover more software that connects directly to the network. But enabling TUN doesn’t mean all traffic goes through a remote node: route exclusions, other VPNs, interface priority, and proxy rules can all affect the final path.

What the client, core, and subscription each do

• Client: Provides the system proxy toggle, service management, configuration editing, and connection list. Menu names and permission requirements vary by project.
• Core: Handles protocols, DNS, rule matching, and the TUN network stack. Clash, Clash Premium, and Clash Meta (later named mihomo) don’t all have the same capabilities.
• Subscription: Provides nodes or a complete configuration. It can affect policy groups, rules, and DNS, but it can’t grant the virtual network adapter permissions required by the OS.

The configuration fields in this article use mihomo as an example. First, check the core information in the client or its startup logs to confirm which core is running, then verify that it supports the fields you need. Don’t infer TUN support from the app’s name alone.

System proxy: works well for browsers, but verify command-line tools separately

In Windows 11, check the system proxy address under Settings → Network & internet → Proxy → Manual proxy setup. If the client’s HTTP or mixed listener uses port 7890, the address is usually 127.0.0.1 and the port is 7890. These values are examples; use the port in the active configuration.

Browsers usually use the system proxy, but extensions, separate proxy settings, and bypass lists can change that. The user proxy settings in Windows and WinHTTP configuration are separate mechanisms. A browser connecting successfully doesn’t prove that background services or every desktop app uses the same proxy.

Use curl to tell “the node works” from “the system proxy is being used”

These two commands are for Windows Terminal. The first explicitly specifies an HTTP proxy; the second sends a request directly. Whether the second uses a proxy depends on settings such as environment variables, so don’t assume it’s a direct-connection test.

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com
curl.exe --connect-timeout 10 -I https://example.com

• If the explicit proxy request works but the regular request fails, check terminal environment variables and the app’s proxy support before switching nodes.
• If you see a connection error for 127.0.0.1:7890, check the listening port, core status, and local firewall.
• If the local proxy connects but the TLS handshake or remote connection then fails, check the node handshake, DNS, and rule-matching logs.

On macOS or Linux, you can set an environment variable for a single command, for example HTTPS_PROXY=http://127.0.0.1:7890 curl -I https://example.com. The variable specifies a proxy for HTTPS requests; the proxy address can still use the HTTP protocol. This doesn’t mean the local listener needs to support TLS. Tools vary in their support for uppercase and lowercase variable names and for SOCKS, so check each tool’s documentation.

TUN mode: covers more connections, but needs permissions and routing

TUN receives IP packets, and the core processes TCP, UDP, and other traffic through its network stack before making outbound connections according to the configuration. Games and command-line tools don’t need to connect to an HTTP proxy themselves, making TUN useful when an app has no proxy settings. The client typically needs administrator privileges, service mode, or the appropriate OS permissions to create the interface, adjust routes, and handle DNS.

Minimal mihomo field example

This is a configuration snippet, not a complete subscription. It assumes that the nodes, policy groups, rules, and DNS module are already configured correctly. A client may generate the final configuration through overrides, so check the effective configuration instead of editing a source file that a subscription update may overwrite.

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

• enable: Enables TUN. If interface creation fails, check permissions and service logs first.
• stack: Selects the network stack implementation. mixed is an option in mihomo and shouldn’t be assumed to work in every older core.
• auto-route: Automatically sets routes needed to capture traffic; it doesn’t mean every interface and exceptional route is covered.
• auto-detect-interface: Helps select the outbound interface. You may still need to check manually when multiple VPNs are running.
• dns-hijack: Sends matching DNS requests to the core’s DNS module. The example matches UDP port 53; it doesn’t cover all encrypted DNS traffic.

Compare scenarios: command-line tools, games, and UWP apps

Gaming: check UDP first, then compare latency

Game downloads usually use TCP/HTTPS, but gameplay may use UDP. A successful launcher download doesn’t prove that gameplay traffic is being captured. Check the connection list for process, destination address, network type, and matched rule, then confirm that the selected node in the policy group supports UDP. Some games are also affected by NAT, region-based matchmaking, and anti-cheat policies; TUN can’t guarantee improvements in these areas.

A single HTTP latency test in the node list doesn’t represent game latency. On the same server and around the same time, record in-game latency and packet loss for five minutes on a direct connection and again through the proxy. For example, “80 ms for a website probe and 140 ms in a match” compares two different measurements and doesn’t indicate a configuration error. Compare changes in the same metric instead.

UWP apps: distinguish loopback restrictions from network issues

Some apps isolated in an AppContainer can’t access a local loopback proxy directly and need a per-app loopback exemption. Don’t enable exemptions for every app when troubleshooting; first confirm that the target app is affected, then use the client’s tool or the relevant Windows management method. TUN may keep an app from connecting directly to a local HTTP proxy, but it can’t guarantee a fix for sign-in services, certificates, app-specific DNS, or remote region restrictions.

DNS and Fake-IP: the TUN toggle doesn’t prove there are no DNS leaks

DNS resolves domain names and affects whether the core can match domain-based rules. In Fake-IP mode, DNS returns a virtual address for a domain, and the mapping is used later to recover the domain for the connection. Fake-IP isn’t a remote node or an encryption protocol. Fake-IP and TUN are often used together, but they’re separate features.

With a system proxy, HTTP CONNECT requests can usually pass the destination domain to the proxy, but an app may still resolve it on its own or use a separate DNS service. With TUN, routes and DNS hijacking can send traditional DNS requests to the core. Browser-based DoH, Android Private DNS, and other encrypted DNS paths won’t all follow the same resolution policy just because any:53 is configured.

1. Confirm that the DNS module is enabled in the client’s effective configuration, then check enhanced-mode and the upstream DNS settings.
2. Check the OS resolver, browser Secure DNS, and other VPNs to establish which service handles each request.
3. After changing modes, reconnect the app and clear the DNS cache if needed so stale results don’t affect your diagnosis.
4. Use DNS and connection logs to verify the route; don’t rely only on the resolver location reported by a test website.

A test page showing a local ISP resolver is a reason to investigate further, not a complete diagnosis. Split-routing configurations may intentionally use local DNS for domains that connect directly. The key question is whether domains expected to use a specific route are actually resolving outside it.

Test in order: change one traffic-capture setting at a time

When troubleshooting, avoid changing TUN, the system proxy, DNS mode, and the node all at once. Too many variables make it hard to tell what restored connectivity. Start with a known-working node, then check the following in order.

1. Test the local proxy: Turn off TUN and use an explicit proxy option to reach a test address. Confirm that the current core is listening on the example port 7890.
2. Test the system proxy: Turn on the system proxy, open a new browser connection, and check the connection list for the destination domain and matched rule.
3. Test TUN on its own: Temporarily turn off the system proxy and any app-specific proxy settings, enable TUN, and restart the target app so it doesn’t reuse an existing connection.
4. Check outbound routing: Review the matched rule, policy group, and final node. Seeing a connection enter the core doesn’t prove it went through a remote proxy.
5. Check the result that matters: Test websites in a browser, actual gameplay in a game, and the target repository or API in a terminal. Don’t use a single speed test as a substitute for testing every use case.

No internet after enabling TUN

Turn off TUN first and check whether the basic network connection returns. Then check, in order, whether the interface was created, service permissions are working, another VPN has taken over the default route, and DNS is reachable. If logs show repeated connection retries, also check whether the node server’s address resolves and whether its outbound connection is looping back. Don’t keep adding routes to mask an interface selection problem.

LAN printer or company network is unreachable

Note the actual LAN subnet, for example 192.168.10.0/24, then check direct-connection rules and route exclusions. DIRECT in proxy rules means a connection goes directly out after entering the core; a route exclusion may keep packets from entering TUN at all. These are different layers. An enterprise VPN may also require dedicated DNS, so adding a single IP rule isn’t enough to consider the issue resolved.

Choosing a setup: add complexity only when you need broader coverage

• Mostly browsing websites: Start with the system proxy and check browser connection logs to confirm it’s working.
• Only a few developer tools: Set an explicit HTTP or SOCKS proxy in each tool. This keeps the scope clear and makes the setup easier to reproduce.
• Several apps ignore the system proxy: Consider TUN, and pay close attention to permissions, DNS, UDP, and LAN access.
• Running an enterprise VPN too: Check your organization’s network requirements first, then test whether routing and DNS can coexist. Don’t assume two virtual networks can simply be stacked.

Once stable, you can use the system proxy and TUN together if the client supports it, but test them separately while troubleshooting. Enabling both doesn’t necessarily proxy traffic twice or provide broader coverage: some apps may connect directly to the local proxy while other connections use the virtual adapter. A clear, verifiable traffic route matters more than turning on more toggles.