Clash Not Connecting to the Internet: A Step-by-Step Troubleshooting Checklist

1. Figure Out Where the Chain Breaks

When a browser loads a page, the request passes through: browser, system proxy, Clash's local port (7890 by default), proxy node, and finally the target site. A break anywhere along this chain shows up as "the page won't load," but the fix is completely different depending on where it breaks. So the first move isn't to start changing settings — it's to find the break point.

The fastest way to locate it is the Connections panel in Clash:

Open the Clash client and switch to the Connections tab.
Keep the panel visible, go back to your browser, and refresh the page that won't load.
Watch what happens in the connection list.

If no new entry shows up at all, the request never reached Clash — the problem is in your system proxy or browser settings, so jump straight to step 2. If a new entry does show up but the page still won't load, the request reached Clash but failed to forward — the problem is in the proxy mode, node, DNS, or subscription, so start from step 3. Sorting these two cases first saves you from blindly trying every fix.

2. Confirm the System Proxy Is Actually Active

A system proxy that isn't enabled is the most common reason Clash shows "connected" while pages still won't load: Clash is running fine, but your browser's traffic was never handed over to it in the first place.

Check and fix:

In Clash for Windows, turn on the System Proxy toggle on the main screen; clients like Clash Verge and Clash Nyanpasu have the same System Proxy option in settings — make sure it's enabled.
Windows check: open Settings → Network & Internet → Proxy. "Use a proxy server" should be on, with address 127.0.0.1 and a port matching Clash's mixed port (7890 by default, or whatever you set as mixed-port in the config).
macOS check: open System Settings → Network, select your active network, go to Details → Proxies. "Web Proxy (HTTP)" and "Secure Web Proxy (HTTPS)" should be checked, with server 127.0.0.1 and the matching port.

A few common traps:

Clash's port was changed at some point, but the system proxy setting still points to the old port, so they no longer match.
Another proxy or accelerator app overwrote the system proxy settings after Clash set them.
Your browser has an extension like SwitchyOmega installed, which uses its own proxy config and bypasses the system proxy entirely. Disable extensions like this while troubleshooting.

Verification: open any IP-lookup site in your browser. The IP shown should match your proxy node's region, not your local ISP's address.

Test with One Command, Bypassing the System Proxy

To check whether the "Clash to node" leg itself is working, run this from the command line:

curl -x http://127.0.0.1:7890 -I https://www.google.com

This routes traffic straight through Clash's local port, skipping the system proxy entirely. If it returns HTTP response headers, Clash and the node are talking fine and the problem is in the system proxy or browser. If the connection fails, the Clash-to-node leg is broken — check steps 3 through 5 first: mode, node, and subscription.

3. Check the Proxy Mode and the Active Node

Once the system proxy checks out, the next question is: once traffic reaches Clash, where is it actually being sent?

Confirm the proxy mode. Clash has three modes — Rule, Global, and Direct. In Direct mode, all traffic bypasses the proxy entirely, which is effectively the same as having no proxy at all. Make sure you're not stuck there.
In Rule mode, check which node is currently selected in the policy group. If it's set to DIRECT, or to a node that's already timing out, pages won't load no matter what — switch the group to a node with normal latency.
Run a latency test on the node list (usually a speed-test or lightning-bolt icon) and rule out anything showing timeout.

Verification: temporarily switch to Global mode, pick a node with normal latency, and refresh the target page. If it loads, the earlier problem was rule-based routing or node selection; if it still doesn't load, move on to DNS.

4. Check for DNS Resolution Issues

A classic sign of a DNS problem: it's not that every site is broken, just some of them — or you can ping the IP directly but not the domain name.

Check each of these:

