Why "connected" doesn't mean "online"
The green dot or "Connected" indicator in the client interface usually just means Clash has completed a handshake test with the proxy server, or that the currently selected node returned a value from a latency test. That status is a different thing from "can the browser actually load a page" — in between sit several other links: whether the system proxy is actually taking effect, whether DNS is resolving correctly, whether rules are routing traffic to the wrong outbound, and more. A problem in any one of these links produces the same symptom of "connected but no internet," and the underlying error is often not shown directly on the main screen — it takes going through each item to pin down.
The nine checkpoints below are ordered as "confirm local settings first, then verify the node itself, and finally check rules and the remote side." It's worth going through them in order rather than jumping around — the problem is very often in step one, but gets mistaken for a dead node.
Checkpoints 1–3: local machine and client settings first
1. Is the system proxy actually turned on
This is the step most often overlooked. On some clients, switching config profiles or restarting resets the system proxy switch back to off, while the node connection status still shows normal — creating the illusion that "it looks connected, but no traffic is actually going through the proxy at all."
- How to check: open the OS network settings panel and confirm the proxy address is
127.0.0.1plus the matching port (usually around 7890), rather than blank or the system default. - Fix: manually turn on the "System Proxy" switch in the client's main screen, then refresh the network settings panel to confirm it was written correctly.
2. Is the wrong proxy mode selected
Clash typically offers three proxy modes: Rule, Global, and Direct. If the mode is accidentally set to Direct, all traffic bypasses the proxy entirely — the node status can still show as normal, but no traffic actually passes through the proxy server.
- How to check: look at the mode selector in the client's settings area and confirm the current selection isn't "Direct." If you normally use Rule mode but notice an unusually large number of sites you can't reach, try switching temporarily to Global mode as a comparison test.
- Fix: switch back to Rule or Global mode and see whether the problem disappears.
Global mode sends all traffic (including sites that should go direct) through the proxy — use it only for comparison testing during troubleshooting. For everyday use, switch back to Rule mode to avoid unnecessary latency and bandwidth use.
3. LAN connections and port conflicts
If you're forwarding traffic to the machine running Clash from a router or another device, you'll need to additionally enable "Allow LAN" in the settings. Also confirm the proxy port isn't already in use by another running program — for example, having another proxy tool open at the same time can cause the two to fight over the same port, silently dropping proxy requests.
- How to check: check the "Allow LAN" switch state in the client settings; use a command-line tool to check what's using the port.
- Fix: close the conflicting program or change the port Clash listens on, then restart the client for the change to take effect.
Checkpoints 4–6: verify whether the node itself is usable
4. Node latency test results
The latency value (ms) shown in the client is usually the result of a connectivity test against the node's server. A normal value means the server is online and reachable; a timeout or extremely high latency means the node itself has a problem, unrelated to local settings.
- How to check: manually trigger a latency test in the proxy group list, paying particular attention to whether the currently selected node shows a timeout (usually shown in red or labeled
timeout). - Fix: if the current node has timed out, switch to another node with normal latency; if every node under the subscription is timing out, the problem may be with the subscription itself or your local network environment — go back and re-check checkpoints 1 and 2.
5. The auto-select logic in proxy groups
In many subscription configs, the "auto-select" proxy group automatically switches the actual node in use based on latency or availability. If the exit node this auto-select group is currently pointed at happens to be down, the current session may briefly lose connectivity due to switching delay — even if other healthy nodes remain in the group.
- How to check: expand the auto-select group and see whether the sub-node currently in effect has abnormal latency.
- Fix: manually force a switch to a specific node you've already confirmed works, rather than relying on the auto-select group, to rule out interference from the auto-switching logic.
6. Whether the node's protocol matches the server-side configuration
For nodes you added or edited manually (rather than generated directly from a subscription), if parameters like protocol type, encryption method, or transport-layer settings don't match the server side, you can end up with "can connect but can't establish a working session" — which shows up the same way: normal latency but pages that never load.
- How to check: compare the node's parameters against the original configuration provided by the server operator, paying special attention to the transport protocol and encryption method.
- Fix: regenerate the config from the subscription link instead, to avoid parameter errors from manual entry.
Checkpoints 7–9: DNS and rule-level troubleshooting
7. Is DNS resolution being poisoned
Some network environments hijack or tamper with DNS queries. Even if the proxy itself is working fine, if the domain resolution step has already returned the wrong IP address, subsequent requests will still fail or get routed to the wrong server. In this scenario, the proxy latency test can look completely normal while pages still never load.
- How to check: compare the IP address the same domain resolves to with the proxy on versus off; you can also check the DNS query records directly in the client logs.
- Fix: enable Clash's built-in DNS module in the config so domain resolution is handled by Clash rather than the system default DNS, and enable
fake-ipmode if needed, to prevent resolution results from being tampered with by the local network at the source.
DNS poisoning is one of the most easily overlooked yet widest-reaching classes of problems — it won't produce an error on the proxy connection itself, it just makes the final destination address wrong, which makes it easy to misdiagnose as "the node is unstable."
8. Are rules incorrectly matching traffic to DIRECT
In Rule mode, the rule sets in the config match a request's domain or IP one by one, and once a DIRECT rule is hit, traffic goes direct instead of through the proxy. If a rule set is outdated or the rule order is wrong, a domain that should go through the proxy might get matched to a direct rule too early — especially in configs using custom rules or multiple stacked rule sets.
- How to check: look at the client's connection log or rule-matching record to confirm which rule the target domain actually matched and which outbound policy group it was sent to.
- Fix: reorder rules so more specific proxy rules come before broad direct rules, or update to the latest version of the rule set; for a quick check, you can also switch to Global mode to rule out rule interference.
9. Is the node group behind an outbound policy group empty or entirely dead
Some configs set up separate policy groups for different types of traffic (such as streaming, social apps, or domestic direct traffic), each referencing its own set of nodes. If a policy group's filter conditions are too strict and leave it with no usable node, any traffic matching that group will fail outright — even if the main default proxy group is working perfectly fine.
- How to check: go through each policy group defined in the config and confirm every group contains at least one currently working node.
- Fix: add more node sources to the policy group, or temporarily point an empty policy group at the main proxy group, so that particular type of traffic isn't left with nowhere to go.
Chaining the nine checks into one troubleshooting path
In practice you don't need to rigidly go through every numbered item before drawing a conclusion. A more efficient approach is to make two quick judgment calls first to narrow things down: first, check whether it's a local settings issue — switch temporarily to Global mode; if the problem disappears, it's most likely a rule or DNS-level issue (checkpoints 7–9). If it's still not working after switching, focus on the system proxy switch, port conflicts, and the node's own status (checkpoints 1–6).
If all nine checks come back clean but the problem persists, keep a screenshot of the client logs and re-import the subscription to generate a fresh config file for comparison — sometimes the problem lies in a config file that's accumulated too many local edits over time, and a clean config is often faster than continuing to dig through the old one.
# Quick command-line way to verify the proxy is working (similar syntax works on both Windows and macOS)
curl -x http://127.0.0.1:7890 https://www.google.com -I
# If it returns an HTTP status code instead of a timeout or connection refused,
# the proxy chain itself is working fine — the problem is most likely at the DNS
# resolution or rule-matching layer