Clash Connected but Web Pages Won't Load: A Step-by-Step Checklist for System Proxy, DNS & Rules
Proxy toggle green, node showing connected, yet pages keep spinning and never load — this "looks fine but isn't working" scenario usually comes down to one of five things: whether the system proxy is actually taking effect, whether the node itself is reachable, whether DNS resolution is working, whether traffic is hitting the rule you expect, or whether stale browser cache is interfering. Work through them in order instead of randomly switching nodes, and you'll pinpoint the break much faster.
Step 1: Confirm the System Proxy Is Actually Active
A client showing "Connected" only means a tunnel exists between the client and the node — it doesn't mean system traffic is actually being routed through that tunnel. This is the layer most people skip, and it's where troubleshooting should start.
Open your system's network settings and check the proxy configuration (Windows: Settings → Network & Internet → Proxy; macOS: System Settings → Network → Advanced → Proxies), and confirm the address and port point to the client's local listening port (usually a mixed port like 127.0.0.1:7890).
If the client has system proxy management enabled, this field should show as auto-written by the client. Try turning it off and re-enabling it from the client's interface, then check whether the setting gets rewritten correctly.
If you're using TUN mode (a virtual network adapter that takes over all traffic), the system proxy setting doesn't apply. Instead, check your network adapter list for the virtual adapter created by the client and confirm it's enabled.
If the system proxy fields are blank, the port doesn't match, or no matching virtual adapter shows up in TUN mode, traffic isn't reaching the client at all — everything downstream is moot until this layer is fixed.
Step 2: Node Connectivity — the First Layer Beyond the Toggle
Once the system proxy is confirmed active, the next thing to rule out is "the tunnel exists, but the node itself can't reach the internet." A "Connected" status in the client generally just reflects a successful handshake — it doesn't guarantee the node is currently forwarding traffic properly.
Run a latency test on the currently selected node in the client's node list. If it times out or shows abnormally high latency, switch to another available node under the same subscription.
Open the client's built-in log panel and look for entries like connection refused or handshake failed — these usually point to a problem on the node side rather than your local configuration.
If every node fails the test, the subscription server is likely down, or your local network is blocking the outbound protocol/port entirely. That's a different class of problem — see our guide on all nodes timing out for a dedicated walkthrough.
Tip
Check the latency test results before switching nodes — don't switch on a hunch. Blind switching makes it easy to misdiagnose a real issue (like DNS or rules) as "a bad node."
Step 3: DNS Resolution — Can the Domain Even Be Translated to the Right Address
If the proxy link is up and the node is reachable, but pages still spin, the likely culprit is domain name resolution. If DNS requests aren't going through the proxy, or a stale result is cached locally, the browser ends up waiting on a connection that will never come back.
Check the DNS settings in your client config and confirm fake-ip or the client's built-in remote DNS forwarding is enabled, rather than falling back to your system's original DNS servers.
Run a resolution test from the command line against a domain that clearly requires the proxy to reach. If it returns a typical error address or times out the way your local ISP's DNS would, the DNS query isn't being intercepted by the proxy.
If your client supports splitting DNS queries via rules, check whether DNS lookups are accidentally routed to a "Direct" policy group — this kind of misconfiguration makes the proxy link look fine while resolution keeps failing.
Flush your local DNS cache (on Windows: ipconfig /flushdns; on macOS: sudo killall -HUP mDNSResponder), then reload the target site.
DNS-layer issues typically show up as "some sites load, others don't," with the same site behaving inconsistently at different times. If you're seeing that pattern, suspect resolution before blaming the node.
Step 4: Rule Matching — Why It's Connected but Still Won't Load
Both Clash and the Clash Meta (mihomo) core rely on rules to decide which policy group each connection goes through. If a rule mistakenly routes the target site to "Direct" or to a dead policy group, the site still won't load even if the proxy itself is working perfectly.
Open the client's connections panel or logs and check which rule the target site's request actually matched and which policy group it landed in — don't just check whether the policy group shows "Connected."
If the matched policy group's currently selected node isn't actually working, the connection will still fail even with a correct rule match — check that node's status separately.
With a lot of custom rule sets or messy rule ordering, it's common for a broad rule earlier in the list to catch traffic before a more specific rule further down gets a chance. Try temporarily clearing custom rules and restoring the subscription's default config to see if the issue disappears.
In TUN mode, also check for rules that exclude key system processes or the browser process from being taken over — these exclusions cause browser requests to bypass the proxy entirely.
Symptom
Likely Cause
What to Do
No sites load at all
System proxy not active / TUN adapter not enabled
Go back to Step 1 and re-check the proxy configuration
Some sites load, others don't
Rule matched to the wrong policy group
Check connection logs to confirm which rule actually matched
Pages just spin with no error
DNS resolution not going through the proxy, or cached
Flush local DNS cache and check fake-ip settings
Everything times out under one policy group
The node in that group isn't working
Switch to another available node in that policy group
Step 5: The Last Mile — Browser and Local Cache
If the first four steps all check out but a specific page still won't load, the problem is often stale connections or certificate data cached by the browser itself, not the proxy chain.
Open the target site in a private/incognito window to rule out browser extensions and local cache interference.
If the browser shows a certificate error or a reset connection, check whether your system clock is accurate — a large time offset can break TLS handshake verification in a way that looks a lot like a proxy problem.
Some browsers keep a persistent connection pool per domain. After switching nodes or policy groups, old connections may not be released right away — restarting the browser process usually clears this up.
Working through these five steps from nearest to farthest will pinpoint the exact break in most "connected but won't load" cases within about 10 minutes. If you've ruled everything else out and it turns out to be a compatibility issue with your client version, consider updating to the latest release and testing again.