Clash for Android Connected but No Internet? Troubleshooting Checklist

1. Check whether the VPN is running and traffic can get through

“Connected” only means the client’s local service or VPN tunnel is running. It doesn’t guarantee that the node, DNS, or routing rules are working. Stop Clash and confirm your phone can access the internet on its own. Start the service again, then check each step: traffic capture → rule match → node connection → destination lookup and access. Change one setting at a time so you can tell what fixed the issue.

1. Stop the client and use your browser to open a site that normally works without a proxy. If it still fails, troubleshoot Wi-Fi, mobile data, account status, or public Wi-Fi sign-in first.
2. Test on both Wi-Fi and mobile data. If only one network fails, check its sign-in requirements, DNS, routing restrictions, and connectivity to the node’s port.
3. Start Clash and open the same address in the same browser. Note whether all sites fail, only sites that should use the proxy fail, or just one app is affected.
4. Note the test time, active configuration, mode, and selected node, then check the logs from that time.

2. Check Android VPN permission and conflicts

In Clash for Android, select a configuration, return to the main screen, and start the service. The first time, Android prompts you to approve the VPN connection. The VPN icon in the notification bar is a useful clue, but also check Android’s VPN settings to see which app owns the active connection.

What to check in Android settings

• On stock Android, go to Settings → Network & internet → VPN. Menu names vary by manufacturer, so you can also search Settings for “VPN.” Make sure the active connection belongs to the client you’re troubleshooting.
• Usually, only one app at a time can hold the VPN interface for an Android user or profile. Stop other VPNs, local VPN-based filtering apps, and packet capture tools, then restart Clash.
• Open the settings for the VPN and check “Always-on VPN” and “Block connections without VPN.” During troubleshooting, you can temporarily turn off the latter to prevent Android from blocking network access when the client stops. Restore it afterward if needed.
• If you use a work profile or app cloning, make sure the affected browser and Clash are in the same profile. Don’t assume a VPN in your personal profile also handles traffic from your work profile.

If Android’s VPN permission prompt never appears, stop the service and start it again, then check for other active connections in Android’s VPN list. Repeatedly tapping Connect won’t fix a VPN interface already in use by another app.

3. Check the configuration, proxy mode, and selected policy

Go to Profiles and make sure the active configuration is the updated one and loads successfully. A successful subscription update doesn’t mean every node works, and importing a profile doesn’t necessarily activate it. Return to the main screen to verify the profile name, then open Proxies to check the current mode and policy groups.

Select a node manually under Proxies to prevent an automatic selection group from switching exits during the test. If Global works but Rule fails, focus on the rules and policy groups instead of reinstalling the client. If both fail, check the node, DNS, and VPN traffic capture.

Trace the policy group to its final exit

A group name in the configuration is just a label. For example, a select group may point to an automatic selection group, which then chooses the node. Expand the relevant policies and follow them to the final exit. Check that you haven’t selected DIRECT, REJECT, or an unavailable node by mistake. After switching nodes, start a new connection; existing web connections may not immediately use the new exit.

4. Treat latency tests and website access as separate checks

A latency result only shows how the node performs against the test address. A result of 180 ms doesn’t guarantee that the destination’s HTTPS connection, account sign-in, or video requests will work. A timeout may also mean the test address itself is unreachable. Don’t treat a single number as proof of end-to-end connectivity.

1. Select node A manually, run the client’s latency test, then open the destination in a new browser tab.
2. Switch to node B and repeat the same steps. If possible, try a different route rather than another node on the same route.
3. If every node fails, stop the service, switch between Wi-Fi and mobile data, then start it again and retest.
4. Check your phone’s date and time settings and enable automatic time. A significant clock error can cause TLS certificate validation to fail.

In the logs, connection refused usually means the destination or an intermediate device rejected the connection. i/o timeout means the request timed out; it doesn’t prove the password is wrong. If unknown fields or protocol errors appeared after a subscription update, check whether the client’s core supports that configuration. The original Clash and Clash Meta (now called mihomo) don’t support exactly the same configuration features.

5. Check DNS hijacking, Private DNS, and browser lookups

DNS failures can leave the VPN connected and node latency looking normal while websites remain inaccessible. Check the logs for lookup, DNS, no such host, or DNS timeouts, then review the configuration’s dns section. Don’t replace every DNS server at once.

Check each step in the DNS lookup path

