Clash Connected but No Internet? 8-Step Troubleshooting Checklist

Step 1: Turn Off the Proxy and Check Your Internet Connection

Turn off “System Proxy” and “TUN Mode” in the client, but leave the client open so you can restore your settings later. If you’re also running another VPN, proxy extension, or network accelerator, pause it to avoid having two tools manage your connection at once. Now try a website that normally works without a proxy to rule out Wi-Fi, broadband, or sign-in issues.

1. Check that your computer has a valid local IP address and default gateway, not just a Wi-Fi connection.
2. On public networks such as those in hotels or airports, complete the required web sign-in first. Don’t enter your credentials on a suspicious certificate warning page.
3. On the same Wi-Fi, turn off mobile data on your phone and test the connection. If needed, connect your computer to your phone’s hotspot for comparison.

If regular websites still won’t load with the proxy off, fix your basic internet connection first. If switching to a phone hotspot restores access, check the original network’s sign-in requirements, DNS, or access restrictions. Don’t assume every issue is caused by your subscription or nodes, and don’t conclude that the whole network is down just because one website won’t load.

Step 2: Check Your Subscription and Active Configuration

Open the client’s “Subscriptions” or “Profiles” page and check the selected profile, its last update time, and the update result. Menu names vary between clients; the key is to confirm that the downloaded configuration is active, not merely listed. A successful subscription update also doesn’t mean your plan still has data available.

• Check your plan: Visit your subscription provider’s account page to check the expiration date, remaining data, and device limits. If the interface doesn’t show data usage, don’t assume the plan is unlimited.
• Try updating manually: Look for HTTP 401, 403, or 404 errors, or a timeout. A 401 or 403 may indicate an authorization or access policy issue; a 404 may mean the URL is no longer valid. Check your provider’s guidance to confirm.
• Verify the loaded configuration: After updating, check that nodes and proxy groups are present. If the logs show a YAML parsing error, fix the configuration before testing; the old configuration may still be loaded.

Subscription URLs often contain access credentials. Don’t post them in public forums or include them in screenshots. If the subscription download fails but an existing profile still loads, use its nodes to continue troubleshooting. Downloading a subscription and connecting through a proxy may use different network paths.

Step 3: Test Nodes Instead of Relying on Latency

Open the “Proxies” page and identify the node currently selected by the active proxy group. Even if the group is called “Auto Select,” check which exit node it actually uses. Run the client’s latency test, then select a different node and try the same website again.

A Successful Latency Test Doesn’t Guarantee a Website Will Load

A latency test usually connects to a configured test URL; it only shows that the target was reachable at that time. A node may pass the test but fail to access a particular website. Conversely, restrictions on the test URL may make a working node appear to time out. One latency figure doesn’t tell you whether a node is fully usable.

1. Choose one URL and test it with node A, then node B, without changing any other settings.
2. Check the logs for connection timeouts, authentication failures, TLS handshake errors, or connection resets.
3. If only one node fails, try another node. If all nodes fail, continue by checking the local proxy listener and configuration.

If switching nodes fixes the problem, keep using the working node for now and don’t change DNS yet. Authentication errors usually call for checking your subscription or node settings. TLS errors may also involve the system clock, server certificate, or network path; disabling certificate verification is not a general fix.

Step 4: Make Sure the System Proxy Is Actually Working

Browser requests must reach the local proxy port before a node can help. In Windows 11, go to “Settings” → “Network & internet” → “Proxy” and check the manual proxy address and port. On macOS, go to “System Settings” → “Network” → “Details” for your current network → “Proxies” and check the HTTP and HTTPS proxy settings. After enabling the system proxy in your client, verify what the operating system actually shows.

Browser extensions can override system settings, and Firefox lets you choose a proxy independently. In Firefox, go to “Settings” → “General” → “Network Settings” → “Settings.” For troubleshooting, select “Use system proxy settings” and temporarily disable extensions that change proxy settings.

Isolate the Problem with an Explicit Proxy Request

The command below removes “is the browser using the system proxy?” from the equation by explicitly telling curl to connect to the local HTTP proxy. On Windows, use curl.exe; on macOS and Linux, you can use curl. The target website is only for testing; it doesn’t have to be reachable.

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

• Returns an HTTP response from the target site: The explicit proxy request reached the target. Even a 403 is different from a failure to connect to the local proxy.
• Only returns 200 Connection established: This may mean only that the proxy tunnel was established. Check whether the target site responds afterward.
• Reports that it can’t connect to 127.0.0.1: Check the port and whether the core is running, then go to Step 7.

If the command works but the browser doesn’t, check the browser’s proxy settings, extensions, and cached connections first. There’s no need to rewrite the entire configuration yet.

Step 5: Compare Global Mode with Rule Mode

Switch to “Global” mode, explicitly select a tested node in the global policy, and open the same URL. If it works in Global mode but not Rule mode, check rule matching, proxy group selection, and direct connections instead of assuming the node is broken. Restore your original Rule mode after testing.

Check the Actual Route in the Connection Log

