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

Choose how to route traffic, then check your rules

A browser loads websites, but terminal commands time out. A game still uses its usual connection even after you enable the system proxy. These symptoms don’t necessarily mean your proxy node is down. Often, the app simply isn’t using the system proxy settings. The key difference between a system proxy and TUN is how traffic reaches the Clash core—not node speed or subscription quality.

Mostly use a browser: Start with the system proxy. It’s simple to set up and easy to turn off if something goes wrong.
Need a proxy for just one command-line task: Pass an HTTP or SOCKS proxy explicitly to the command. You don’t need to enable TUN right away.
An app has no proxy settings, or you need to route some UDP traffic: Consider TUN, then check routing, DNS, and node protocol support.
Connected to a company VPN: Check your organization’s network requirements first. Avoid letting two tools modify the default route at the same time.

System proxy: apps connect to a local proxy port

A system proxy sets a local proxy address in the operating system’s settings. Apps that honor these settings read the address and send their requests to the client. For example, if the client listens on 127.0.0.1:7890, a browser can use that local port to connect through the proxy. Check the port shown by your client; 7890 is only an example.

Which connections can a system proxy handle?

Browsers such as Edge and Chrome usually follow the system proxy, but organization policies, extensions, and launch options can change their behavior. Firefox can use the system proxy or have its own connection settings. Download managers, developer tools, and games all handle proxies differently. Seeing “system proxy enabled” in the taskbar doesn’t mean every app is using it.

HTTP proxies are commonly used for web requests. HTTPS usually uses HTTP CONNECT to establish a tunnel; this doesn’t mean the client decrypts HTTPS traffic.
SOCKS5 can handle TCP. UDP support also depends on the app, client, and proxy node.
mixed-port accepts both HTTP and SOCKS proxy requests on the same port, but it won’t reroute apps that ignore proxy settings.

Check the address in system settings

In Windows 11, go to Settings → Network & internet → Proxy to check your manual proxy or setup script. On macOS, go to System Settings → Network → your current network service → Details → Proxies. These menus let you verify system settings; use the client for everyday toggling to avoid settings overwriting each other.

Don’t enter 0.0.0.0 as an app’s proxy server address. It’s commonly used to listen on all IPv4 interfaces; apps on the same computer should usually connect to 127.0.0.1. For LAN sharing, configure the listening address, firewall, and access controls separately.

TUN mode: route IP traffic through a virtual network interface

TUN creates or uses a virtual network interface, then uses routing and related mechanisms to send matching IP packets to the core. Apps don’t need HTTP proxy settings, making TUN useful for programs that can’t be configured to use a proxy manually. The mihomo core, which evolved from Clash Meta, supports this functionality, but clients differ in their core versions, service setup, and interface controls.

Turning on TUN doesn’t guarantee that all network traffic is captured. Actual coverage depends on IPv4 and IPv6 routes, excluded interfaces, LAN bypass settings, other VPNs, and the system firewall. Virtual machines, containers, and WSL also use additional network paths, so their traffic doesn’t necessarily behave like traffic from apps running on the host.

Comparison	System proxy	TUN mode
Traffic entry point	Apps connect to a proxy listening port	A virtual interface and routes capture IP traffic
App requirements	Uses system settings or requires separate proxy configuration	Usually doesn’t require apps to support a proxy protocol
UDP handling	A standard HTTP system proxy doesn’t handle general UDP traffic	Can handle captured UDP traffic, provided the node supports it
Permissions and services	Usually doesn’t require creating a virtual interface	Usually requires elevated permissions or a preinstalled privileged service
What to check when troubleshooting	Address, port, and whether the app uses the settings	Routes, DNS, service permissions, and interface conflicts

Why does TUN often need administrator permissions?

Creating an interface and changing routes are system-level network operations. Windows clients may use a service; macOS may require an authorized helper app. On Linux, this typically involves /dev/net/tun and the necessary network permissions. Once a privileged service is installed, you may not need to run the graphical client as an administrator every time.

If the logs report insufficient permissions, follow your client’s instructions to install or repair its service instead of repeatedly toggling TUN. Don’t leave the system firewall disabled as a troubleshooting measure. Check the service status first, then identify the specific blocked app or rule.

Command-line tools and games: test the app instead of guessing from a toggle

If command-line requests fail, test with an explicit proxy first

Command-line tools don’t necessarily use the operating system’s proxy settings. Some recognize HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY, but support and case handling vary. Passing a proxy explicitly usually makes it easier to see what’s affected than changing global environment variables.

# Windows PowerShell: use curl.exe to avoid the legacy alias
curl.exe --proxy http://127.0.0.1:7890 --noproxy "" -I https://example.com

# Use curl on macOS / Linux
curl --proxy http://127.0.0.1:7890 --noproxy "" -I https://example.com

# Use SOCKS5 and let the proxy resolve the destination hostname
curl --proxy socks5h://127.0.0.1:7890 --noproxy "" -I https://example.com