1. Search Android Settings for “Private DNS.” If a strict provider hostname is configured, note its current value and temporarily switch to “Automatic” for comparison.
2. Check the browser’s “Use secure DNS” setting. A browser may resolve names over HTTPS, so its DNS traffic might not be affected by ordinary port 53 interception.
3. Check the client’s VPN and DNS settings along with the configuration file. Android clients may manage DNS interception through the app interface or use the core’s TUN settings. Don’t assume a YAML entry is active just because it’s present.
4. After making a change, stop and restart the service, close existing tabs, and test again. Restart the browser if needed to avoid interference from old connections or app caches.

Traditional DNS typically uses UDP or TCP port 53; DNS over HTTPS usually uses port 443. Intercepting port 53 alone doesn’t capture all encrypted DNS traffic. The example below shows the DNS hijacking entry in a mihomo TUN configuration that supports the relevant fields. It is not a complete configuration to paste directly into the original Android client:

tun:
  enable: true
  dns-hijack:
    - any:53
    - tcp://any:53

You’ll also need to check the core version, routing, and settings such as dns.enable. An Android client may capture traffic through its own VPN service; the VPN toggle in the interface is not interchangeable with the core’s tun.enable setting.

fake-ip doesn’t mean DNS resolution failed

In fake-ip mode, a domain may be mapped to an address in the default 198.18.0.0/16 pool. This is expected behavior; an unfamiliar-looking address alone doesn’t indicate a problem. Check whether subsequent connections are still handled by the same core. After switching between fake-ip and redir-host, restart the service and affected apps so they don’t keep using old mappings or cached results.

If only a few apps are affected, back up your configuration before comparing modes. Don’t treat switching to redir-host as a universal fix for DNS problems. Also avoid testing with a website’s IP address alone: HTTPS certificates and virtual hosts often rely on the correct domain name.

6. Check app access and rule matches

If only one browser or app is affected, first check whether the VPN captures its traffic. In Clash for Android, manage which apps are included under Settings → App access; other clients may call this “per-app proxy.” Check whether the mode is “include selected apps only” or “exclude selected apps”—the same checked box means the opposite in each mode.

• Proxy only selected apps: The browser must be selected, or it will use the system’s direct connection.
• Bypass selected apps: Checked apps, including the browser, won’t use the proxy. Make sure the browser wasn’t selected by mistake.
• Block connections without VPN: Combined with app exclusions, this may prevent excluded apps from accessing the internet. Check the Android system setting as well.

Next, open Logs or the client’s connection list, then reload the failing page. If you see the connection and its rule match, at least some of the app’s traffic is reaching the core. If there’s no record at all, check the log level, app access, and VPN traffic capture before changing the node password.

Rules are typically evaluated from top to bottom, and the first match determines the exit. The example below sends a specific domain directly and routes everything else to a policy named PROXY. The actual configuration must include that policy group:

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

If the failed connection matches REJECT, check the blocking rules above it. If it incorrectly uses DIRECT, review the domain rules, rule providers, and final fallback. A webpage may also load images, sign-in pages, and API requests from separate domains. If the homepage loads but sign-in fails, inspect the failed request’s connection instead of adding a rule for the homepage domain alone.

7. If the connection drops when the screen locks, check battery and background settings

If the connection works at first, fails a few minutes after the screen locks, and recovers when you open the client, background restrictions are a likely cause. Go to Android Settings → Apps → the client → Battery, then allow background activity or select “Unrestricted,” depending on the options available. Some manufacturers also require you to allow autostart in their battery management settings.

1. Check that background data is allowed for the client. If Data Saver is on, make sure it isn’t blocking the client’s background access.
2. Check notification permission under Settings → Notifications. An ongoing notification helps you monitor the service, but a visible notification doesn’t guarantee Android won’t stop the process.
3. Test with the screen on, then lock it for five minutes and try again. Note whether the service notification, VPN icon, or logs disappear.
4. Test switching from Wi-Fi to mobile data and back again. If the connection only fails after switching networks, reconnect the service and check that the connection is re-established.

If changing background permissions fixes the problem, restore unnecessary exceptions one at a time and keep only the settings that actually affect the client. There’s no need to disable every battery-saving feature on your phone for a proxy client.

8. Use test results to choose the next step instead of reinstalling repeatedly

If you still can’t find the cause, save the relevant logs from about 30 seconds before and after the failure. Also note the Android version, client version, core name, network type, proxy mode, and test results. A report like “Rule mode fails, Global works, and the issue reproduces on mobile data” is much more useful than “Connected but no internet.”

If the configuration requires features your older core doesn’t support, back up your configuration and choose a client that supports the required protocols. For installation, importing a profile, and initial VPN permission, see the Quick Start Guide. For configuration fields and modes, see the full documentation. Keep your test results before switching clients so you don’t have to start troubleshooting from scratch.