System Proxy vs. TUN Mode: Why Some Apps Bypass Clash

First, separate traffic capture from route selection

Your browser loads websites, but a game cannot connect. Clash is set to Global, yet downloads in the terminal still go direct. Usually, the controls are working—the traffic simply never reached the proxy core. When troubleshooting, first ask whether the connection got in, then which rule handled it.

• System proxy and TUN: determine how an app's traffic reaches the core.
• Rules, Global, and Direct: determine which route the core selects for a connection.
• Proxy groups and nodes: determine which proxy server handles the connection, or whether it goes direct.

Enabling TUN does not mean every connection will use a proxy. Once TUN is capturing traffic, a DIRECT rule can still send a connection directly. Conversely, switching to Global will not capture a program that completely ignores the system proxy.

System proxy: apps send connections to a local port

How HTTP and HTTPS requests reach Clash

When you enable “System Proxy” in the client, it typically updates the operating system's proxy settings. Apps that honor those settings then connect to the local proxy port. The flow is: app → 127.0.0.1:7890 → core checks rules → direct or proxy route.

HTTP requests can be forwarded through an HTTP proxy. HTTPS usually starts with a CONNECT request to create a tunnel, then carries TLS traffic through it. A standard HTTPS proxy tunnel does not require a decryption certificate, and enabling the system proxy alone does not let Clash read encrypted webpage content.

Why some apps are unaffected

The system proxy is a setting that apps can choose to read, not a switch that forces every network connection through a proxy. Browsers may honor it, use an extension, or rely on their own proxy settings. Command-line tools often use environment variables or app-specific settings, while games commonly open TCP or UDP connections directly.

• Windows: Go to Settings → Network & internet → Proxy to check the user proxy settings. Some services use separate WinHTTP settings, so this page alone may not tell the whole story.
• macOS: Go to System Settings → Network → select the current network service → Details → Proxies. Settings can differ between network services.
• Linux: Desktop proxy options, shell environment variables, and app-specific settings may not be connected. Check each one separately.

System proxy makes fewer changes and is easier to troubleshoot app by app. If you mainly need a browser and developer tools that support proxies, start here to make issues easier to isolate.

TUN mode: capture IP packets through a virtual network interface

TUN is a layer 3 virtual network interface. A TUN-capable core uses operating-system routes to send eligible IP packets to the virtual interface, identify their connections, and pass them to the rule engine. Apps do not need to understand HTTP or SOCKS proxy protocols.

There is still one important condition: packets must actually be routed to the TUN interface. Auto-routing, excluded subnets, interface binding, and route priorities from other VPNs can all affect coverage. “TUN is enabled” does not mean it captures traffic from every process on every interface.

Understanding mihomo configuration options

Clash is a common name for the client and core ecosystem. Clash Meta continued development under the name mihomo, and features vary between cores. The following mihomo TUN snippet shows how the fields relate; merge it into your existing configuration rather than replacing your entire subscription.

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

• enable: Enables TUN, but the required operating-system permissions still apply.
• stack: Selects the network stack implementation. mihomo offers options such as system, gvisor, and mixed. Support depends on your core version; no option is fastest on every device.
• auto-route: Automatically adds routes needed for traffic capture, but does not override every routing exception.
• auto-detect-interface: Automatically detects the outbound interface. Check the actual route if you are also using a work VPN.
• dns-hijack: Here, any:53 captures matching UDP DNS requests on port 53, provided they have already entered the relevant capture path.

Desktop clients may generate these fields through their settings, and subscription updates may overwrite manual changes. Prefer the client's TUN settings, configuration overrides, or merge features, then check the final active configuration.

DNS differences: proxying a webpage does not mean DNS takes the same route

Where domain names may be resolved when using a system proxy

DNS behavior depends on the app and proxy protocol. An HTTPS CONNECT request can include the destination domain for the proxy to resolve, but an app may also use system DNS beforehand. SOCKS5 can likewise pass either a domain name or an already resolved IP address; the outcome depends on which one the app uses.

That is why command-line tests against the same SOCKS5 port can return different results with socks5:// and socks5h://: in curl, the latter explicitly resolves the destination domain through the proxy. A changed public IP does not prove that all DNS requests went through Clash.

TUN DNS hijacking and Fake-IP are separate features

DNS hijacking forwards matching DNS requests to the core's DNS module. Fake-IP is a response method: the app gets a mapped address, and the core maps subsequent connections back to the original domain. mihomo commonly uses 198.18.0.1/16 as its Fake-IP pool; check your configuration. This is not the public IP address of a proxy server.

