TUN vs. System Proxy: Traffic Coverage and Trade-Offs

1. Traffic Capture vs. Proxy Routing

System proxy and TUN solve the same first step: getting app connections into the Clash core. Once there, rules, policy groups, and proxies determine whether traffic goes direct, through a proxy, or is blocked. Enabling TUN does not mean all traffic is proxied, and using a system proxy does not limit you to rule-based routing.

This guide uses the Clash Meta (mihomo) core for its TUN examples. Client apps differ in their controls, service installation methods, and default ports; older Clash clients may not support every setting shown below. Before making changes, check the client’s core information to confirm that it is running mihomo—don’t rely on the app name alone.

Three Common Traffic Paths

• System proxy: The browser reads the system proxy settings and sends connections to a local HTTP proxy port, where the core applies routing rules.
• TUN: Apps make IP connections as usual. The operating system routes eligible packets through a virtual network interface for the core to process.
• In-app proxy: Enter a SOCKS5 or HTTP address directly in Git, a command-line tool, or a chat app. This is a separate way in and does not depend on the system proxy setting.

2. Coverage: Browsers, Command-Line Tools, and UDP

A system proxy is a set of settings that apps can read, not a network-layer interceptor. Support varies across Windows networking APIs, app-specific network libraries, and macOS apps. A working browser connection proves only that the browser is using the proxy—not that every app on the device is covered.

UDP support depends on the entire connection path

An HTTP proxy port is not a general-purpose UDP tunnel. SOCKS5 defines UDP relay, but support depends on whether the app implements it, the client accepts it, and the exit node supports it. TUN can send more UDP traffic to the core, but it cannot make a node that lacks UDP support handle UDP.

For example, HTTP/3 commonly uses UDP on port 443. A website loading over TCP does not prove that its QUIC connection works. If a game login succeeds but voice chat fails, check the destination address, protocol, and policy for each connection separately; a single latency test is not enough.

3. Permissions and Setup: Proxy Ports vs. Virtual Interfaces

System Proxy: Check the Local Listening Address

This example uses 127.0.0.1:7890 as an explicit local proxy address; it is not a default shared by every client. mihomo’s mixed-port accepts both HTTP and SOCKS requests on the same port. Use the mixed port shown in your client or in the active configuration.

# mihomo config snippet: local mixed proxy listener
mixed-port: 7890
allow-lan: false
mode: rule

In Windows 11, check Settings → Network & internet → Proxy → Manual proxy setup. A client may also configure the system proxy through an automatic configuration script, so don’t check only the manual proxy section. On macOS, go to System Settings → Network → select the active network service → Details → Proxies. The address and port shown must match the client’s listening port.

For local use, keep the listening address on loopback. Don’t change it to listen on all interfaces just because a browser cannot connect. Making a proxy available to your LAN is a separate configuration task that also requires access controls and firewall rules.

TUN: Routing and Background Service Permissions

TUN creates a virtual network interface and changes routes, so desktop clients usually need administrator privileges or a privileged service. Windows clients may require service mode to be installed first; macOS clients may use a privileged helper or a network extension, depending on the implementation. Not every Clash client for macOS requests the same network extension permissions.

# mihomo TUN config snippet; not a complete subscription
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

• stack: mixed combines the system TCP stack with the gVisor UDP stack in the current mihomo implementation. Check supported values and compatibility against the version of the core you use.
• auto-route: true sets the relevant routes automatically. Creating the interface does not guarantee that route installation succeeded.
• auto-detect-interface: true detects the outbound interface automatically. If Wi-Fi, Ethernet, and other VPNs are active at the same time, check which interface is actually used.
• dns-hijack is a field under tun. The example matches DNS requests on port 53 over UDP and TCP, then passes them to the built-in DNS module.

4. DNS and IPv6: Why TUN May Still Miss Traffic

Check traffic capture and DNS resolution together. Apps resolve a domain before connecting; if DNS queries take a different path, resolution may fail, rules may lack domain information, or the connection may go to an unexpected address. Seeing a virtual interface does not prove that DNS is configured correctly.

Port 53 Hijacking Does Not Cover All DNS

