Clash Connected But No Internet: A Step-by-Step Checklist From System Proxy to DNS

The client shows "Connected," the status light is green, and node latency numbers look normal — but no webpage will load in the browser, either spinning forever or throwing an error. This is one of the most common issues in Clash usage, and the cause usually isn't the node itself, but somewhere along the chain from the system, through the client, to the exit point. Below are five checkpoints ordered from most to least likely, each with a command you can run directly instead of guessing.

Step 1: Confirm the system proxy actually takes effect

A "Connected" status in the client only means the core process is running and the listening port is open — it doesn't mean system traffic is actually routed through that port. In many cases, users toggle Clash's built-in "Set as system proxy" switch, but the system-level proxy setting gets overridden by another app, or the browser uses its own separate proxy config, so traffic never enters Clash at all.

• Windows: Open "Settings → Network & Internet → Proxy" and confirm the address and port under "Use setup script" or "Manual proxy setup" match what the client shows.
• macOS: Open "System Settings → Network → Advanced → Proxies" and check whether "Web Proxy (HTTP)" and "Secure Web Proxy (HTTPS)" point to 127.0.0.1 and the client's port.
• If the browser has a separate proxy extension configured (like SwitchyOmega), changing the system proxy won't affect that browser — check the extension's settings directly.

Step 2: Check for port conflicts

Clash listens on port 7890 (mixed HTTP/SOCKS) and 9090 (external controller) by default. If other proxy software, virtual machine networking components, or a previous Clash process that didn't shut down cleanly are running on the same machine, the port may already be occupied — the client can appear to run fine on the surface while the actual listener fails.

netstat -ano | findstr 7890

lsof -i :7890

If the port is occupied by a non-Clash process, kill that process or change Clash's listening port to another value (like 7891), then restart the client. Also check Task Manager / Activity Monitor for multiple lingering clash / mihomo background processes, which can interfere with each other.

Step 3: Verify the node itself is usable

A latency reading of a few dozen milliseconds doesn't mean the node can actually reach the target site — speed test tools usually only measure the TCP handshake with the landing server, not whether the exit IP has been blocked by the target site, or whether that node's outbound bandwidth is already exhausted. Ways to rule this out one by one:

1. Switch to a different node in a different region/protocol in the client's node list, then revisit the same URL to see if the problem is specific to the current node.
2. Open the client's connection log or traffic panel to see whether the current request actually went through the selected node, or was routed to "DIRECT" by some rule.
3. Test outbound connectivity directly from the command line to rule out browser cache, DNS cache, and other interference:

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

If this command returns HTTP/2 200 or a similar normal status code, the proxy chain itself is fine, and the browser issue is likely caused by cache, extensions, or HTTP/3 compatibility problems on the browser side — try an incognito window or a different browser to confirm.

Step 4: Check for DNS poisoning or hijacking

If the proxy chain is fine but specific sites still won't load — or load with wrong content — the DNS layer is the likely culprit. On networks in mainland China, resolving domains through the system's default DNS often returns poisoned, incorrect IPs. Even if traffic is already handed off to Clash, if domain resolution itself doesn't go through the proxy's built-in DNS module, subsequent requests will still connect to the wrong address.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://doh.example-provider.com/dns-query
  fallback:
    - tls://1.1.1.1:853

To verify whether DNS resolution is working correctly, compare the resolution results with and without the proxy directly from the command line:

nslookup www.example.com
nslookup www.example.com 198.18.0.2

If the two results return noticeably different IPs, or one of them times out entirely, it means there's a discrepancy between the local default DNS and the proxy's built-in DNS. The proxy's built-in DNS result should take priority — also confirm that no system network setting is forcing an ISP DNS that overrides the proxy configuration.

Step 5: Check whether rules are misrouting traffic

Clash's core mechanism is routing each connection to a different policy group based on rules. If the rule set is misconfigured, it's entirely possible to see "proxy connected, some sites work, some don't" — the problematic site gets misjudged by some rule as "should go direct," while the local network happens to be unable to reach that address directly.

• Open the client's rules/log panel, visit the URL that won't load, and check which rule the connection actually matched and which policy group it landed in.
• If it shows DIRECT instead of a proxy node, check whether the rule set (such as GeoSite or GeoIP categories) has incorrectly classified that domain or IP range under a "mainland China nodes" or "direct" category.
• The rule set itself might be outdated — going too long without updates means newly added domain ranges won't be correctly covered. It's worth periodically refreshing the rule set source or switching to an actively maintained rule repository.

Still not fixed after all five steps?

Working through the checks above in order will resolve the vast majority of "connected but no internet" cases. If everything checks out — traffic, DNS, and rules all look normal — but pages still won't load, look into two more things: whether a local firewall or security software has set separate network restrictions on the Clash process; and whether the subscription's nodes are temporarily down, which can be fixed by re-importing the subscription link to force-refresh the node list. In most cases, restarting the client process and re-running through the steps above will surface the issue at some point along the way.