Aug 21, 2026 Advanced Setup 12-minute read

Clash TUN Mode vs. System Proxy: Traffic Coverage and Use Cases

Learn how system proxies rely on app support while TUN captures IP traffic, and which option suits games, command-line tools, and UWP apps.

Choose how traffic enters first, then check your routing rules

For everyday browsing, start with the system proxy. Consider TUN when apps ignore proxy settings, you need UDP coverage, or you want to route multiple types of apps consistently. These options control how traffic reaches the core; they do not determine whether it ultimately connects directly or through a proxy node.

With the mihomo core, think of a connection in three stages: it enters through a proxy port or TUN interface, matches a rule, and then goes out directly or through a proxy node. The entry point, rules, and exit are separate. Changing only the entry point does not necessarily change which rule matches.

“Capturing all traffic” describes a common goal for TUN, not a guarantee under every condition. Route exclusions, other virtual interfaces, IPv6 settings, app-bound interfaces, and client implementation can all affect coverage. Connections to proxy nodes must also bypass TUN correctly to prevent routing loops.

System proxy: apps connect to a local proxy port

How the system proxy works

When you enable “System Proxy” in a client, it typically updates the operating system’s proxy settings to point to a local listening address, such as 127.0.0.1:7890. Apps that read these settings send requests to that address; apps that ignore them continue using their usual network path.

7890 is an example in this guide, not a default port for every client. Check the client’s settings for the “mixed port” or “HTTP port.” If a different value is shown, update it in commands and app proxy settings too. Do not confuse the controller port with the proxy port.

Browsers: Usually follow the system proxy, but a browser’s own proxy settings may override it.
Command-line tools: May not read the desktop system proxy. They might need a proxy option or environment variable instead.
Games and real-time communications: Native UDP traffic usually does not enter the core just because an HTTP system proxy is enabled.
Apps with their own networking stack: May bypass the system proxy, or proxy only the sign-in page while connecting directly for everything else.

Verify the port with an explicit proxy

The command below explicitly sends the request through a local HTTP proxy. In Windows Terminal, use curl.exe to avoid ambiguity with other commands named curl; on most other systems, use curl.

curl --head --proxy http://127.0.0.1:7890 https://clash67.com/

After running it, check the client’s connection log. A target domain and matched rule should appear there if the request actually reached the core. The HTTP status only reflects that site’s response at the time; it does not prove that every site is reachable. This test also does not confirm that the system proxy setting was written correctly, since the command specifies a proxy explicitly.

TUN mode: capture connections through a virtual interface and routes

TUN is a Layer 3 virtual network interface. After the client creates the interface and configures routes, IP packets matching those routes enter the core for processing. Apps do not need to understand HTTP or SOCKS proxies, making TUN useful for programs that ignore system proxy settings.

This kind of traffic capture usually requires elevated system permissions. Desktop clients may configure interfaces and routes through a background service or elevated process; Android clients often use system VPN permission to capture traffic from selected apps. Implementations and toggle names vary by platform, so do not copy desktop settings blindly to a phone.

mihomo TUN configuration example

This snippet shows common entry-point settings; it does not include nodes, policy groups, or a complete DNS configuration. Merge it into your active configuration rather than replacing the entire subscription. If tun or another top-level key with the same name already exists, edit the existing fields to avoid duplicate definitions.

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

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

mixed-port: Accepts HTTP and SOCKS proxy connections on the same port. You can keep this entry point when TUN is enabled.
allow-lan: false: Keeps the proxy service unavailable to your local network. You do not need to enable LAN access just to use TUN on this device.
stack: mixed: Selects a mixed protocol stack supported by mihomo; it does not mean “enable the system proxy too.” Check the core bundled with your client for actual support.
auto-route: Lets the core configure the relevant routes automatically. Creating a virtual interface without the right routes may still leave traffic uncaptured.
auto-detect-interface: Automatically detects the outbound interface. On devices with multiple network adapters, check the logs and selected exit interface.
dns-hijack: Captures matching traditional DNS requests, including UDP 53 and TCP 53. It does not decrypt encrypted DNS used inside apps.

System proxy vs. TUN: use-case comparison

Use case	Recommended starting point	What to check
Browsing the web	System proxy	Whether the browser follows system settings and has its own proxy configuration
One-off command-line request	Explicit proxy option	Options supported by the tool, the actual port, and environment variables
Multiple tools that ignore proxy settings	TUN	Whether routes are active and the process or domain rule matches
Games that use UDP	TUN	Whether the node and server support UDP, and whether the traffic is mistakenly routed direct
UWP apps	Test the system proxy first, then consider TUN	The app’s networking stack, loopback restrictions, and system policies
Corporate network used alongside other tunnels	Start with the system proxy	Corporate routes, private DNS, and priority among other virtual interfaces

Games: capturing UDP does not mean the node supports UDP

TUN can route game traffic into the core, but the exit still needs to support the relevant transport. If the node or server does not support UDP, switching to TUN cannot add that capability. Find the game connection in the connections panel and check its network type, destination, matched rule, and selected node. Then determine whether the problem is at the entry or the exit.

A game launcher, sign-in service, and in-game session may use different domains and addresses. A successful sign-in does not prove that game traffic is proxied. Do not conclude that TUN is faster based on a single latency test either; latency also depends on the network path, node load, and the destination server’s location.

