Clash Connected but No Internet? An Eight-Step Troubleshooting Checklist

Troubleshoot this type of failure from the outside in along the network path: basic connectivity, remote nodes, device time, rule selection, DNS, the proxy entry point, and TUN interception. Only then inspect the configuration and core logs. Change one variable at a time and test again immediately. If you switch nodes, change DNS, and enable TUN together, it becomes difficult to identify the actual cause.

Step 1: Stop Clash and verify the underlying connection

Stop the proxy service first instead of merely switching from “Rule” to “Direct.” On Android, turn off the running switch on the main screen and confirm that the VPN indicator disappears from the status bar. On Windows or macOS, also disable the system proxy so requests are not still sent to a local port after the core stops.

1. Stop Clash or the mihomo core.
2. Disable the system proxy and TUN mode.
3. Disconnect and reconnect to the current Wi-Fi, or toggle Airplane mode once.
4. Open a regular webpage you have not visited before to avoid a false result caused by browser cache.
5. Test Wi-Fi and mobile data separately, and note which connection fails.

If no webpage loads even after Clash is stopped, the problem is upstream. Common causes include an incomplete captive-portal login on Wi-Fi, router DNS problems, restricted mobile data, or a network that only provides local access. On public Wi-Fi, open a regular HTTP page to trigger the sign-in portal. Proxy troubleshooting only makes sense after direct access works again.

Step 2: Switch nodes to distinguish a healthy subscription from a usable node

A subscription updating successfully does not mean every node in it can connect. An update is usually just one HTTPS request, while proxy access also depends on DNS resolution, TCP or UDP handshakes, TLS time validation, protocol parameters, and the remote service status.

Run a latency test before testing real access

On the “Proxies” page, find the current proxy group and run a latency test on at least three different routes. The test URL is usually set by the configuration’s url, such as https://www.gstatic.com/generate_204. Interpret the results as follows:

• 80–300 ms: The node completed the test request, but that does not mean every website will be reachable.
• Over 800 ms: The route is clearly congested, indirect, or lossy, so real requests may time out frequently.
• timeout: The request did not finish within the test window; switch nodes first.
• 0 ms, a blank result, or an immediate failure: The test URL, DNS, permissions, or core status may be abnormal.

Do not keep clicking within the same automatic selection group. Manually choose two nodes from different regions and with different server names, then test webpages through each. If one node works while the others fail, the problem is on the route side and the client does not need to be reinstalled. If every node times out, continue by checking the device time and DNS.

Make sure the policy group is not set to DIRECT or REJECT

The main selection group may be named “Node Selection,” “Proxy,” or something else. Open it and confirm that the current choice is not DIRECT, REJECT, or an expired child policy group. An automatic policy group may retain the result of an earlier test, so after switching manually, wait about 5–10 seconds before testing again.

Step 3: Correct the system time and time zone

TLS certificate validation depends on an accurate system clock. If the device date is off by hours or days, node handshakes, subscription updates, and HTTPS pages may all fail. Common log messages include certificate has expired, not yet valid, and TLS handshake failed.

On Android, go to “Settings” → “System” → “Date & time” and enable “Set time automatically” and “Set time zone automatically.” On some devices, the path is “Settings” → “Additional settings” → “Date & time.” After enabling them, wait for the carrier or network time to sync, then fully stop and restart Clash.

Desktop systems also need time synchronization checked. In Windows, go to “Settings” → “Time & language” → “Date & time” and select Sync now. The time zone should match your location; for example, China Standard Time is usually shown as UTC+08:00. Manually setting the clock approximately correctly is not the same as synchronizing it. Even a few minutes of drift can affect some short-lived certificates or authentication requests.

Step 4: Switch proxy modes to isolate rule-matching problems

Common Clash modes include rule, global, and direct. Rule mode evaluates the configuration’s rules from top to bottom and sends a match to the assigned policy group. Incorrect rule order, renamed policy groups, or a missing final rule can make specific websites unreachable.

