On this page
An app showing “Connected” is only the start of troubleshooting; check whether the target you just accessed returned a result. An immediate proxy error on a web page, failures only with domain names, and losing internet access across the device after enabling a virtual network adapter require different checks. Recording the exact symptom helps avoid changing rules, nodes, and system settings all at once.
Connected Status Does Not Mean Requests Succeed
Record the failing target, exact error, and current mode, then use the table below to choose a check. A running core does not prove that the proxy port works, and a reachable node does not prove that DNS works; verify these separately.
The system-proxy comparison and port checks below apply to Windows/macOS. On Android, check VPN permission and per-app settings using the mobile guide. Once there are connection records, the DNS, rule, and node checks later in this article still apply.
First check for each symptom
| Symptom | Check first |
|---|---|
| Every website immediately reports a proxy connection failure | The local address and port configured in the system proxy |
| Domains fail, but direct access by IP responds | DNS and browser secure DNS |
| Domestic sites work, while sites requiring proxying time out | Node, policy group, and matched rule |
| The system proxy works, but enabling TUN breaks all connectivity | Service, virtual adapter, default route, and other VPN software |
| Only one app fails | Whether that process enters Clash, plus the app's own status code |
Compare System Proxy, TUN, and Direct Access
Disable TUN, keep only Rule mode and the system proxy, and reopen the same page. If the system proxy works while TUN breaks connectivity, the subscription and node have at least one viable basic path, so focus on services, routes, and DNS. If both modes fail, leave the virtual adapter alone for now.
For the direct test, use a page that your current network can normally open without a proxy, rather than the target that requires one. If that page also fails after disabling the system proxy, check Wi-Fi, broadband, corporate authentication, or the router. Clash cannot fix a network that already lacks internet access.
Does the Web Request Appear on the Connections Page?
Clear the connection records and visit one fixed domain. If no new request appears, the browser may not use the system proxy, the port may be wrong, or the app may bypass the current capture method. Changing more rules and nodes will not affect that.
Once the request appears, record its target, matched rule, group, and error. Unexpected DIRECT, REJECT, timeout, and connection refused indicate different causes and need separate checks. Looking only at the tray icon color misses this concrete evidence.
One minimal reproduction
Keep the configuration and node fixed
Temporarily disable automatic switching and keep one egress.
Clear the connection and log views
Do not mistake a background update for the page request you just made.
Visit the same HTTPS address
Record whether it enters Clash, which rule it matches, and what error appears.
Change only one variable and retry
Do not change the node, rule, DNS, and TUN together.
For an immediate error, verify the system proxy and listening port
If the browser immediately says it cannot connect to the proxy server, Windows or macOS may still point to an old port on 127.0.0.1 while the current client is not listening. Read the actual mixed-port from client settings, then verify it with netstat, lsof, or ss.
If the port exists, make an explicit request with curl -x to distinguish the local proxy entry point from system-proxy configuration. If the explicit proxy works but the browser fails, the problem is in system or browser settings. If the explicit proxy also fails, return to the core, node, and logs.
# 将 7890 换成客户端实际端口
curl -I -x http://127.0.0.1:7890 https://example.com
# Windows
netstat -ano | findstr :7890
# macOS / Linux
lsof -nP -iTCP:7890 -sTCP:LISTENInvestigate DNS only when resolution behavior is abnormal
If a domain has no target address, nslookup fails, or disabling browser secure DNS changes the result, inspect the resolution path. Temporarily disable browser DoH for comparison, then check the paths actually used by the OS and Clash and whether nameserver is reachable. Disabling one toggle does not automatically give them the same resolution settings.
After recovery, decide whether to re-enable the browser’s independent resolution. When router and browser resolution coexist, Clash may not receive the full domain name.
How to Distinguish Fake-IP Addresses from Stale Cache
In Fake-IP mode, a domain resolving to an address such as 198.18.0.0/15 is usually normal: the app connects to the virtual address first, then Mihomo restores the domain and evaluates rules. Seeing 198.18.x.x does not itself mean DNS poisoning. What matters is whether the connections page retains the original domain and matches the intended policy.
The real problem occurs when the system and app retain old results after switching configurations, changing rules, or moving from Redir-Host to Fake-IP. Close the test app, clear the system DNS cache, restart the Mihomo core, and test again. Do not retain old connections while repeatedly switching enhanced modes.
If a NAS, printer, router dashboard, or corporate internal domain must return a real intranet address, add it to the current configuration's fake-ip-filter or send it to the appropriate internal DNS. Verification should show that these local domains still resolve to real LAN addresses while public domains reappear by name on the connections page and route correctly.
ipconfig /flushdnsAfter the request enters the client, separate rule, node, and TUN issues
The request times out after matching DIRECT
Common cause:An unintended direct rule may match, or the local network or destination service may be unreachable
Resolution:First check whether the request should connect directly. Only if it should use a proxy, place the precise rule before GEOIP and MATCH, then repeat the same request.
The request matches a proxy group but reports dial timeout
Common cause:The current node, protocol, or remote endpoint is unreachable
Resolution:Compare against another known-working pinned node without changing DNS first.
The local proxy reports connection refused
Common cause:The port is not listening, or the system proxy is configured incorrectly
Resolution:Check mixed-port, process status, and port conflicts.
All connectivity fails only under TUN
Common cause:Service permissions, default route, virtual adapter, or another VPN conflict
Resolution:Restore the system proxy and check each item separately; do not reset the entire computer's network.