Clash Connected but No Internet: A Step-by-Step Troubleshooting Checklist

When Clash shows “Connected,” it usually means the iOS network extension, TUN interface, or local proxy has started. It does not confirm that the subscription is still valid or that the current proxy group has selected a working node. A request still passes through DNS resolution, rule matching, the proxy group, and the remote node. Failure at any layer can look like Safari loading endlessly, an app reporting a network error, or only some websites being unreachable.

Do not change several settings at once while troubleshooting. First note the current configuration name and proxy mode, then retest with the same webpage after each step. Start by opening Safari and visiting http://captive.apple.com/hotspot-detect.html; a normal response usually displays “Success.” Then visit a familiar HTTPS website. Testing HTTP and HTTPS separately helps distinguish problems with the network entry point, DNS, TLS, or the proxy route.

Step 1: Confirm the problem appears only when Clash is enabled

Compare the connection with Clash off and on

1. Keep the current Wi-Fi or cellular network unchanged and turn off Clash’s proxy switch.
2. Open the two websites that previously failed in Safari, then refresh each once.
3. Turn Clash back on, wait five seconds for its status to stabilize, and visit the same addresses again.
4. Record whether the result is “works when off, fails when on” or whether both states fail.

If the connection still fails with Clash off, the problem is probably with the local network, your carrier connection, or the website itself. Check Airplane Mode, the Wi-Fi sign-in page, and cellular-data permissions first. Public Wi-Fi often requires authentication; temporarily turn off Clash, open any HTTP page to trigger the sign-in portal, complete authentication, and then enable the proxy again.

If browsing works with Clash off but fails immediately after it is enabled, continue in the order below. If only one app fails, go to iOS Settings → Cellular and confirm that both the app and the Clash client are allowed to use cellular data. Also check whether the app works only on Wi-Fi and whether the current Wi-Fi network requires portal reauthentication.

Step 2: Check that the subscription is valid and fully updated

A subscription appearing in the client does not mean its URL can still be fetched. Expiration, an invalid link, a login page returned by the server, or an interrupted update can leave the client using an old configuration. If every old node has stopped working, the interface may still show proxy groups and “Connected,” while actual connections time out.

Check the update time and result

• Open the client’s configuration or subscription page and confirm that the active profile is the one you expect, not an older locally imported copy.
• Check the last update time. If the provider has replaced its nodes but the local timestamp is several days old, run a manual update.
• After updating, confirm that the proxy groups still contain nodes. A group name with no selectable nodes usually means the subscription content is empty or failed to parse.
• For HTTP 401 or 403, check your subscription access and URL; for 404, obtain a new subscription link; for 5xx, wait for the server to recover and try again.

Do not delete the old configuration before updating. A safer approach is to keep it, create a new profile slot, and import the updated URL there. Switch only after it loads correctly. If the new subscription contains incompatible fields, you can quickly revert to the old profile and compare the differences.

Step 3: Confirm that the proxy group has selected a working node

Common Clash proxy group types include select, url-test, fallback, and load-balance. A select group requires manual selection; automatic testing groups depend on the test URL, interval, and node reachability. Node names appearing in a group only show that the configuration loaded—they do not mean the node handshake succeeded.

Use manual selection first to rule out automatic testing

1. Open the proxy groups page and find the main proxy group referenced by the final rule, such as “Proxy” or “PROXY.”
2. Do not switch nodes only inside a secondary region group. Confirm that the outermost main group is not set to DIRECT, REJECT, or an automatic group whose nodes no longer work.
3. Manually select one specific node, then test two or three nodes in different regions.
4. After each switch, wait three to five seconds before reopening the webpage so that reused connections do not lead to a false conclusion.

A latency test only shows that the test URL was reachable at that moment. A node showing 80 ms may still fail to reach the target website, lack UDP support, have TLS handshake problems, or use a restricted exit. Conversely, a test timeout may mean the test address is blocked while the node can still reach other sites. Check the actual webpage result and connection log together rather than relying on the latency number alone.

Recognize common connection errors

Step 4: Check the mode and rule match

In rule mode, requests are matched from top to bottom and stop at the first match. An overly broad DOMAIN-SUFFIX, IP-CIDR, or GEOIP rule can send a request to the wrong proxy group. The final MATCH or FINAL rule must also point to a real, working group.

Use global mode for a short comparison

Temporarily switch the mode from “Rule” to “Global,” then have the global policy use a node you have confirmed works. If the webpage loads, the node and basic proxy path are probably fine, and the problem is concentrated in rule matching or proxy-group references. If global mode also fails, continue checking the node, DNS, and system VPN layers.

Use global mode only to isolate the cause, not as the final fix. After identifying the issue, switch back to rule mode and open the connection log to find the policy and rule for the failed domain. For example, if the request matches DIRECT but the current network cannot reach the destination directly, adjust the rule order or replace the rule set. If it matches an empty proxy group, correct the group-name reference in the configuration.

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

The rules above send example.com and its subdomains to PROXY first, then send destinations matching GEOIP CN directly, while all remaining requests go to PROXY. If a broad direct-connection rule is placed before the target-domain rule, the later rule may never be reached.