The dns-hijack example above applies to traditional DNS. Browser DNS over HTTPS uses HTTPS connections, while DNS over TLS usually uses TCP port 853; neither automatically becomes a core DNS query just because port 53 hijacking is configured. For troubleshooting, temporarily disable Secure DNS in the browser and repeat the test under the same conditions before deciding on a long-term setup.

This TUN example also requires the mihomo DNS module to be enabled—for example, with dns.enable: true—and a working upstream resolver. fake-ip and redir-host are DNS handling modes, not alternatives to TUN. When using Fake-IP, configure the filter list to suit the apps you use.

Test IPv6 Separately

If your network provides both IPv4 and IPv6 but the client captures only one correctly, an app may prefer an address from the other family. Test IPv4 and IPv6 separately, and check the core’s IPv6 settings, DNS AAAA responses, and system routes. One successful IPv4 test does not prove that all connections pass through TUN.

5. How to Test: Change One Traffic Path at a Time

Test in this order: explicit proxy → system proxy → TUN. Keep the same policy group and proxy node throughout, and disable other proxies or VPNs. Reconnect after changing the traffic path so browser connection reuse does not skew the results. The commands below use public example sites to demonstrate the method; response times are not benchmark results.

1. Check that the proxy port works. Turn off TUN and explicitly specify the local proxy in a command. If this fails, troubleshoot the core, port, or proxy node before changing the virtual interface.
2. Check the system proxy. Turn on the system proxy, visit the same destination in a browser that honors system settings, then check the client’s connection list for the destination domain, matched rule, and policy chain.
3. Check TUN. Turn off the system proxy and leave TUN on. Access the destination from the command line without an app-level proxy, check the connection log, and inspect system routes if needed.
4. Test the actual apps. Then check games, voice chat, and LAN access. A successful webpage test does not verify UDP traffic or local network access.

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

# TUN comparison test: do not use curl proxy settings
curl.exe -I --connect-timeout 10 --noproxy "*" https://example.com/

# Test IPv4 and IPv6 separately
curl.exe -4 -I --connect-timeout 10 --noproxy "*" https://example.com/
curl.exe -6 -I --connect-timeout 10 --noproxy "*" https://example.com/

On macOS and Linux, replace curl.exe with curl. --noproxy "*" only tells curl not to use an app-level proxy; it does not bypass TUN. An HTTP response confirms only that the request received a response. To verify that it went through a proxy node, check the core’s connection log or verify the exit route.

On Windows, use route print to inspect routes. On macOS, use route -n get 1.1.1.1 to check the route to a specific IPv4 destination. On Linux, use ip route get 1.1.1.1. Systems may use interface routes or policy-based routing, so the presence of a particular default route is not a universal test.

6. Compatibility and Trade-Offs: Capture Only What You Need

When to Prefer the System Proxy

• You mainly use a browser and want other apps to keep their existing network paths.
• Your work device is connected to a corporate VPN, so changing routes across the whole device is not appropriate.
• Only a few developer tools need a proxy; configure an HTTP or SOCKS5 proxy in those tools.

When to Consider TUN

• The target app does not honor the system proxy and has no proxy settings of its own.
• You need to cover supported UDP traffic and have confirmed that the proxy node can handle it.
• You want multiple apps to pass through the core and be routed by domain, IP address, process, or other rules.

Running TUN alongside another VPN can cause conflicts involving the default route, DNS, overlapping subnets, and return paths. For example, if a corporate network also uses private addresses, a broad “bypass all private networks” rule may bypass routes required by the corporate VPN. First note the destination subnets used by the corporate network, then configure route exclusions and rules supported by your client. A generic private-network rule is not a complete solution.

You can enable both traffic paths at once, but it’s best not to during troubleshooting. Apps explicitly connecting to a local proxy may use the loopback path, while other apps use TUN. That makes it hard to explain why access still works after one setting is turned off. Keep one primary path to make it easier to identify whether the issue is permissions, DNS, the port, or a rule.

For platform-specific details, see the system guides. To import a subscription and configure rule-based routing, follow the setup guide. The best way to verify your setup is to check the target app’s actual connection logs, not a single “enabled” indicator in the client.