Open your active config file and confirm the dns block exists, enable is set to true, and nameserver points to working public DNS servers. If this block is missing entirely, Clash falls back to the system DNS, which is easy to get wrong on networks where domain resolution is tampered with.
Clear old resolver caches: on Windows, run ipconfig /flushdns from the command line; in the browser, open chrome://net-internals/#dns to clear the cache, or just restart the browser.
Check your browser's "Secure DNS" (DNS over HTTPS) setting. When it's on, the browser resolves domains on its own, bypassing the system DNS — which can conflict with Clash's DNS takeover. Turn it off while troubleshooting.
Use nslookup with the target domain to verify the resolution path. Getting a consistent result means resolution is working; if Clash's DNS is running in fake-ip mode, seeing an address starting with 198.18 is expected, not a bug.

For the full breakdown of DNS fields and leak-prevention setup, check the user guide — for now, just confirm resolution is working before moving on.

5. Check Whether Your Subscription and Nodes Are Still Valid

If most of the nodes in your list are showing timeout, the issue is probably not local at all — it's on the subscription side.

Run an Update on your current subscription in the config page to pull the latest node list. A list that hasn't been refreshed in a while may be full of nodes that are already offline.
Log into your provider's dashboard and confirm your plan hasn't expired, your data allowance isn't exhausted, and your subscription link hasn't been reset. Once a link is reset, your old config is pulling dead content — you'll need to re-import with the new link.
After updating, run the latency test again to confirm at least one node is healthy, then switch back to Rule mode and retest the page.

A useful rule of thumb: one node timing out is a node problem; every node timing out points to the subscription or your local network first.

6. TUN Mode, Firewalls, and Software Conflicts

If none of the five steps above fixed it, it's time to look at the system level.

TUN mode needs an extra component: Clash for Windows requires Service Mode installed, and Clash Verge needs the service mode installed and authorized. Turning on TUN without the component properly set up typically looks like "internet drops the moment TUN is enabled, and comes back the moment it's off." While troubleshooting, it's best to just turn TUN off and rely on the system proxy alone — one less variable to worry about.
Windows Firewall or third-party security software may be blocking Clash's core process from reaching the network — add the client to the allow list and try again.
Running multiple proxies, VPNs, or game accelerators at once causes them to fight over the system proxy and routing table. While troubleshooting, keep only Clash running and quit everything else.
If none of that helps, restart the client; if that still doesn't work, restart the whole system to clear any lingering port conflicts.

Note

Change only one setting at a time while troubleshooting, and verify immediately after each change. Changing several things at once and testing afterward means that even if it starts working, you won't know which change actually fixed it — and the problem is likely to come back.

7. Quick Reference by Symptom

Here's the checklist above condensed into a table, so next time you can jump straight to the matching symptom:

Symptom	Likely Cause	Where to Start
No new entries in the Connections panel	System proxy inactive or bypassed by an extension	Step 2
Connections show up, but the selected node is timing out	Node is dead or the policy group is misconfigured	Step 3
Only some sites won't load	Rule-based routing issue or abnormal DNS resolution	Steps 3-4
Internet drops the moment TUN mode is enabled	Service mode not installed or missing permissions	Step 6
Every node is timing out	Subscription expired, plan expired, or local blocking	Steps 5-6
Works on phone, but not on the computer (same subscription)	System proxy, firewall, or port config issue on the computer	Steps 2, 6

8. A Few Good Habits While Troubleshooting

A few final habits that aren't tied to any specific issue, but that save time overall.

Back up before you touch anything. Before editing a config file, export a copy of your current working config so you can roll back instantly if something breaks.
Pick one test site and stick with it. Testing against the same target site after every change avoids the false "oh, it's working now" moment caused by switching sites — some sites are just flaky on their own.
Remember what you changed last. Problems usually show up right after the most recent change: a subscription update, a client upgrade, a new piece of software installed. Working backward from "what changed recently" is usually faster than starting the checklist from scratch.
If the problem started right after a client upgrade, roll back and test the older version first. If the old version works and the new one doesn't, it's a version compatibility issue — check the release notes on the project's release page for known issues.

Work through this checklist step by step, and you'll be able to pin down almost any "connected but no internet" situation to a specific stage. If it turns out to be a subscription-side issue, no amount of local tweaking will fix it — contacting your provider directly is the right move.