Use Global mode for a short comparison test

1. Record the current mode and selected node.
2. Switch the mode from “Rule” to “Global.”
3. In the global policy group, manually choose a node with normal latency.
4. Open the target webpage again instead of only refreshing an old tab.
5. Switch back to “Rule” after testing to avoid unnecessarily widening the proxy scope.

If Global mode works but Rule mode does not, the node and basic connection are probably fine; the problem is in the rules or policy group. Open the “Connections” log and inspect the target domain’s Rule, Rule Payload, and Chains. If the traffic is routed to DIRECT, check whether a higher-priority direct rule is overriding the domain rule.

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

Rules are evaluated from top to bottom, and the first match takes effect. The end usually needs a catch-all rule such as MATCH,PROXY. Policy group names must exactly match those in proxy-groups, including capitalization and spaces. Avoid making broad edits directly to subscription-generated configurations. Prefer the client’s override feature and keep the original subscription as a fallback.

Step 5: Check DNS resolution and Fake-IP mappings

Focus on DNS when webpages report that the server cannot be found, every node latency test fails, or an IP address works while its domain does not. Clash Meta, the mihomo core, commonly supports fake-ip and redir-host modes. Fake-IP first returns a mapped address to the application, then the core uses that mapping to handle the real domain, so DNS requests must actually pass through Clash.

Clear caches, then restart the DNS path

• Stop Clash and wait about 5 seconds.
• On Android, toggle Airplane mode once, or disconnect and reconnect to Wi-Fi.
• Clear the browser’s DNS cache. The simplest method is to fully quit the browser process and reopen it.
• Start Clash again, then visit a domain you have not tested before.

Android’s “Private DNS” can also change the resolution path. Go to “Settings” → “Network & internet” → “Private DNS” and temporarily set it to “Automatic” for comparison. On some devices, the menu may be “Connection & sharing” → “Private DNS.” If the specified encrypted DNS host is unreachable on the current network, applications may wait a long time for a resolution result.

Check the key DNS settings

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
  fallback:
    - tls://1.1.1.1:853

The listen port must not be occupied by another program. The 1053 value above is only a common example; the actual configuration may use a different port. If the log shows address already in use, there is a port conflict. Encrypted DNS addresses also depend on whether the network allows the relevant port: DoT usually uses 853, while DoH usually uses 443.

Step 6: Verify the system proxy address, port, and listening status

On desktop systems, a common problem is that the Clash core is running normally while the system proxy still points to an old port. The typical mixed port is 7890, and the SOCKS port may be 7891. However, both subscriptions and clients can change these values, so do not rely on defaults alone.

Open the client’s “Settings” → “Preferences” or “General” page and note mixed-port, port, and socks-port. Then verify that the operating system proxy points to 127.0.0.1 and the same port. If the client only listens on SOCKS while the system HTTP proxy is configured to use that port, some applications will fail immediately.

A terminal can use an explicit proxy request to bypass the system proxy settings and verify that the local entry point works. The following command assumes the mixed port is 7890:

curl -I --connect-timeout 10 \
  -x http://127.0.0.1:7890 \
  https://example.com

If the explicit proxy request succeeds but the browser fails, the problem is most likely in the system proxy or the browser’s own settings. If the command immediately returns “connection refused,” nothing is listening on that port; check whether the core is running and whether the port was changed. If the request hangs and eventually times out, the local port may be working, but the node, DNS, or outbound connection still has a problem.

A working browser with a failing terminal command does not necessarily indicate a Clash problem. Many command-line programs do not automatically read the operating system proxy. Set HTTP_PROXY and HTTPS_PROXY, or specify the proxy explicitly in the command arguments.

Step 7: Check TUN mode, VPN permissions, and app conflicts

On Android, Clash usually creates a local VPN interface through the system VpnService. Granting connection permission only means that the interface can be created. If the system revokes permission, battery-saving rules stop the background service, or another VPN app occupies the interface, the UI may remain active briefly while traffic can no longer be forwarded correctly.

