Clash Connected but No Internet on Android? A Step-by-Step Troubleshooting Checklist

A VPN key icon in the Android status bar only shows that Clash has VPN permission and its service is running. It does not confirm that your subscription is valid, a proxy is reachable, or DNS is working. If the interface says “Connected” but the internet is still unavailable, traffic has usually entered the client and then stopped at the proxy, rules, DNS resolution, or app routing layer.

Do not change several options at once. First define the scope of the problem, then work through the sequence: “network basics → configuration → proxies → proxy groups → DNS → TUN and system settings → app routing.” Reopen the test page after each step and record the result. This prevents a temporary recovery from hiding the real cause.

Step 1: Determine whether the proxy or the phone’s internet connection is at fault

Run tests with Clash off and on

Stop the service from Clash’s main screen and wait for the VPN icon to disappear. Then use both Wi-Fi and mobile data to open two websites that normally work. If they still cannot be opened with Clash off, the proxy configuration is not the cause. Check the router, mobile network, Airplane mode, account status, or system network restrictions first.

Stop the Clash service and test a regular webpage and a messaging app over Wi-Fi.
Turn off Wi-Fi, switch to 4G or 5G, and repeat the test.
Start Clash again and retest on the same network only.
Record whether “all apps are offline,” “only the browser is offline,” or “direct connections work but proxied destinations do not.”

The scope of the outage determines the next branch. If every app is offline, check invalid proxies, DNS, VPN conflicts, and an incorrect global route first. If only one or two apps fail, inspect app routing, bypass lists, and that app’s dependence on QUIC, IPv6, or particular certificate behavior. If direct websites work but proxied destinations fail, the proxy or proxy group is usually responsible.

Use an IP address and a domain name to isolate DNS issues

A domain must be resolved to an IP address first; connecting by IP skips DNS resolution. Try opening a router address such as 192.168.1.1 in your browser. If the local IP opens but every domain fails, DNS should be your first check. Do not treat a public-IP test as conclusive, because some websites reject direct IP access.

Symptom	Check first	Lower priority
Still offline with Clash disabled	Wi-Fi, mobile data, and system networking	Proxy groups and rules
Direct access works, proxied destinations fail	Proxies, subscription, and group selection	Phone hardware
IP reachable, domain fails	DNS, Private DNS, and Fake IP	Proxy latency ranking
Only one app fails	App routing, bypass rules, and UDP	The entire subscription is unusable

Step 2: Check whether the subscription and configuration are actually active

Make sure the selected configuration is not an old copy

Many issues occur because a subscription updated successfully while the client is still running a different local configuration. In the common Clash Meta for Android interface, open “Profiles” and check the selected marker, update time, and filename beside the active profile. If several profiles have similar names, verify their sources one by one instead of relying on the top entry.

Check that the subscription has not expired and that its traffic allowance has not been exhausted.
In “Profiles,” update the current subscription and confirm that the interface reports success.
After updating, select the profile again, return to the home screen, and stop and start the service.
If the update returns 401, 403, or 404, check the subscription URL or account status.
If the update reports a YAML parsing error, restore the original configuration supplied by the provider and temporarily disable custom overrides.

Being able to download text from a subscription URL does not mean the content can run successfully. An empty proxy list, a proxy group referencing nonexistent proxies, or a failed rule-provider download can all leave the core running without forwarding traffic correctly. Open “Logs,” restart the service, and focus on the first 30 seconds after startup. Repeated proxy not found, no such host, timeout, or rule-set download errors point to the corresponding object.

Temporarily disable settings that may override the original configuration

The client’s override feature can change ports, DNS, rules, and operating modes. If an old override is incompatible with the new subscription structure, the subscription may be valid while the configuration ultimately passed to the mihomo core is still broken. Open “Settings” → “Overrides,” or the equivalent entry in your version, temporarily disable recently added DNS, rule, and script overrides, then reload the configuration.

Step 3: Verify the proxy and proxy-group selection

A latency result does not prove full usability

On the “Proxies” page, run a latency test for the active proxy group. In a single test, results around 80–250 ms are usually worth checking further. Persistent timeouts, or several proxies fixed at roughly 5000 ms, indicate that the test request received no response. A latency test checks only the test address; it does not prove that every TCP, UDP, or target domain is available.

After selecting a proxy, return to the home screen and watch live traffic. If upload and download remain at 0 B/s while opening a webpage, the app may not have entered the VPN, may be bypassed, or may not be under system control. A small amount of upload with download stuck at zero often indicates an unreachable proxy, a failed handshake, or a blocked return path. If both directions show traffic but the page keeps loading, continue with DNS, UDP, or app-protocol checks.

Select a fixed proxy manually to rule out automatic groups