Step 5: Distinguish a DNS problem from a proxy problem

Typical DNS failures make domains unreachable and apps report that the server cannot be found, while existing connections or a few services using fixed addresses may continue to work. Clash Meta (mihomo) commonly supports the enhanced modes fake-ip and redir-host. In an iOS TUN or network-extension environment, DNS requests may also be affected by system encrypted DNS, another VPN configuration, or LAN hijacking.

Check the log for resolution errors first

• no such host usually indicates a domain-resolution failure.
• context deadline exceeded may indicate an upstream DNS timeout, or that the upstream request must use an unavailable proxy group.
• If only local network domains fail, check whether they need to be resolved by the router’s DNS, such as 192.168.1.1.
• If switching networks fixes the problem, the original Wi-Fi network likely has a DNS, authentication, or UDP transport restriction.

If the client offers a Settings → Parameters → DNS-style menu, note the current values first. Then check whether DNS is enabled, whether the enhanced mode matches the configuration, and whether the upstream address is complete. Menu names vary by client. When the configuration is subscription-managed, edit an independent copy first so the next subscription update does not overwrite the change.

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

1053 is an example listening port and must not conflict with another local DNS service. Traditional DNS commonly uses UDP or TCP port 53, while DNS over TLS commonly uses port 853. Do not change nameserver, fallback, proxy-server-nameserver, and the fake-IP range at the same time without understanding the subscription structure. Replace one reachable upstream first and retest so you know which change made a difference.

If the iPhone has a separate encrypted-DNS profile installed, go to Settings → General → VPN & Device Management to inspect it. During troubleshooting, temporarily disable other DNS or VPN profiles and keep only the current Clash network extension. Restore the original settings after testing.

Step 6: Check the iOS VPN and TUN status

iOS generally allows only one primary VPN tunnel to take over traffic at a time. A corporate VPN, another proxy client, content filter, or security app may conflict with Clash’s network extension. A VPN indicator in the status bar only proves that some VPN configuration is active; it does not identify which configuration is currently handling traffic.

Verify the active configuration in System Settings

1. Open Settings → General → VPN & Device Management → VPN.
2. Confirm that the connected entry belongs to the Clash client currently in use.
3. Disconnect other VPNs and turn off on-demand connections in other proxy clients.
4. Return to Clash, turn the proxy off, wait five seconds, and turn it on again.
5. If it remains stuck connecting, restart the iPhone and launch only Clash. Do not open other network tools at the same time.

In TUN mode, the client must create a virtual network interface and take over the relevant traffic. Routing exclusions that are too broad may let requests bypass TUN; exclusions that are too narrow may disrupt access to LAN devices. If only a printer, NAS, or router admin page is unreachable, check that private LAN ranges remain direct, such as 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.

If the problem occurs only on cellular data, go to Settings → Cellular and confirm that the Clash client is allowed to use cellular data. On a dual-SIM device, also verify that the active data line is registered correctly. After switching the SIM data line, disconnect and recreate the VPN so the network extension receives a new default route.

Step 7: Use logs to pinpoint the failing layer

After the comparisons above, the log can usually narrow the problem to a specific stage. Open the client’s connection or log page, clear the old entries, and visit just one test domain. Record the time, domain, matched rule, proxy group, node name, and final error. Do not open multiple apps at once, or background requests will quickly bury the target entry.

Read the log by request stage

1. No request entries: Traffic may not be reaching Clash. Check the VPN configuration, TUN status, and app network permissions.
2. Domain shown but resolution fails: Check the DNS upstream, encrypted-DNS settings, and DNS-related logs.
3. A rule match is shown: Confirm that the matched proxy group is the one you expect.
4. A node is selected but the connection times out: Switch nodes and networks to determine whether the node is down or the current route is blocked.
5. TLS error after TCP connects: Check the system time, destination domain, node route, and certificate warning. Do not accept certificates from unknown sources.

If the client supports log levels, temporarily change info to debug while troubleshooting, reproduce the issue once, and switch it back immediately. Leaving debug enabled creates a large volume of entries and makes important errors harder to find. When reporting the issue, redact subscription URLs, credentials, node passwords, and personal domains; keep only the error type and necessary context.

Final checklist: Let the result guide your next step

• Clash cannot access the internet even when disabled: Start with Wi-Fi sign-in, cellular permissions, or the system network.
• The subscription update fails: Check subscription access, returned content, and configuration format.
• A manually selected node works but the automatic group does not: Check the test URL, group type, and test interval.
• Global mode works but rule mode does not: Inspect the request match and adjust the rule order.
• Domains fail and the log shows resolution timeouts: Check the DNS upstream and system encrypted DNS.
• There are no requests in the log: Check the active iOS VPN configuration and whether TUN is actually taking over traffic.
• Wi-Fi fails but cellular works: Check public-network authentication, router DNS, and port restrictions.
• Every node times out: Update the subscription and ask the node provider to confirm the route status.

The most effective troubleshooting order is to compare Clash off and on, verify the subscription and nodes, then check rules and DNS, and finally inspect the system VPN. Change only one variable at a time and retest with the same website. This prevents a node failure from being mistaken for a DNS problem and preserves reproducible clues instead of wiping every setting at once.