Clash TUN Mode vs. System Proxy: How They Work and When to Use Each

First, separate traffic capture from proxy mode

System proxy and TUN determine how app traffic enters the Clash core. Rule, Global, and Direct modes determine how traffic is routed after it enters the core. These settings operate at different layers. With TUN enabled, you can still use Rule mode: traffic to sites in mainland China can match DIRECT, while other destinations follow their policy groups. Enabling Global mode does not automatically route games that ignore proxy settings through the core.

The configuration examples here target mihomo, the successor to Clash Meta. Clash is commonly used as an umbrella term for the core and its client ecosystem, but available features depend on the actual core and operating system. Legacy Clash configuration fields for TUN should not be assumed to be fully compatible with modern mihomo. Check the core name in your client, then consult the documentation for that version.

System proxy: apps connect to a local proxy port

When you enable the system proxy, the client typically sets a local proxy address in the operating system, such as 127.0.0.1:7890. A browser that honors this setting connects to that port first; the core then chooses a direct or proxied route. HTTPS traffic is usually tunneled with HTTP CONNECT. A system proxy does not decrypt HTTPS traffic, and ordinary proxy forwarding does not require installing a certificate.

Coverage depends on the app

• Browsers: Many browsers use the system proxy by default, but extensions, enterprise policies, or browser-specific settings can override it.
• Command-line tools: Whether curl, Git, or a package manager uses system proxy settings depends on the tool and how it was built. Explicit options or environment variables make behavior easier to verify.
• Games and voice apps: Many communicate directly over sockets and ignore the system HTTP proxy. Enabling the system proxy alone often does not change their UDP traffic path.

mixed-port is a listening port that accepts both HTTP and SOCKS proxy connections. This configuration lets apps on the same device reach the core through port 7890. It does not automatically set the system proxy or allow other devices to connect to that port.

mixed-port: 7890
allow-lan: false
mode: rule

The main advantage of a system proxy is its limited scope: you don't need to create a virtual network adapter for ordinary web browsing, and disabling it usually just means restoring the system proxy settings. Its limitation is just as clear: if an app doesn't use this entry point, the core won't see its connections.

TUN: capture connections through a virtual network adapter and routes

TUN creates a layer 3 virtual network interface that receives IP packets routed to it by the operating system. The core processes this traffic and then establishes connections according to its rules. This can capture traffic from apps that have no proxy options. Rather than teaching every app to use an HTTP proxy, TUN changes the traffic path at a lower network layer.

On desktop systems, creating a virtual network adapter and changing routes typically requires administrator privileges, a privileged service, or specific system capabilities. Android clients usually capture traffic through the system VPN interface; in the same user profile, two such VPNs generally can't run at once. Exact behavior depends on the platform and client implementation.

Example mihomo TUN fields

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

• stack: mixed selects a mixed-stack implementation supported by mihomo. Don't assume from its name alone that it will be faster than other stacks.
• auto-route requests automatic route configuration for traffic capture. auto-detect-interface automatically detects the outbound interface; support and behavior vary by platform.
• dns-hijack sends matching traditional DNS requests to the core's DNS handler. The DNS module must also be enabled and configured correctly; this example does not cover every encrypted DNS path.

System proxy vs. TUN: at a glance

Neither option increases your node's bandwidth. TUN adds packet-processing overhead, which varies with the network stack, operating system, and number of connections. If your browser already uses the proxy correctly, switching to TUN alone won't automatically double download speeds or guarantee lower latency.

Choosing for games, terminals, and UWP apps

Web browsing and regular downloads: start with the system proxy

If you mainly need a browser and download tools with explicit proxy settings, the system proxy is usually enough. First confirm that browser requests appear in the connections panel, then check the matched rule and actual route. If a site won't load, check the node, DNS, and rules before adding TUN as another variable.

Terminal tools: configure a few tools explicitly

In Windows PowerShell, use curl.exe to avoid differences caused by the curl alias in some environments. These commands test an HTTP proxy and a SOCKS5 proxy, respectively. The second command resolves the destination hostname through the proxy. Make sure the port matches the client's actual listening port.

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

If only Git or a package manager needs a proxy, configure it in that tool. Consider TUN if you need consistent traffic capture across many command-line programs, child processes, and development tools. Environment variables affect only processes that read them, and you may need to restart the terminal for changes to take effect.

Games and voice apps: check UDP and server region first

TUN can capture games that don't offer proxy settings, but capturing their traffic and making the game connection work are two separate steps. The node protocol, node configuration, and server must all support the required UDP forwarding. Check which server region the game actually connects to and which policy it matches; avoid routing a nearby server through a distant exit when a direct connection would work. A latency test showing 50 ms does not mean the round trip to the game server will also be 50 ms. This is an example of what the number means, not a measured result.

UWP apps: distinguish proxy settings from loopback restrictions

Some UWP/AppContainer apps on Windows are restricted from accessing local loopback addresses. Even when the system proxy points to 127.0.0.1:7890, an app may not be able to use it. TUN avoids relying on the app to connect to a local HTTP proxy, but loopback restrictions are not the cause of every UWP networking issue. If your client offers a loopback exemption tool, use it only for apps that need it and are supported. Don't treat bulk exemptions as a default step.

Verify TUN and troubleshoot after enabling it

First establish that the system proxy works, then test TUN on its own. Enabling both doesn't necessarily create a loop, but it makes it harder to identify how requests enter the core. Terminals with explicitly configured proxy environment variables may keep using the local port even after you turn off the system proxy.

1. Check the underlying connection. Temporarily disable both capture methods and confirm that your local network, gateway, and direct-access sites work. This rules out basic connectivity issues.
2. Test the system proxy. Enable it and use an explicit --proxy request to check that port 7890 is listening and that the node and rules work.
3. Test TUN by itself. Turn off the system proxy, clear any app-specific proxy settings in the test program, and enable TUN. Start a new connection from a program without explicit proxy options.
4. Confirm that traffic is being captured. Find the destination in the connections panel or logs and check its rule, policy group, and route. On Windows, use Get-NetAdapter to inspect interfaces and route print to inspect routes. Don't rely on the tray icon alone.
5. Check DNS and IPv6. If domain names fail while existing connections still work, inspect the DNS logs. If IPv4 works but some apps still bypass the proxy, check whether IPv6 routes and settings are covered too.

Connections appear, but access still fails

This means at least some requests reached the core. Check whether they matched REJECT, selected an unavailable node, or were refused by the server. If UDP games fail while HTTPS works, check UDP support first; a successful HTTP test doesn't prove that every protocol works.

No matching connections appear

First confirm that the client panel is connected to the running core. Then check TUN service permissions, whether automatic routing took effect, whether the app is bound to a physical network adapter, and whether another VPN has taken over the default route. On Windows 11, check for leftover system proxy settings under Settings → Network & internet → Proxy. Labels may differ in other versions.

Choosing between them: match the method to the apps

• Browser access only: Start with the system proxy, keep Rule mode, and confirm the local port and active policy group.
• A few terminal tools: Prefer explicit proxy options or each tool's own settings so you can verify and undo them individually.
• Games, voice apps, or apps without proxy support: Consider TUN and check UDP, DNS, IPv6, and route coverage.
• Existing enterprise VPN or complex virtual network: Assess route conflicts first. The system proxy is usually easier to keep within a limited scope.

Choose based on how your apps connect, not on which setting seems more “global.” Stick to one verified working method, change one setting at a time, and check connection logs and matched rules to confirm the result. This usually makes troubleshooting easier than enabling every option at once. For your first setup, start with the Getting Started Guide. To learn about rules and configuration structure, see From Beginner to Advanced.