Clash Is Connected but There Is No Internet: Troubleshooting DNS, Fake-IP, and Rules

The same “Clash is connected” message may mean only that the core process is running; it does not prove that the system-proxy port works, the node is reachable, or DNS is healthy. Record one specific error, one destination address, and the current mode to establish a starting point.

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.

Then disable the system proxy to restore direct access and confirm that the underlying network works. If direct access also fails, address the Wi-Fi, broadband connection, corporate authentication, or router first. Clash cannot repair an underlying connection that has no internet access.

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.

If the request appears, record the destination, matched rule, policy group, and error. Unexpected DIRECT, REJECT, timeout, and connection refused results point to different layers. The tray icon's color omits the most useful evidence.

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.

Give DNS priority only when a domain request lacks a destination address for a long time, nslookup fails, or disabling browser secure DNS changes the behavior. First route the browser, system, and Clash through one resolution path, then check whether nameserver is reachable.

If the system uses router DNS while the browser independently enables secure DNS, Clash may not receive the complete domain. During troubleshooting, temporarily disable browser DoH so a domain follows only one resolution path from the system to Clash; afterward, decide whether to enable it again.

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.

The final diagnosis should fit in one concrete sentence—for example, “the request entered Clash, matched PROXY, and the fixed node returned dial timeout”—rather than “the app is green but there is no internet.” That sentence already identifies the layer to address next.