Command line: configure individual tools explicitly

When only one tool needs proxy access, an explicit setting is usually easier to troubleshoot and leaves other apps’ network paths unchanged. Whether HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY work depends on the tool. The HTTPS in a variable name does not mean its value must use the HTTPS proxy protocol.

UWP: distinguish proxy limitations from sandbox loopback restrictions

Some UWP apps may be affected by loopback restrictions when connecting to a local proxy. This is separate from whether the node is working. If an app cannot connect through the system proxy, first use a browser to confirm the local port works. Then check whether the app needs loopback access enabled, or test with TUN. Do not grant loopback access to every app just to troubleshoot one.

DNS and Fake-IP: what to check when TUN connects but domains do not load

TUN captures connections; DNS resolves domain names to addresses they can connect to. Both paths need to work together. Common symptoms include a browser that hangs after TUN is enabled, resolution timeouts in the logs, or different results for the same domain across apps. Switching nodes again may not fix a DNS issue at the entry point.

Confirm DNS is enabled: Check dns.enable in the active configuration and whether the client generates DNS settings from its own options.
Check capture on port 53: Traditional DNS usually uses UDP 53 and may also use TCP 53. Checking only one is not enough.
Identify encrypted DNS in apps: DNS requests sent over HTTPS or TLS will not simply match port 53 hijack settings.
Check that DNS upstreams are reachable: Make sure the upstream DNS server can be reached, and that it does not depend on a proxy connection that has not yet been established, creating a dependency loop.

Fake-IP returns synthetic addresses for matching domains, while the core keeps a mapping between each domain and its address. A common example address pool is 198.18.0.1/16. Seeing an address from this range is not necessarily an error, but related connections must return to the core as expected for it to resolve the destination correctly.

After TUN is disabled, apps that have cached synthetic addresses may temporarily be unable to connect. Reconnect the app first, then clear the DNS cache using your operating system’s method. On Windows, run ipconfig /flushdns in a terminal. A browser’s own DNS cache may need to be cleared separately. For local network discovery, device management, or specific internal domains, check Fake-IP filtering and direct-resolution rules for your use case instead of filtering every domain.

Verify in four steps: entry, rule, exit, and recovery

Start with a working baseline.
Turn off TUN, confirm the subscription is enabled, select a working node, and test the local port with an explicit proxy command. In the client’s connections panel, note the destination domain, matched rule, and policy group. If the baseline does not work, troubleshoot the subscription, port, or node first; do not add TUN to the mix.
Test TUN capture on its own.
Enable any required service or system permission, turn on TUN, and temporarily disable the system proxy. Make sure the test tool has not inherited proxy environment variables. Run curl --head --noproxy "*" https://clash67.com/ and check the connection log. Here, --noproxy "*" only tells curl not to use an explicit proxy; it does not bypass the operating system’s TUN routes.
Check the rule and exit.
Find the request you just made and check whether it matched the expected rule and whether it went direct or through a proxy node. A page loading only proves the connection succeeded. If the destination was reachable directly, the page alone cannot confirm that proxy routing worked.
Test recovery and special network paths.
Turn off TUN and reconnect to confirm that normal networking returns. Then test local network devices, corporate network access, IPv6 destinations, and game traffic over UDP. Change one setting at a time and record what changed; otherwise, simultaneous DNS, routing, and policy group changes make it hard to identify the cause.

FAQ: running both modes, lost connections, and LAN access

Can I enable the system proxy and TUN at the same time?

Yes. Many clients allow both entry points to run at once. But having both enabled makes troubleshooting harder: one app may enter through the proxy port while another enters through TUN. When setting things up, test each mode separately before deciding whether to keep both. Running both does not automatically improve speed or replace correct exit routing.

Everything loses internet access after enabling TUN. What should I turn off first?

Turn off TUN first and check whether normal networking returns. If it does, check service permissions, the default exit, DNS, and conflicts with other tunnels in that order. Restart the client and check whether it creates a virtual interface and adds routes without errors. Do not start by disabling the system firewall; use the logs to identify which programs or connections need to be allowed.

Does TUN also proxy traffic to local network devices?

Not necessarily. Whether local network connections enter TUN, and whether they go direct afterward, depends on routes and rules. Test with the device’s actual address, such as 192.168.1.1, and check which rule matches. If the connection should go direct, verify both route exclusions and rules so local admin pages are not accidentally sent through a remote node.

If TUN is enabled on my computer, will my phone use the proxy too?

No. TUN on your computer does not automatically turn it into a gateway for your local network. Your phone needs its own proxy settings or a properly configured gateway. Connecting the phone to the computer’s proxy port also involves the listening address, LAN permissions, and firewall rules—separate from TUN on the computer itself.

What if IPv4 works but some apps still bypass the proxy?

Check whether those connections use IPv6, and review the client’s IPv6 settings, DNS responses, and TUN routes. Testing IPv4 alone does not confirm that both address families are captured. Also check whether the app is bound to a specific network interface or excluded by the client’s app bypass settings.

Base your choice on connection logs you can verify. Keep the system proxy if it meets your needs; use TUN for broader app coverage, then check permissions, routes, DNS, and UDP support at the exit. For core and rule fields, see the mihomo core guide in our protocol reference.