On this page
The system proxy waits for apps to submit traffic; TUN captures it at the system network layer
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 entry method only captures traffic. Rules, DNS results, and policy groups still determine the actual outbound route.
Judge the entry path solely by whether the previously failing program creates a connection record
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, the entry is not missing; continue reading the rule 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.
auto-route, interface, and stack jointly determine how data crosses the virtual adapter
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:53DNS overrides should send resolution requests into the same decision path
An app first resolves a domain to an address, then establishes the connection. If the DNS request bypasses Mihomo, the core may see only an IP and domain rules cannot work as intended. It may also receive a resolution result mismatched with the proxy outbound route, causing a home page to open while images fail or the same service works intermittently.
dns-hijack sends matching DNS traffic to Mihomo's internal DNS. It does not automatically apply to every system and source. Windows and macOS cannot automatically intercept DNS from other devices on the local network; router and phone requests require separate configuration. Android Private DNS also bypasses ordinary interception paths.
- Connections contains the domain, and the rule is correct
- DNS and sniffing provide at least enough information for rule evaluation.
- 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 preserves the domain relationship; it does not create speed from nothing
In fake-ip mode, Mihomo first returns a reserved address to the app and internally stores which domain corresponds to that fake address. When the app connects to it, the core can recover the original domain and evaluate DOMAIN, DOMAIN-SUFFIX, and RULE-SET earlier.
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 |
For apps that require a real IP, use redir-host or a precise Fake-IP exception
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 behaves more like ordinary DNS: the app receives the real IP returned upstream. The tradeoff is that Mihomo may not preserve domain mappings as early as Fake-IP, so domain-rule recognition also depends on the client, cache, and sniffing settings. Do not switch the whole setup because one internal domain fails; start with a single-domain exception.
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 |
DNS troubleshooting requires one unchanged request
When a domain-related issue occurs, hold the node and request constant, then record the current enhanced-mode, upstream DNS, and error. Change one variable at a time for comparison: for example, add a clearly incompatible internal domain to fake-ip-filter, or temporarily toggle Android Private DNS. If the result changes, keep that change.
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.
Browser users should start with the system proxy and use TUN only for UDP or missed traffic
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.
When networking fails, roll back TUN, then DNS, then the system proxy
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 web pages still will not open after you close the client, check whether the system proxy is still pointing to an old port on 127.0.0.1. Direct connectivity should return once the stale setting is removed. The choice should map to an observable result: the system proxy handles the browser, TUN captures processes that previously slipped through, and the DNS mode makes the target domain consistently match the intended rule. Do not keep any layer enabled long-term unless it delivers the result you need.