Open the “Connections” page and refresh the website. Find the connection for the target domain and check the matched rule, policy chain, and final exit. A connection matching DIRECT goes straight to the destination; one matching REJECT may be blocked outright. Rules are usually matched from top to bottom, so a broad rule near the top can prevent more specific rules below it from taking effect.

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

This snippet illustrates rule order only: example.com and its subdomains connect directly; all other requests go to PROXY. It isn’t a complete configuration and works only if a node or proxy group named PROXY is defined. Don’t paste it over your subscription configuration. Subscription updates may also overwrite manual changes, so use the client’s override feature when available.

Step 6: Tell DNS Resolution Failures Apart from Proxy Connection Failures

Investigate DNS if the browser says “Server not found,” the logs show no such host, or name resolution times out. If the logs show a failure to connect to the node server, also check whether the node server’s hostname resolves; don’t focus only on the destination website’s DNS.

• Check local name resolution first: Run nslookup example.com in a terminal and check whether it times out and which DNS server it uses. This only shows the result for that query path; it doesn’t test mihomo’s internal DNS.
• Then check the core logs: Determine whether resolution failed for the node’s hostname or the destination hostname, and check whether the DNS upstream is reachable.
• Check your browser’s secure DNS: Built-in browser DoH may use a separate DNS path. Temporarily turn it off and test again, note the result, and then decide whether to leave it off.

In fake-ip mode, the client may return a mapped address in the 198.18.0.0/16 range to the application. In configurations that use this address pool, that doesn’t mean DNS is broken. Next, check whether the corresponding traffic reaches the core and whether it can resolve the correct destination hostname.

Don’t replace all DNS upstreams at once or assume that enabling fake-ip will fix the issue. The DoH address itself must also be reachable; incorrect bootstrap resolution or proxy dependencies can create a loop. Change one thing at a time and keep the original configuration so you can revert.

After correcting the configuration on Windows, run ipconfig /flushdns to clear the system DNS cache, then restart your browser and test again. Clearing the cache removes old records but can’t fix an unreachable upstream server.

Step 7: Check Port 7890 and Core Startup Logs

mixed-port can accept both HTTP and SOCKS5 proxy requests on the same listening port. 7890 is a common example, not a universal default. If the core hasn’t started, an enabled toggle in the interface can’t replace an actual listening service.

Find Which Process Is Using the Port

# Windows: Run in Command Prompt
netstat -ano | findstr :7890

# macOS: Show TCP listening processes
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux: Show TCP listening sockets
ss -ltnp 'sport = :7890'

On Windows, find the line with local port 7890 and status LISTENING, then match the PID in the last column to the process in Task Manager’s “Details” tab. A remote port or an established connection doesn’t mean a local proxy is listening. On Linux, you may need additional permissions to view processes owned by other users.

• Nothing is listening on the port: Check the logs for configuration parsing errors, startup failures, or permission warnings.
• Another program is using the port: Identify the process, then close the conflicting program or change the client’s mixed port to an unused port, such as 7891.
• After changing the port: Re-enable the system proxy and update your browser’s manual settings and test commands so they don’t keep connecting to the old port.

Don’t terminate unfamiliar system processes or enable “Allow LAN” just to connect from your own computer. A browser connecting to 127.0.0.1 doesn’t need allow-lan; listening on the LAN can expose the proxy to more devices.

Step 8: Isolate TUN, Other VPNs, and Security Software

If an explicit proxy test succeeds but browsing fails with TUN enabled, check the virtual network adapter, routes, and DNS interception. TUN captures traffic from more applications; it isn’t a required workaround when the system proxy fails. Clash forks differ in what they support, so follow the options and behavior of the mihomo core used by your client.

1. Establish a baseline: Turn off TUN, leave the system proxy on, and check whether the browser works.
2. Test TUN on its own: Turn off the system proxy, then enable TUN. Install the service or grant the required permissions as prompted by the client, and check the core logs for adapter or routing errors.
3. Pause conflicting network tools: Temporarily disconnect other VPNs, game accelerators, and tools that change routes. If you’re using a managed work device, check with your administrator first.
4. Check your security software logs: Look for specific application blocks or network restrictions. Add only the necessary rules for trusted clients; don’t leave your firewall disabled.

If the system proxy works but TUN doesn’t, keep using the system proxy while you troubleshoot permissions, route conflicts, or DNS hijacking settings. If only one app fails, check whether it follows the system proxy, uses UDP, and is compatible with the selected node. Don’t assume the entire computer has lost internet access.

Still Not Working? Create a Reproducible Troubleshooting Record

When asking for help, include your operating system and version, client and core versions, when the issue started, the actual listening port, and the results for direct connections, explicit proxy, Rule mode, Global mode, and TUN. Include only the relevant log lines from just before and after one failed attempt. Hide subscription URLs, access tokens, node credentials, and personal network information.

The goal of this eight-step checklist is to narrow down the problem: fix the network if direct connections fail; check the port and node if explicit proxy requests fail; inspect routing if Global mode works but Rule mode doesn’t; and check traffic interception if only TUN fails. Once it’s working, switch back to Rule mode, undo temporary troubleshooting changes, and confirm your everyday websites and apps connect normally.