Connected but Pages Won't Load: A Checklist from Node Latency to DNS

The proxy toggle is green, yet the browser just spins. The cause could be the node, the rules, DNS, or the system proxy. This guide lists nine checkpoints in order from easy to hard, each with a way to verify it and a fix.

Narrow down the scope before you start digging

"Shows connected but pages won't load" can mean very different problems. Spend a minute narrowing the scope first — it saves most of the time you'd otherwise spend guessing.

• Only some sites fail, others work fine: likely a rule-routing or single-node issue, not a general network failure.
• Nothing loads at all, including local sites: suspect the system proxy, the TUN adapter, or the local network first — it's probably not the node.
• Pages load but very slowly, images cut off: usually node latency or bandwidth, not a "can't connect" problem.
• Started right after switching subscriptions or editing the config: check the rules or DNS block in the config first; rolling back once quickly confirms whether that's the cause.

Once you've matched the symptom to one of the categories above, jump straight to the relevant checkpoints below — you don't need to go through every single one.

Checkpoints 1–3: Is something wrong with the node itself

1. Is the currently selected node actually reachable

"Connected" on the proxy page usually only means the control connection between the client and the core is fine — it says nothing about whether the selected node can reach the internet. Open the proxy page and run a latency test on the current group. A timeout or a three-digit-plus latency alongside failed loads means the node is the problem — switch to a lower-latency node and retest. If that fixes it, keep going with points 2 and 3; if pages still won't load after switching, skip ahead to the rules and DNS sections.

2. Is the group stuck on a dead node

With select or url-test groups, if the subscription provider temporarily drops a node, the client won't warn you — the group just keeps sitting on that dead entry. Check the log page for a burst of dial tcp: connection refused or i/o timeout errors. If they all point to the same node name, switch to another node in the group manually, or change the group type to url-test so the core auto-skips nodes with abnormal latency.

3. Has the subscription expired or nearly run out

Some subscriptions don't throw a clear "fetch failed" error when data or time runs out — instead they swap in dead placeholder nodes for every entry, which looks exactly like "connected but nothing loads." Checking the expiry date and remaining data on the provider's dashboard is far faster than repeatedly restarting the client.

Checkpoints 4–6: Are rules sending traffic the wrong way

4. A domain that should be proxied is matching as direct

Clash matches rules top to bottom and stops at the first hit. An overly broad DOMAIN-SUFFIX or DOMAIN-KEYWORD in a custom rule can catch a domain earlier than intended and route it to DIRECT when it should go through the proxy. Set the log level to debug, open the failing site, and check which rule the domain actually matches and which group it lands in — that pinpoints the offending rule directly.

5. The rule-provider isn't fetching correctly

With remote rule sets, if a fetch fails, the core typically falls back silently to an empty set or the last cached copy — it won't drop the proxy connection to warn you. Check the rule set's last-update time on the config page, or add a fallback line to the config:

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/reject.txt"
    path: ./ruleset/reject.txt
    interval: 86400
rules:
  - RULE-SET,reject,REJECT
  - MATCH,PROXY

That trailing MATCH,PROXY line guarantees any traffic not covered by the rule set still has a defined destination, instead of falling into undefined behavior.

6. The FINAL / MATCH rule points to the wrong group

The catch-all rule at the end of the config (FINAL in the old syntax, MATCH in the new one) sends every domain that didn't match an earlier rule straight there. If it's mistakenly set to DIRECT, all unmatched domains go direct — which means widespread failures on any network without direct access. Check the last line of the config and make sure it points to a proxy group, not direct.

Checkpoints 7–9: Hidden traps in DNS and the system layer

7. DNS resolution is being poisoned or returning the wrong IP

Even if traffic is proxied, if domain resolution still uses the local ISP's DNS instead of the DNS Clash controls, the result can still be poisoned — a wrong IP means nothing loads no matter how fast the proxy is. Check whether the dns block in the config is enabled, and whether enhanced-mode is set to fake-ip or redir-host:

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
  fallback:
    - tls://1.1.1.1:853
  fallback-filter:
    geoip: true
    geoip-code: CN

In fake-ip mode, the client assigns each domain a virtual IP and restores the real request at the core level, which sidesteps most local DNS poisoning — it's the currently recommended default mode.

8. The system proxy isn't actually being used

Some applications — especially command-line tools, certain game clients, and older browsers — ignore the system proxy setting entirely. Even with Clash showing "connected," these apps still connect directly and naturally fail to reach anything that requires the proxy. Test with a browser that clearly honors the system proxy (Chrome, Edge). If that works, the app itself is the issue, not Clash — you'll need to configure a proxy address for it separately or switch to TUN mode to intercept it at the network layer.

9. TUN mode and the system proxy are both on, causing conflicts

TUN mode takes over all traffic at the network layer. If the system proxy is also set manually, the two interception paths overlap, which can create routing loops or duplicate handling of traffic — showing up as intermittent failures, working one moment and not the next. Keep only one method active: turn off the system proxy when TUN is on, and vice versa — never both at once.

Putting the nine checkpoints into one full pass

If you're not sure where the problem lies, this order usually finds it within five minutes:

1. Switch nodes to rule out a dead node (checkpoints 1–3).
2. Set the log level to debug, reproduce the issue, and see which rule the domain hits (checkpoints 4–6).
3. Check whether enhanced-mode is fake-ip to rule out DNS poisoning (checkpoint 7).
4. Test with a different app that clearly supports the system proxy, as a control (checkpoint 8).
5. Check whether TUN and the system proxy are both enabled at once (checkpoint 9).

After these five steps, over 90% of "connected but won't load" cases get traced to a specific cause. If every checkpoint checks out and the problem still persists, the config file itself likely has an error — replace it temporarily with a simple, known-good example config to confirm the client is behaving normally, then add your custom rules back one at a time.