TUN vs. System Proxy: How Traffic Is Captured
Clash TUN mode receives IP packets through a virtual network interface, then passes them to the core to resolve, match against rules, and establish outbound connections. A system proxy, by contrast, exposes an HTTP or SOCKS proxy endpoint that applications must explicitly use. So if your browser connects but command-line tools, games, or some desktop apps bypass the proxy, the issue may be how traffic is captured—not the proxy node itself.
This guide covers the mihomo core, which evolved from Clash Meta. A client with “Clash” in its name may use a different core; the configuration features of legacy Clash, legacy Premium, and mihomo are not interchangeable. Before you begin, check the client’s core information or startup logs to confirm that mihomo is running, and refer to the current core’s supported configuration fields.
| Check | System proxy | TUN mode |
|---|---|---|
| Traffic capture point | Application proxy interface | System routing and virtual network interface |
| Application requirements | Must honor the system proxy or be configured individually | Traffic routed through the interface can be captured |
| UDP traffic | Not uniformly covered by a standard HTTP system proxy | Can be captured, but the proxy outbound must support UDP |
| Permissions | Usually no permission to create a network interface is needed | Usually requires administrator access, a privileged service, or network capabilities |
| How traffic is routed | Determined by core rules | Still determined by core rules |
Before you start: check your nodes, permissions, and persistent configuration
- Test the connection first. Use the system proxy to open a known-working site and confirm that your subscription is imported and at least one proxy group has a working node. TUN cannot fix an expired subscription, failed node authentication, or an offline server.
- Back up the active configuration. Note the current mode, DNS settings, and existing routes. Some clients generate their runtime configuration from subscription data, so direct edits may be overwritten on update. Use the client’s override, merge, or persistent configuration options instead.
- Pause other traffic-capture tools. Quit other VPNs, accelerators, and virtual-network proxy apps to reduce conflicts involving default routes, DNS, and firewall rules. Re-enable them one at a time after troubleshooting.
- Keep a local way to control the device. Route changes can interrupt remote desktop or SSH sessions. For your first setup, work directly on the device; don’t change routes over your only remote connection.
Menu names vary by client. Verify three things: the privileged service is available, TUN is enabled, and the active configuration contains a valid tun section. An enabled-looking switch alone does not prove that the virtual network interface was created successfully.
mihomo TUN Configuration: Stack, Routing, and DNS
The example below can be merged into an existing mihomo configuration; it is not a complete subscription with proxies and proxy groups. It keeps your existing proxies and rules and demonstrates only traffic capture and DNS. If the top-level dns or tun section already exists, merge the fields instead of declaring the same key twice.
mode: rule
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:
- https://1.1.1.1/dns-queryStack: Start with mixed, then switch if troubleshooting calls for it
mihomo offers TUN stack options such as system, gvisor, and mixed. With mixed, TCP uses the system stack and UDP uses the gVisor stack, making it a clear starting point. Compatibility varies across operating systems and core builds. If connections fail, change only one stack at a time and retest the same destination; don’t change the node, DNS, and routing simultaneously.
Changing the stack does not change what the proxy node can carry. Even if your device captures UDP successfully, games, voice chat, and QUIC connections may still fail if the selected proxy protocol or server does not support UDP forwarding. Check outbound support rather than repeatedly reinstalling the virtual network interface.
auto-route: Adds routes; it doesn’t change routing rules
auto-route: true lets the core automatically add routes through TUN. auto-detect-interface: true identifies the outbound network interface to prevent connections to the proxy server from re-entering TUN and creating a routing loop. On devices with wired, wireless, and virtual interfaces, existing routes can affect auto-detection. If you need to specify the outbound interface manually, first confirm its actual name, then use the configuration method supported by your core version.
dns-hijack: Captures traditional DNS, not encrypted DNS
any:53 matches UDP requests on port 53 entering TUN; tcp://any:53 matches TCP port 53. These send matching traffic to the core’s DNS handler, but they cannot turn browser DoH or app-managed DoT back into regular DNS. For testing, temporarily turn off your browser’s “Secure DNS” setting to verify the system’s DNS path first.
In this example, 127.0.0.1:1053 is the local DNS listening address—not the system proxy port, and not an address with a port to enter as your network adapter’s DNS server. TUN interception and the local listener are separate entry points. fake-ip returns virtual addresses for the core to map; seeing results in the 198.18.0.0/16 range does not, by itself, indicate a problem.
Windows: Check service permissions, then inspect the virtual adapter
- Quit other VPNs. Go to Settings → Network & Internet → Proxy and note your existing manual proxy settings so they don’t confuse tests of the two traffic-capture methods.
- Install or enable the service mode provided by your client, and approve the Windows User Account Control prompt. If the client has no service mode, follow its instructions to run it temporarily as an administrator and check whether permissions are the issue.
- Enable TUN in rule mode and check the logs for errors creating the interface or configuring routes. Don’t download network adapter drivers from unknown sources to replace the components bundled with the client.
- Turn off the system proxy in the client, then run the commands below to inspect interfaces and routes and test connectivity. Restore the system proxy afterward if needed.
Get-NetAdapter -IncludeHidden |
Format-Table Name, InterfaceDescription, Status
Get-NetRoute -AddressFamily IPv4 |
Sort-Object RouteMetric |
Format-Table DestinationPrefix, InterfaceAlias, NextHop, RouteMetric
Resolve-DnsName example.com
curl.exe --noproxy "*" -I https://example.comRun these commands in PowerShell. --noproxy "*" tells curl to ignore application-level proxy settings, but it does not bypass system routing, making it useful for checking TUN. The adapter name depends on the client configuration, so don’t rely on one specific name as the only sign of success. Also check the core’s connection records for this request.
If the logs report access denied, address the service permissions first. If the interface exists but no requests reach the core, check routes, other VPNs, and security software logs. Disabling the entire firewall is not a safe long-term fix.
macOS: Authorize the helper service and identify utun interfaces
Creating a TUN interface and changing routes on macOS requires appropriate permissions. Desktop clients usually handle this through a privileged helper service. Install or authorize it as prompted, and check System Settings → Privacy & Security if macOS asks you to. Authorization varies by distribution method, so the absence of a particular system toggle does not necessarily mean installation failed.
- First verify the node in regular proxy mode, then enable the client’s privileged helper service and TUN.
- To test TUN independently, check the HTTP, HTTPS, and SOCKS proxy status under System Settings → Network → your current network connection → Details → Proxies.
- Use Terminal to inspect interfaces, routes, and DNS; use the core’s connection records to confirm the test request’s rule and outbound.
ifconfig
netstat -rn -f inet
scutil --dns
curl --noproxy '*' -I https://example.comutun interfaces can also be created by macOS features or other VPNs, so their number alone doesn’t show whether Clash TUN is working. Compare route changes and log timestamps before and after enabling it. macOS supports resolvers assigned by interface and domain; scutil --dns is more useful for checking system DNS than looking only at /etc/resolv.conf.
Linux: Check /dev/net/tun and the service account
Linux needs an available TUN device and permission to create interfaces and modify routes. This commonly requires CAP_NET_ADMIN, though the exact requirements also depend on kernel features, service sandboxing, and the runtime environment. Desktop clients can perform these operations through a bundled service. If running mihomo directly, use a reviewed service configuration rather than granting permissions to an unknown binary.
ls -l /dev/net/tun
ip -br link
ip route show table all
ip rule show
resolvectl statusresolvectl applies to systems using systemd-resolved; on other distributions, check the DNS resolver actually in use. If you have a systemd unit named mihomo.service, use the commands below to inspect its status and logs from the current startup. If the unit has a different name, use the name configured during installation.
systemctl status mihomo.service
journalctl -u mihomo.service -b --no-pager -n 100Don’t check only the main routing table. Automatic routing may use policy routing, so inspect ip rule show and all routing tables as well. Root inside a container does not mean full access to the host; the container also needs the TUN device exposed and the required capabilities. Don’t use a fully privileged container as a substitute for checking permissions.
Verification: Check traffic capture, rules, and outbound separately
- Verify traffic capture. Turn off the system proxy, run the curl command above, and check the core’s connection records. If the destination domain or IP appears, the request reached the core; a webpage loading by itself isn’t enough to confirm this.
- Verify the rules. Visit services that should go direct and through the proxy, then note the matched rule, proxy group, and final node. If TUN works but traffic matches DIRECT, that’s a routing result—not a traffic-capture failure.
- Verify DNS. Test system name resolution, then run a DNS leak test. The resolver shown by a test site is the recursive DNS server, so it does not have to match the proxy exit IP. Check that it follows the DNS path you intended.
- Verify IPv6. If IPv6 is enabled, test both IPv4 and IPv6 and check the core’s connection records. Testing IPv4 alone does not confirm that dual-stack traffic is captured.
- Verify UDP. Retest with the game, voice app, or HTTP/3-enabled app you actually use, and confirm that your node supports UDP. A successful TCP request to a regular website does not prove UDP is working.
Record three sets of results—before enabling TUN, after enabling it, and after turning it off—including system proxy status, matched rules, DNS upstream, and error logs. Latency depends on the node, destination, network path, and cache; one speed test cannot show that TUN is faster than the system proxy.
Common TUN Issues and Safe Rollback
| Symptom | Check first | What to do |
|---|---|---|
| Internet stops working as soon as TUN is enabled | Interface permissions, routing loop, reachability of the upstream DNS server | Turn off TUN to restore connectivity, then review the startup logs one item at a time |
| Domains fail, but IP addresses work | Core DNS, port 53 interception, app-level encrypted DNS | Test DNS resolution separately without changing the node at the same time |
| Browser works, but games don’t | UDP outbound, node capabilities, destination rules | Check UDP connection records and server support |
| Can’t access devices on the local network | Private-network routes, destination address, domain mapping | Set route exclusions or direct rules for the specific subnet |
| Problems after switching Wi-Fi networks | Outbound interface detection, stale routes, logs of network changes | Once the network is stable, restart the core and check routes again |
Direct access to your LAN and bypassing TUN are different
Matching a private IP address to DIRECT means traffic goes through the core and exits directly; excluding that subnet from TUN routing means traffic bypasses the core. These approaches differ in log visibility and DNS behavior. If a printer, NAS, or corporate network is unreachable, first confirm the destination’s actual address and subnet. Don’t exclude a large, unknown address range just to fix access to one device.
How to restore your settings after turning TUN off
Turn off TUN first and wait for the client to remove its interface and routes; then restore your original system proxy and DNS settings. If you still can’t connect, exit the client normally and check for leftover proxy settings, routes, and other VPNs. Don’t clear the entire routing table. If old addresses persist after changing DNS or fake-ip settings, verify the configuration, flush the system DNS cache, and restart the affected apps.
Keep a verified working configuration that documents the core type, TUN stack, DNS upstream, outbound interface selection, and any required LAN exceptions. Subscription updates should change only what you expect. After changing traffic-capture or DNS settings, repeat the same tests in the same order to distinguish configuration issues from node problems or changes to the system network.