TUN mode vs. system proxy: How traffic routing works and when to use each

Choose a mode based on the apps you use

For browsers and desktop apps that follow your system proxy settings, start with the system proxy. Use TUN when you need to route apps that ignore proxy settings, some games, or UDP traffic. TUN generally covers more traffic, but whether it works depends on routing, permissions, DNS, and interference from other VPNs.

These modes determine how traffic reaches the core—not which proxy node it ultimately uses. Once traffic enters Clash or mihomo, rules and proxy groups still apply. Enabling TUN does not mean all traffic is proxied; connections matched to DIRECT still connect directly.

How system proxy and TUN routing work

System proxy: apps connect to a local port

A system proxy typically registers a proxy address with the operating system, such as 127.0.0.1:7890. Apps that read this setting send requests to a local listening port. HTTPS sites generally establish a tunnel through an HTTP proxy using the CONNECT method; this does not downgrade the connection to HTTP.

Whether an app reads system proxy settings depends on its networking library. Some command-line tools only read environment variables such as HTTP_PROXY and HTTPS_PROXY; others have their own proxy options. On Windows, the user proxy settings and WinHTTP settings are separate, and services do not necessarily follow the desktop user's proxy.

TUN: routes send IP packets through a virtual network adapter

TUN creates a layer 3 virtual network interface, then uses routes to send matching IP packets to the core. Apps do not need to understand HTTP or SOCKS proxies, so programs that make direct TCP or UDP connections can also be routed through the proxy.

This does not automatically cover everything. More-specific routes, policy routing from other VPNs, network adapter binding, and IPv6 settings can all change the actual path. TUN also does not mean every protocol can be proxied: UDP requires support from both the selected outbound and the server, so working TCP does not imply working UDP.

DNS is a key difference between the two modes

A page loading successfully does not prove DNS is being handled as intended. With a system proxy enabled, some apps still ask the operating system to resolve a domain before connecting to the proxy; others send the domain directly to the proxy. SOCKS can resolve names locally or remotely, so be sure to specify which method you are testing.

Port 53 hijacking and encrypted DNS

mihomo's dns-hijack can redirect matching traditional DNS requests to the built-in DNS resolver. The common any:53 setting targets UDP port 53; to handle TCP port 53 as well, add tcp://any:53. This does not automatically detect every type of DNS query.

Browsers use HTTPS for DoH, while DoT typically uses TCP port 853 and DoQ typically uses UDP port 853. These protocols are not redirected to the built-in DNS resolver just because port 53 hijacking is configured. Their connections may pass through TUN, but that does not mean the encrypted queries are handled by the core's DNS resolver. Domain-based routing also depends on domain mapping and sniffing settings.

A fake-ip address does not mean DNS resolution failed

With fake-ip enabled, the built-in DNS resolver can return a mapped address, commonly from 198.18.0.0/16, and the core associates subsequent connections with the original domain. Do not change DNS just because you see an address like 198.18.x.x. Check that TUN is still capturing the app's traffic and that the mapping is valid.

• After changing DNS modes, quit and reopen the app you are testing so it does not keep using existing connections or cached results.
• On Windows, run ipconfig /flushdns to clear the system DNS cache. Browsers may still have their own caches.
• Use reachable internal DNS servers for local device names and corporate domains; do not send every query to a public resolver by default.
• If IPv4 works but IPv6 does not, check IPv6 routing and DNS responses separately. Checking only A records is not enough.

Configure and enable mihomo

Keep a working copy of your configuration before changing how traffic is routed. The YAML below shows fields to merge; it is not a complete subscription. Keep your existing proxies, proxy-groups, and rules. If the file already contains tun or dns, merge these settings into the existing mappings rather than adding duplicate top-level keys.

Check the local proxy entry point first

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

mixed-port lets HTTP and SOCKS share a port. Set allow-lan: false to keep the proxy service inaccessible to other devices on your local network; TUN routes traffic from this device and does not require LAN access to be enabled. mode: rule keeps rule-based routing in place—it does not replace your nodes or rules.

Then merge the TUN and DNS settings

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

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

The two public DNS addresses shown are examples of upstream resolvers, not a fit for every network. Configure upstream resolvers and domain resolution policies to suit your environment, especially on corporate or campus networks. listen's 1053 is the built-in DNS listener port, not the system proxy port. This field alone does not redirect system DNS to that port.

• stack: mixed selects the mixed protocol stack. Check your core's supported options, and consult its documentation about other stacks if you run into compatibility issues.
• auto-route: true requests automatic routing of traffic through TUN; it does not guarantee that routes from other VPNs will take precedence.
• auto-detect-interface: true automatically detects the outbound interface. If you use multiple adapters, a hotspot, or a VPN, check which interface is actually used.
• dns.enable and tun.enable are separate switches. Enabling TUN does not necessarily enable the built-in DNS resolver.