• When using the DNS capture snippet above, also check dns.enable, upstream resolvers, and related routes to make sure the DNS module is enabled.
• any:53 does not automatically decrypt browser DoH or treat TLS-encrypted DoT traffic as regular DNS.
• Domain-based rules depend on the core knowing the domain name. If it only sees the destination IP, the match may differ from what you expect.
• If Fake-IP causes issues with LAN device discovery, internal company domains, or a particular app, adjust the relevant filters and DNS rules rather than clearing all DNS settings.

Choose by app: browsers, command-line tools, and games

Browsers: check the browser's own proxy settings first

A browser can usually start with the system proxy. If only one browser is affected, check its proxy extensions, custom proxy settings, Secure DNS, and any connections opened before you switched settings. In Firefox, go to Settings → General → Network Settings → Settings and check whether “Use system proxy settings” is selected.

Command line: specify the port explicitly for repeatable tests

Use the commands below to compare a direct connection, an HTTP proxy, and SOCKS5 with proxy-side DNS resolution. In Windows PowerShell, use curl.exe to avoid older environments interpreting curl as a different command alias. Reaching a test site alone does not prove the proxy worked; check the client's connection log at the same time.

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

The first command bypasses an explicitly configured proxy, but traffic may still go through TUN if TUN is capturing it. To test the system proxy, turn TUN off first. To test TUN, remove explicit proxy arguments so the two routes do not get mixed up.

To make tools in the current shell that support environment variables use a proxy, set the variables below temporarily. They affect only processes that read them; they do not change the network route for the entire device.

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1

The value of https_proxy can still use http:// to establish an HTTPS tunnel through an HTTP proxy. Git, package managers, and container tools may also have their own proxy settings. Inside a container, 127.0.0.1 points to the container itself, not the host.

Games and voice chat: check UDP support on the outbound route

A game may use HTTPS to sign in, then UDP for matches and voice chat. If you can sign in but cannot join a match, checking websites is not enough. TUN can capture the relevant UDP packets, but the selected node, proxy protocol, server, and network route must all support UDP forwarding.

A proxy does not guarantee lower latency. The game server's region, route length, packet loss, and jitter matter more than the node's name. For a fair test, keep the server and node fixed and record direct and proxied results separately. A single speed-test bandwidth score does not predict how a game will feel.

Apps bypassing the proxy: follow two troubleshooting paths based on connection logs

1. Start with a minimal setup. Pause other VPNs, game boosters, and proxy extensions, leaving just one client running. Note your current settings first, and check your organization's network policies if you are on a work network.
2. Confirm the core is running. Check that the mixed port is actually 7890. On Windows, run netstat -ano | findstr :7890 to check for a listening port. The port being open does not prove the current client owns it, so verify the process too.
3. Test the system proxy on its own. Turn TUN off and enable the system proxy. Open a new connection in a browser or with an explicit proxy command from above, while checking “Connections” and “Logs” in the client.
4. Then test TUN separately. Turn off the system proxy, enable service mode or administrator permissions as required by the client, and then turn on TUN. Android typically requires system VPN authorization; Linux typically needs the appropriate network-management permissions. The Windows steps do not apply everywhere.
5. Check the matched rule and actual route. If a connection appears but shows DIRECT, check rule order, process matching, and the selected proxy group first. Rules are evaluated in order, so an earlier match may take precedence over the rule you expected.
6. Check DNS and compatibility last. If logs show DNS timeouts, Fake-IP mapping issues, or failures with specific UDP traffic, adjust the relevant setting one at a time.

Short-lived connections may disappear from the Connections panel before you can see them. If needed, enable logging and reproduce the issue. Before sharing logs, remove subscription URLs, access tokens, node credentials, and private domains. Do not expose your full configuration just to share a screenshot.

Choosing a mode: start with the narrowest traffic capture

For browsers and a few proxy-aware apps, start with the system proxy. For predictable behavior in developer tools, configure each tool's own proxy options. Consider TUN only when games, voice chat, or apps that ignore proxy settings need their traffic captured.

System proxy and TUN can run together; they do not inevitably conflict, but test them separately while troubleshooting. If your connection drops, there is no need to reinstall right away: turn off TUN and confirm routes recover, then turn off the system proxy and check whether the OS still points to a local port left behind by a stopped client. If TUN is already capturing connections but the outbound route cannot connect, changing the capture method will not fix the node itself.

Use this troubleshooting order: Is traffic captured? → Is DNS working correctly? → Which rule matched? → Can the outbound route connect? These four checks turn “the proxy is on, but nothing works” into problems you can verify. For rule fields, see the Configuration and Protocol Guide. For your first setup, start with the Quick Start Guide.