On this page
A working browser with no terminal connection records needs different checks from a recorded request whose domain rules do not work. For the former, check how traffic reaches the client; for the latter, check the actual domain, resolution result, and rules. Extending traffic handling cannot fix a failing node or service. These distinctions help you decide when to use a virtual network adapter and when only one internal domain needs an exception.
How Do the System Proxy and TUN Capture App Traffic?
When enabling the system proxy, Clash writes a local proxy address into the operating system. Apps that honor it send HTTP and HTTPS requests to that port. Browsers normally do; terminal tools, games, and some desktop apps may not. The system proxy also cannot uniformly capture UDP.
TUN creates a virtual adapter and routes more TCP and UDP connections into Mihomo. It addresses “this process did not use the local proxy port,” but cannot change node availability, rule order, or a server's 403 response.
Core differences between the two entry methods
| Item | System proxy | TUN |
|---|---|---|
| Who decides whether traffic enters Clash | Whether the app reads system settings | System routing and the virtual adapter |
| UDP | Normally not captured | Can enter TUN, still depending on the node and configuration |
| System permissions | Modify proxy settings | Also requires virtual-adapter, service, or network-extension permission |
| Rollback | Disable the proxy toggle | Disable TUN and wait for routes and the interface to be removed |
- An app initiates a connectionBrowser, terminal, game, or background service
- System proxy or TUNDetermines whether the traffic can enter the core
- Rules and DNSPreserves the domain and determines direct access or proxying
- Actual outbound routeDIRECT, a proxy node, or rejection
The system proxy or TUN sends traffic into the core. Rules, DNS results, and policy groups then determine whether that traffic goes directly or through a proxy node.
Use Connections to Decide Whether an App Needs TUN
Use the same action for a before-and-after comparison
Keep the Profile, Rule mode, and node fixed
Prevent automatic switching or configuration updates from interfering with entry testing.
Enable only the system proxy
Repeat one fixed action in the target program.
Inspect Connections
If the request appears, it has entered the client. Continue by checking rules and logs.
Enable TUN only when no record appears
Repeat the same action and compare whether a new connection appears.
If a new connection appears and succeeds under TUN, it filled the capture gap. If both entry methods show the request but both return timeout, focus on the node, DNS, or target network instead of continuing to switch entry methods.
The Roles of auto-route, the Outbound Adapter, and stack
Mihomo auto-route sends traffic into TUN, while auto-detect-interface identifies the real outbound adapter. stack may use system, gvisor, mixed, or another implementation. If the default covers the target app, do not change it arbitrarily for “speed.”
A sudden outage after switching from Wi-Fi to a hotspot may reflect a changed outbound adapter. Adjust the firewall for the core process only when system or mixed is blocked on a specific computer. On Windows, strict-route may also affect virtual networks such as VirtualBox, so validate virtual machines separately.
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53When Domain Rules Fail, Check Whether DNS Enters Mihomo
DNS converts domain names into addresses for connections. If resolution bypasses Mihomo, the core may see only an IP and fail to match domain rules as intended. The resolved address may also conflict with the proxy exit, causing a homepage to load while images fail or access becomes intermittent.
dns-hijack sends matching DNS traffic to Mihomo’s internal DNS, but it does not work automatically on every system. Windows and macOS cannot automatically intercept queries sent to DNS servers on the local network; check the actual system DNS address and interception results. Android Private DNS also bypasses ordinary interception.
- Connections contains the domain, and the rule is correct
- The request contains a domain name that rules can use. It may come from the proxy request, DNS mappings, or sniffing.
- Only an IP appears, and domain rules do not match
- Check whether DNS enters Mihomo and whether the app uses encrypted DNS.
- The IP works, but the domain reports a resolution error
- Compare system DNS, Mihomo DNS, and the current network.
Fake-IP: Map Virtual Addresses to Original Domain Names
The fake-ip mode returns a reserved address to the app and remembers its domain name. When the app connects to that address, Mihomo can recover the domain and use DOMAIN, DOMAIN-SUFFIX, and RULE-SET to select the exit.
This method does not automatically make DNS faster or improve remote-node quality. Some local-network services, device discovery, enterprise software, or programs that directly validate an IP may be incompatible. Add the specific domain to fake-ip-filter, or choose another DNS enhancement mode after validation.
Common Fake-IP results
| Behavior | Explanation |
|---|---|
| The system query returns a reserved address | This may be a normal fake-ip mapping and does not mean the domain was hijacked |
| Connections can display the original domain | The mapping helps the core evaluate domain rules |
| One internal domain fails under fake-ip | Exclude the exact domain and let internal DNS resolve it |
| Every site is slow | Do not conclude from fake-ip alone; continue with the node, DNS upstreams, and logs |
redir-host and Single-Domain fake-ip-filter Exceptions
Some enterprise software, local-network services, and device-discovery features directly use the real address returned by DNS and should not receive a Fake-IP. You can use redir-host for the entire configuration or add only known-incompatible domains to fake-ip-filter. The former changes resolution for every domain; the latter has a smaller scope.
redir-host gives apps the real IP returned by upstream DNS. Mihomo may not retain domain information in advance as Fake-IP does; identification also depends on the client, cache, and sniffing. If only one internal domain fails, start with an exception for that domain rather than changing the whole configuration.
Choosing when a real IP is required
| Scenario | Better approach | Verification results |
|---|---|---|
| Only one corporate internal domain fails | Add a precise fake-ip-filter and use internal DNS | Return the real internal IP, and let the connection match DIRECT |
| One class of apps is broadly incompatible with Fake-IP | Compare with a separate redir-host configuration | The app recovers, and public-domain rules still match correctly |
| NAS devices and printers use fixed private IP addresses | Keep private subnets on DIRECT | Access no longer detours through a proxy policy |
| You do not know which domain is incompatible | Find the target in Connections and DNS logs first | Add an exception only after identifying it; do not use a broad wildcard |
Keep the Target Request Fixed and Adjust DNS Based on Resolution Errors
For a domain issue, keep the node and request fixed and record the current enhanced-mode, upstream DNS, and error. Change one variable at a time, such as adding a confirmed incompatible internal domain to fake-ip-filter or temporarily changing Android Private DNS. Keep the change only if the issue improves and previously working access still works.
no such host / DNS lookup failed
Check whether the upstream DNS is reachable and whether requests are reaching Mihomo.
LAN domains stop resolving, while public domains still work
Preserve the internal DNS path, and set direct routing or a Fake-IP exclusion for the exact domain.
Resolution fails only after switching networks
Compare the DNS, IPv6, and egress interface on the two networks before changing every node.
Domain rules always show MATCH
Check whether the core received the domain name and whether a broader rule matched first.
Which Method Fits Browsing, UDP, and Corporate Networks?
Choose for the use case
| Use case | Recommended starting point | Why |
|---|---|---|
| Mostly web browsing and desktop apps that honor the system proxy | System proxy | Requires fewer permissions, is easy to turn off, and has a clear connection path |
| No Connections records for terminals or game launchers | Compare app proxying with TUN | Captures processes that do not use the system proxy |
| Apps that need UDP support | TUN | The system proxy cannot capture UDP consistently |
| Corporate intranets, virtual machines, and complex LANs | Start with the system proxy | Keep the original routes first, then verify the TUN exclusion scope one item at a time |
| A domain rule routes incorrectly | Any existing entry point + rule correction | Expanding the entry point does not change which rule matches first |
The choice is not permanent. When you only need a browser for everyday use, you can turn off TUN and return to the system proxy; enable it again when a particular program needs it. After either switch, verify with the original target action and Connections, not just the color of the toggle.
Disable TUN, Restore the System Proxy, and Clear Stale Ports
If everything loses connectivity as soon as you enable TUN, turn TUN off first and keep the original Profile and node. If the system proxy recovers, the problem is in the virtual adapter, routes, or TUN DNS. If the system proxy also fails, return to the node and configuration. Do not use the operating system's network reset right away, because it clears many unrelated settings.
If pages still fail after closing the client, check whether the system proxy still points to an old 127.0.0.1 port. Clear it, then verify recovery with a target that can normally be reached directly.