Open “Proxies” and find the proxy group actually referenced by the rules, such as PROXY, 节点选择, or a provider-defined group name.
Temporarily avoid 自动选择, 故障转移, and load-balancing subgroups.
Choose a specific proxy that returned a latency result.
Test two different websites continuously for at least 30 seconds.
Then switch to a proxy in another region or using another protocol and test again.

If a fixed proxy works but the automatic group does not, check the automatic test URL, tolerance settings, and candidate proxies in that group. If every proxy fails, do not keep switching among similar entries from the same region. Check the subscription, whether the network blocks the relevant ports, and handshake errors in the logs.

Check the operating mode

Common Clash modes include Rule, Global, and Direct. You can switch briefly during troubleshooting, but interpret the results carefully:

Rule mode: Traffic is matched against rules and sent to a direct, proxy, or reject policy. This is the usual choice for daily use.
Global mode: Most traffic is sent to the global proxy group. If that group still points to a dead proxy, changing modes will not restore access.
Direct mode: Used to verify whether the client can send traffic directly after taking control; it does not test proxy availability.

If Rule mode fails but Global mode works, the proxy has basic connectivity and the next step is to inspect rule matching. Open “Logs,” visit the failing destination, find its connection record, and confirm which proxy group handled it. If the destination was incorrectly sent to DIRECT, REJECT, or a dead group, adjust the rule source or override instead of changing the proxy port.

Step 4: Troubleshoot DNS, Private DNS, and Fake IP

Resolve Android Private DNS conflicts first

Android Private DNS uses encrypted resolution. On some networks, failure to reach the specified Private DNS host makes Wi-Fi appear connected while domains refuse to open. Go to system “Settings” → “Network & internet” → “Private DNS,” temporarily choose “Automatic” or “Off,” and restart Clash. On some devices, this option is under “Connection & sharing” or “More connection settings.”

If access returns immediately after disabling Private DNS, the original Private DNS host is incompatible with the current network or Clash’s DNS interception path. Keep only one resolution chain in charge: either Android Private DNS or mihomo’s DNS module. Avoid forcing both systems to override each other.

Check the DNS configuration fields

A common DNS structure in mihomo configurations looks like this. The addresses only illustrate the relationship between fields and should not be pasted over an entire subscription configuration.

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

enable controls the core DNS module; listen is the local listening address; enhanced-mode commonly uses fake-ip or redir-host. With TUN enabled, also make sure DNS hijacking matches the listening port. If requests are redirected to 1053 while the DNS module is not listening there, domain requests will be sent to nowhere.

Compare redir-host with Fake IP for compatibility

Fake IP returns reserved addresses for domains, then the core forwards traffic using the mapping. It usually provides consistent rule matching, but some LAN devices, banking apps, screen-casting tools, and apps that depend on special DNS responses may be incompatible. Typical symptoms include most websites working while one app cannot sign in, local domains fail, or device discovery breaks.

Copy the configuration and temporarily change enhanced-mode from fake-ip to redir-host for comparison. If the issue disappears, add a Fake IP filter for the affected domains instead of permanently disabling enhanced resolution everywhere. Reload the configuration and restart the service afterward; simply returning to the home screen usually will not invalidate old mappings immediately.

Step 5: Resolve conflicts between TUN, system VPN, and manual proxies

Make sure only one VPN service is active

Android’s VPN interface can normally be occupied by only one app. If another VPN, firewall, traffic filter, or work-profile VPN takes over after Clash starts, the client may continue showing as active briefly even though system traffic is no longer passing through it. Go to system “Settings” → “Network & internet” → “VPN” and confirm that the connected entry is the Clash client you are using.

Stop other apps that use Android VPNService.
Turn off “Always-on VPN” for other VPN profiles.
During troubleshooting, disable “Block connections without VPN.”
Authorize Clash’s VPN request again and watch the status-bar icon.

“Block connections without VPN” is useful once the setup is stable. During troubleshooting, if the Clash service crashes, the configuration fails to load, or Android reclaims it, this option blocks all networking and can make the problem look like a dead proxy.

Remove a leftover manual proxy from Wi-Fi

Some users enter 127.0.0.1 and 7890 in Wi-Fi advanced settings. If the client now uses TUN/VPN interception, or the local mixed-port has changed, this manual proxy sends browser traffic to a port with no listener. Open system “Settings” → “Wi-Fi” → “Current network” → “Proxy” and set it to “None” during troubleshooting.

Port 7890 is often used as a mixed-port, 7891 is commonly used for SOCKS or redirect configurations, and 9090 is often used for the external control interface. Actual values depend entirely on the current configuration. Do not infer local listening status from conventional ports; check the client settings or logs.

Switch the TUN stack for compatibility testing