Start in order and verify

1. First confirm that your existing nodes work with the system proxy. Then temporarily disconnect other VPNs and note your current network settings.
2. Install the required service or grant administrator privileges as directed by your client, then enable TUN. On mobile, you will usually need to approve the system VPN permission.
3. Reload the configuration and check the startup logs for invalid fields, insufficient permissions, virtual adapter creation failures, or port conflicts.
4. Temporarily turn off the system proxy and leave TUN enabled. Test a browser and an app that normally ignores proxy settings.
5. Check the connection log for the destination, matched rule, and final policy. Confirm that traffic not only enters the core but also takes the intended route.

Use two tests to distinguish port issues from routing issues

Change only one condition at a time. The commands below use the same HTTPS URL to compare an explicit proxy with a request that does not use an application-level proxy. In Windows PowerShell, use curl.exe to avoid issues with the curl alias in some environments.

Test 1: Check the HTTP proxy entry point only

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

Run this with TUN disabled. --noproxy "" clears the proxy bypass list for this request and explicitly uses the local 7890 port. If the connection is refused, check that the port is listening and the core has started. If the proxy accepts the request but the destination times out, check the node, rules, and destination site.

Test 2: Check the TUN routing path only

curl --noproxy "*" --connect-timeout 10 -I https://example.com/

Turn off the system proxy and enable TUN before running this. --noproxy "*" tells curl not to use an application-level proxy, but it cannot bypass the operating system's TUN routes. Check the core's connection log afterward. A successful command alone does not prove the request was proxied; it may have connected directly.

These commands test HTTPS requests only. They do not test game UDP, voice calls, or QUIC. To test those scenarios, use the actual app to establish a session and check whether the relevant UDP connection appears, which rule it matches, and whether the outbound supports UDP.

Check routing and DNS status

# Windows
route print
ipconfig /all
netsh winhttp show proxy

# Linux
ip rule show
ip route show table all
resolvectl status

# macOS
scutil --proxy
scutil --dns
netstat -rn

These commands read system status and do not change network settings. On Linux, resolvectl is available only on systems that provide the tool; otherwise, check DNS settings in your network manager. Automatic routing may add routes to a separate routing table, so checking only the main table is not enough.

Common issues and compatibility fixes

System proxy works, but the internet stops working when TUN is enabled

First check TUN permissions, virtual adapter creation, and outbound routes. Turn TUN off to see whether connectivity returns, then enable it on its own. If the problem occurs only when connected to a corporate VPN, coordinate routing and internal DNS instead of repeatedly switching nodes.

Do not delete default routes or stop unfamiliar network services without a clear reason. Changing TUN routes during a remote desktop session can disconnect you; arrange local access or a rollback plan first.

Browser works, but command-line tools or games do not

With only the system proxy enabled, the app may not be using that proxy. For command-line tools, try specifying the proxy explicitly. For games, check whether they use UDP and whether the node supports that traffic. If they still fail with TUN enabled, check the connection log instead of assuming traffic capture failed.

Local devices, printers, or corporate domains are unreachable

First distinguish routing problems from name resolution problems. If you can connect using the device's IP address but not its name, check internal DNS. If the IP address is unreachable too, check local network routes and rules. Setting a destination to DIRECT only determines its outbound after traffic enters the core; it may not fix app-based broadcast or multicast discovery.

Can both modes be enabled at once?

Some clients support enabling the system proxy and TUN together. The core normally handles its own outbound traffic to prevent routing loops, but that does not mean running both modes is more reliable. For troubleshooting, test each mode separately; for everyday use, enable only what you need. Running other proxy software or VPNs at the same time can cause unclear traffic ownership and competing routes.

Can you use desktop settings on Android and iOS?

No. Mobile clients often use the system VPN interface to capture traffic, with permissions, app exclusions, and background behavior controlled by the platform and client. A typical mobile device can usually have only one user-level VPN connection active at a time. The YAML in this article cannot replace system VPN permissions or guarantee support for the same fields in other clients.

Keep the configuration minimal for your use case

• Browsers and common desktop apps: Start with the system proxy and confirm that each app follows it.
• Developer tools and terminals: Start with the tool's own proxy options; consider TUN if you need to route many tools consistently.
• Games, voice apps, and programs without proxy support: TUN may help, but verify UDP support, node capabilities, and rules separately.
• Corporate VPNs, multiple adapters, and complex internal networks: Record your routes and DNS settings first, then decide which connections to capture. Avoid changing several network layers at once.

A stable setup means the target app uses the intended entry point, DNS resolution fits the network, the right rule is matched, and connectivity returns when traffic capture is disabled. For field details, see the configuration reference. For general connection issues, work through the FAQ.