These commands assume port 7890 is a mixed port that supports the relevant protocols. An HTTP response means the proxy request connected successfully, but the status code alone can’t tell you which public IP address was used. If an explicit proxy works but a regular command doesn’t, check that tool’s proxy options or environment variables before changing subscriptions.

Games use UDP, and TUN doesn’t guarantee lower latency

A game may use TCP for login, UDP for matches, and a separate connection for voice chat. With TUN enabled, only connections captured by routing and supported by the node can use the proxy. Node protocol, server configuration, rule matching, and regional restrictions can all affect the outcome.

Look for the game process or destination address in the client’s connection list to confirm the connection reaches the core.
Check the matched rule and proxy group. A login connection might use the proxy while gameplay unexpectedly matches a direct rule.
Check that the node supports UDP forwarding; a successful browser speed test isn’t enough.
Compare direct and proxied connections to the same server at the same time of day. Note in-game latency, packet loss, and disconnections.

A node with a longer route can increase latency. TUN expands which traffic can be captured; it doesn’t automatically speed up games. Check the game’s terms of service and anti-cheat restrictions separately.

DNS handling: distinguish proxy-side DNS from system DNS

Another key difference between a system proxy and TUN is where DNS queries go. When using an HTTP proxy to visit an HTTPS site, an app can send the destination hostname to the proxy for resolution. But an app’s own pre-resolution, background connections, and secure DNS features may take different routes. So, a website loading through the proxy doesn’t prove that all DNS queries use the same route.

TUN can work with DNS interception to send matching queries on port 53 to the core’s DNS module. In mihomo, dns-hijack is commonly used for this. It can’t decrypt arbitrary encrypted DNS: an app’s DoH uses HTTPS, while DoT typically uses port 853. Don’t expect a setting for port 53 to detect and rewrite those protocols automatically.

How to read a mihomo configuration snippet

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

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

This partial snippet explains individual fields; it isn’t a complete, runnable configuration. auto-route sets up relevant routes automatically, while auto-detect-interface detects the outbound interface. The port 1053 in listen is a local DNS listening port, not a node port. DNS interception and this listening port are separate concepts.

Fake-IP mode assigns a mapped address to a domain, then uses that mapping to handle later connections. 198.18.0.1/16 is the address pool used here, not the address of a real web server. Your existing configuration also needs suitable upstream DNS settings. Don’t paste this snippet over your subscription file, and don’t add a second dns or tun key at the same level.

Enable in stages: establish a baseline before adding TUN

Enabling both the system proxy and TUN isn’t necessarily a conflict, but it doesn’t mean you’ll get twice the effect. HTTP proxy connections and virtual-interface routing can coexist, and the client needs to handle its own traffic and route exclusions correctly. For easier troubleshooting, use one traffic entry point at a time so you can pinpoint the layer causing the problem.

Check the node and configuration: Import your subscription, select a node, choose Rule mode, and load a web page through the system proxy.
Note the local port: Check the HTTP, SOCKS, or mixed port in the client. Don’t mistake the controller API port for a proxy port.
Set up service permissions: Install the service or grant permission as instructed by the client, and close other tools that are routing network traffic.
Test TUN on its own: Temporarily turn off the system proxy, enable TUN, restart the target app, and check the connection list and logs.
Check everyday services: Test websites, command-line tools, LAN devices, and company intranet sites. Make sure your rules don’t accidentally route addresses that should connect directly.

Android clients typically use the system VPN interface to capture traffic, and usually only one VPN service per user can be active at a time. This is different from setting an HTTP system proxy on a computer. iOS uses its own Network Extension mechanism, so desktop YAML fields and toggle locations don’t directly apply to mobile.

If TUN leaves you offline, narrow down the cause by symptom

The system proxy works, but TUN doesn’t

Check whether the service is running and whether the logs show errors creating an interface, setting routes, or granting permissions.
Check whether other VPNs, virtual network adapters, or security software are also changing routes. Disable one at a time and test again.
Check IPv6 capture settings. A successful IPv4 request doesn’t mean every connection follows the same route.

Some websites work, but some apps report a domain name error

Check whether the DNS module is enabled, whether its upstream server is reachable, and whether the app uses its own DoH settings.
Check Fake-IP filters and direct rules, especially for LAN domains, company intranet domains, and services that rely on real IP addresses.
Check the connection logs to see whether the issue is a DNS lookup failure, a mismatched rule, or a failed node connection. Not every timeout is caused by DNS.

You still can’t connect after closing the client

Turn off TUN and the system proxy normally before closing the client. If it crashes, check whether the system proxy still points to 127.0.0.1:7890 after the listener has stopped, and whether your previous VPN or network service has been restored. Save your work before restarting network services or the system. Don’t delete routes in bulk without recording the original settings.

If you still can’t pinpoint the issue, see internet connection troubleshooting and configuration file checks. Before sharing logs, remove subscription links, node passwords, and access tokens. Keep the error time, core details, error lines, and steps to reproduce.