mihomo’s TUN implementation may offer system, gVisor, or mixed stacks, depending on the client version and system support. If all connections suddenly time out after updating Android or the client, open the relevant “Settings” → “Network” → “TUN” entry, note the current value, then test another supported stack.

After switching, stop the service completely, wait 5 seconds, and start it again. Changing the toggle while the service is running may leave the old VPN interface and connection cache in place. If TCP works on one stack but voice calls, games, or HTTP/3 fail, check UDP support before concluding that the proxy itself is unusable.

Step 6: Check app routing, bypass lists, and battery restrictions

Inspect app routing when only certain apps are offline

App routing determines whether an Android package enters the VPN. Allowlist mode intercepts only selected apps, while blocklist mode bypasses selected apps. Reversing these modes can make the browser work while the target app never uses the proxy, or leave only a few apps online.

Open Clash “Settings” → “Network” → “App routing,” or the equivalent entry in your version.
Confirm whether the current logic is an allowlist or a blocklist.
Temporarily disable app routing so all regular apps enter the VPN.
Restart the service and test the app that previously failed.
When restoring routing, add apps one at a time instead of importing a large package list.

Work profiles, cloned apps, and dual-app installations may use different UIDs. Selecting an app in the main profile does not mean its work-profile copy follows the same rule. If only a cloned app fails, check VPN permissions and the app list in the corresponding user profile.

Check LAN bypass rules and excluded routes

To keep printers, screen casting, and router administration available, configurations often bypass private ranges such as 192.168.0.0/16, 10.0.0.0/8, and 172.16.0.0/12. If a remote service also uses these ranges, an overly broad bypass sends traffic directly through the local interface and it fails.

Conversely, sending all LAN traffic through a remote proxy can make the router admin page and local devices unreachable. Check the outbound policy for the destination IP in the logs. Private addresses should normally use DIRECT; internal addresses that require remote access should follow the actual network design.

Remove system restrictions on background services

Some Android builds restrict background VPN services after the screen locks, making everything work at first and then all connections stall after a few minutes. Go to system “Settings” → “Apps” → “Clash client” → “Battery,” choose “Unrestricted” or allow background activity. Then open “Mobile data & Wi-Fi” and allow background data and unrestricted data usage.

If the issue appears only 5–10 minutes after the screen locks and disappears when the screen wakes, battery management is more suspicious than the proxy. Also check the manufacturer’s settings for autostart, background pop-ups, and locked-task permissions. Change one setting at a time and run a complete screen-lock test.

Step 7: Use logs for final diagnosis

Create a reproducible test record

When the logs are noisy, clear them or note the current time, then access only one failing destination. Record the following:

Network: Home Wi-Fi
Mode: Rule
Configuration updated: 2026-08-14 10:32
Proxy group: PROXY → Node A
Test time: 10:36:20
Symptom: Domain timed out after 15 seconds
Log keywords: DNS timeout / connection refused

A complete connection record usually answers three questions: Was the domain resolved, where did the rules send the connection, and at which stage did the outbound connection fail? timeout means the wait expired and may indicate that the proxy, destination, or intermediate network is unreachable. connection refused means the peer actively rejected it. network unreachable often points to routing, an interface, or IPv6. TLS handshake errors require checking the clock, SNI, protocol parameters, and network interference.

Use a minimal configuration to separate client issues from subscription issues

If the steps above do not identify the cause, use the original subscription supplied by the provider, disable custom overrides, app routing, and extra rules, and test with one fixed proxy only. If the original configuration works, the problem comes from a local change. If it still fails but the same subscription works on another network, focus on the current network environment. If it fails across multiple devices and networks, contact the subscription provider to verify proxy status.

Do not change the client, subscription, network, DNS, and proxy at the same time. Change one variable, then complete at least one startup, one domain-access test, and one log review. For “connected but no internet” problems, consistent reproduction is more valuable than repeated reinstalls.

Troubleshooting results at a glance

Test result	Likely cause	Next step
Access returns when Clash is disabled	Configuration, proxy, DNS, or VPN interception issue	Continue through this guide in order
Fixed proxy works, automatic group does not	Automatic-group candidate or health-check issue	Adjust group members and health checks
Global mode works, Rule mode fails	Incorrect rule match or proxy-group reference	Confirm the actual outbound route in the logs
Access returns after disabling Private DNS	Conflict in the system DNS path	Use a single DNS solution as the authority
Access returns after disabling app routing	Incorrect allowlist, blocklist, or UID selection	Rebuild a minimal app list
Access returns after switching to mobile data	Wi-Fi restriction or routing issue	Check router DNS, IPv6, and port policies
Fails after the screen locks	Battery management reclaimed the background service	Allow background operation and unrestricted battery use