1. Stop other VPN, network-filtering, and firewall apps.
2. Disconnect the old connection in Android’s VPN settings.
3. Return to Clash, restart the service, and confirm the system connection request.
4. Disable TUN first and test using the client’s default VPN interception method.
5. On desktop systems, test in the reverse order: after confirming that the system proxy works, enable TUN to handle applications that do not read proxy settings.

Desktop TUN mode creates a virtual network adapter and adjusts routes. Common mihomo parameters include stack: mixed, auto-route: true, and auto-detect-interface: true. If the device is connected to wired Ethernet, Wi-Fi, a virtual-machine adapter, and a corporate VPN at the same time, automatic interface detection may select the wrong route.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

During troubleshooting, disable TUN first and use the system proxy to verify whether HTTP and HTTPS access returns. If the system proxy works but enabling TUN causes failure, focus on route creation, virtual-adapter permissions, the current default gateway, and conflicts with other VPNs. Do not treat “Enable TUN” as a universal fix: it changes the scope of traffic interception, but it cannot repair a dead node or incorrect DNS.

Step 8: Read the logs, roll back the configuration, and re-import the subscription

If the first seven steps do not identify the cause, inspect the configuration and runtime logs. Set the log level to info, reproduce the problem once, and check the latest entries immediately. Use debug only briefly when the information is insufficient, because detailed logs grow quickly and make key errors harder to filter.

Log excerpt	Check first
i/o timeout	Node unreachable, packet loss, or blocked outbound traffic
connection refused	Target port is not listening, or the remote service refused the connection
no such host	DNS resolution failed, or the upstream DNS server is unreachable
address already in use	Local proxy or DNS port conflict
authentication failed	Node credentials, UUID, password, or subscription data are invalid
certificate-related errors	System time, certificate chain, or TLS parameters

If the problem began after a subscription update, switch first to a local configuration that worked before the update. When multiple configurations coexist, confirm that the active Profile is the one you just inspected. Then fetch the subscription again and check the update time and configuration parsing result. If parsing fails, do not continue using a partially loaded configuration. Restore the old one or ask the subscription provider to confirm the configuration format.

Manual overrides are another frequent source of failures. Check dns, rules, proxy-groups, tun, and the port fields carefully. YAML is indentation-sensitive, so use spaces consistently to preserve the hierarchy. A policy group referencing a nonexistent node, a rule pointing to a missing policy group, or the same port being defined twice can cause startup failures or disable some features.

Final minimal recovery sequence

1. Export or record the current configuration name, ports, and key overrides.
2. Disable TUN, Private DNS, and the browser’s independent DNS.
3. Import a subscription configuration confirmed to parse correctly.
4. Choose a node with normal latency.
5. Test in Global mode first, then switch back to Rule mode.
6. After basic proxy access returns, re-enable DNS overrides and TUN one at a time.

Retest standard: do not rely on a single page refresh

After making a fix, run at least three types of tests. First, open HTTPS pages on two different domains. Second, switch once between Wi-Fi and mobile data to confirm the service can rebuild the connection after the network changes. Third, inspect the “Connections” log to verify that the target domain matches the expected rule and node. A single successful latency test only shows that the test URL was reachable at that moment.

On Android, lock the screen for about 3–5 minutes, then unlock it and open a webpage. If access fails only after the screen locks, investigate background-running permissions, battery optimization, and the manufacturer’s power-saving policy instead of continuing to change node protocols. On desktop systems, restart the browser or terminal to ensure old proxy connections and DNS caches have been released.

The goal of complete troubleshooting is not merely to make the status button say connected again. It is to confirm a repeatable path: the device gets basic connectivity, DNS resolves, traffic enters the correct proxy entry point, rules select the intended policy group, the node establishes an outbound connection, and the response returns through the same path to the application. Verifying each layer along this path usually narrows the problem to a clear scope within eight steps.