Clash Connected but Websites Won’t Load: How to Check Your Subscription, Port, and System Proxy

First, understand what “Connected” actually means

A Clash client showing that it’s running, a node reporting latency, or Android showing a VPN connection doesn’t mean the entire path from your browser to a website is working. “Running” usually means only that the core process has started. A node latency test usually checks only the configured test address. On Android, the VPN indicator mainly confirms that the local VPN service is active. Web traffic still depends on app proxy settings, the local listening port, routing rules, the node’s outbound connection, and the destination site. A problem at any point can leave a page loading indefinitely.

This guide covers Clash-compatible clients. The same troubleshooting steps apply to the Clash Meta (now called mihomo) core. Client settings and default ports vary; 7890 is only an example local mixed port to check, not necessarily the port used on your device.

1. Note the active configuration, selected node, proxy mode, HTTP or mixed port, and whether system proxy and TUN are enabled.
2. Pause other proxy clients and VPNs first. On desktop, turn off TUN and troubleshoot with system proxy only to reduce routing and DNS variables.
3. Open one site that normally works without a proxy and one that requires your current proxy. Note the browser’s full error code for each.
4. Change one setting at a time, then revisit the same address. Keep the change if it fixes the issue; otherwise, revert it. Avoid changing the port, DNS, and rules all at once.

Step 1: Check whether your subscription has expired and the configuration is loaded

A successful subscription update doesn’t guarantee that your nodes work

Open the client’s subscription or configuration page and check which configuration is active—not just which one was updated most recently. A successful update means the subscription content could be downloaded; it doesn’t confirm that your account has data remaining or that the node server is reachable. Conversely, if an update fails, the client may keep using a cached configuration, so nodes can still appear in the list.

• Check your account: Visit your subscription provider’s account page to confirm the expiry date, remaining data, and device limits. Don’t rely solely on cached figures shown in the client.
• Check the response: If logs show HTTP 401 or 403, check authorization, account status, and provider access restrictions. For 404, check whether the URL was revoked or copied incorrectly. A status code alone doesn’t identify the cause.
• Check the format: A YAML parsing error may mean the download returned a login page or error page, or that the content isn’t a Clash configuration supported by your client.
• Check the core: If the configuration uses protocols or fields unsupported by your current core, use a subscription format explicitly supported by your provider or switch to a compatible core. Repeatedly importing the same file won’t fix the issue.

Choose a specific node to rule out automatic selection

Manually select a node in the current proxy group and confirm that requests actually use that group. Test node A, then node B, visiting the same site each time. If the latency test passes but the page won’t load, the test site may be reachable while the destination isn’t—or the destination’s rule may send traffic to a different group. Check the outbound route in the connection log; latency alone isn’t enough to diagnose the problem.

If every node fails but direct connections work, check your subscription account, node hostname resolution, and connectivity to the node’s port first. Don’t paste your subscription URL into unfamiliar online converters or testing sites: it often contains access credentials. Hide tokens and QR codes in screenshots, too.

Step 2: Check that the mixed port is listening and not in use

If the system proxy points to 127.0.0.1:7890 but the core is listening on 7897, the browser can’t forward traffic through that entry point. Another common cause is an older client holding the port: the new client appears to start, but its core fails to provide a proxy because it can’t bind to the port. Check mixed-port or HTTP port in the active configuration, then look for address already in use in the logs.

Run the following command in Windows PowerShell to check the example port 7890. If your port is different, replace the number in the command first.

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

If nothing is listening, check whether the core started and whether the configuration failed to load. If you find a process ID, use the command below to identify the process. Don’t terminate an unfamiliar process or expose the listener on all network interfaces to fix a local proxy.

Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 7890).OwningProcess

Test the proxy entry point without using your browser

Use the built-in Windows curl.exe and explicitly specify the local HTTP proxy. On macOS or Linux, run the same arguments with curl. The address below is only for checking whether an HTTPS request completes; it isn’t a node speed benchmark.

curl.exe --noproxy "" -x http://127.0.0.1:7890 -I --connect-timeout 10 --max-time 20 https://example.com/

Seeing 200 Connection established in an HTTPS request doesn’t necessarily mean the destination page loaded. Check the subsequent TLS handshake and response, too. A 403 or 429 from the site doesn’t mean the proxy disconnected; the site may be enforcing access policies or rate limits.

Step 3: Make sure your system proxy and browser settings match

If the explicit proxy test works but your browser can’t load pages, check that it’s actually using the same proxy. A system proxy doesn’t transparently route every device connection: apps can ignore it, and extensions, PAC scripts, or custom proxy settings can override it.

• Windows 11: Go to Settings → Network & internet → Proxy. Check the manual proxy address and port, and whether a setup script is enabled. If you use the client’s system proxy toggle, verify the settings here instead of relying on the tray icon.
• macOS: Go to System Settings → Network → your active network service → Details → Proxies. Make sure the HTTP, HTTPS, or automatic proxy settings match your current setup. Remove any stale PAC URL.
• Firefox: Go to Settings → General → Network Settings → Settings. Check whether Firefox uses the system proxy settings or has a different proxy configured manually.
• Android: Traffic is usually routed through the client’s VPN service, so desktop system proxy steps don’t apply. Check the per-app proxy list to make sure your browser isn’t excluded, and look for another VPN that may be taking over the connection.

Temporarily disable browser proxy extensions and try again. Fully quit and reopen the browser to avoid reusing old connections. On Windows, netsh winhttp show proxy displays the WinHTTP proxy; it doesn’t tell you which system proxy settings every browser uses, so don’t treat it as the only source of evidence.

Step 4: Check which rule matched and where the traffic went

Switch the client to Rule mode, open Connections or the equivalent request list, then revisit the site that failed. Note the destination domain, matched rule, selected proxy group, and final node. Clash rules are usually checked in order, so a broad rule near the top can match first and prevent a later domain-specific rule from taking effect.

1. Make sure the request appears in the connection list. If it doesn’t, suspect that the app is bypassing the proxy, reusing a connection, or being routed by another network tool.
2. If the final outbound is DIRECT, check whether the site should connect directly and whether the domain rules include its login, image, or API domains.
3. If the final outbound is REJECT, check whether a blocking rule is catching the request by mistake. Don’t delete all your rules.
4. If traffic uses a proxy group, expand the group and make sure it hasn’t selected an unavailable node or DIRECT.
5. Briefly switch to Global mode, explicitly select a tested node, and visit the same address. Switch back to Rule mode when the comparison is done.

If the site loads in Global mode but not Rule mode, compare the actual outbound routes for both requests rather than treating Global mode as a permanent fix. Global mode changes the route for many connections and can affect local services, work networks, and account sign-ins. If both modes fail, recheck the node and DNS instead of repeatedly adding domain rules.

Save custom rules through the client’s supported override or merge mechanism. Direct edits to subscription-generated files may be overwritten on the next update. Start with a minimal, targeted rule, then check which API domains the page needs. Avoid broad suffix rules that change unrelated traffic.

Step 5: Tell DNS poisoning apart from resolution failures and normal Fake-IP behavior

A browser’s DNS error doesn’t necessarily mean DNS poisoning. An upstream DNS timeout, unreachable encrypted DNS server, unresolved node hostname, or a different resolution path in the browser’s Secure DNS can all look similar. Check the logs first to see whether the failed hostname belongs to the destination site or the proxy node itself.

First, identify which DNS path handles the query

On Windows, use the command below to check the system’s default DNS response. It shows only the result of that system query; it doesn’t necessarily reflect what your browser, Clash’s built-in DNS, or the remote proxy resolves.

nslookup example.com
ipconfig /flushdns

The second command clears the Windows DNS client cache, but not the browser cache or the core’s DNS cache. After changing DNS settings, reload the configuration or restart the core if your client supports it, then create a new browser connection. Don’t assume different IPs from two DNS servers mean poisoning: CDNs often return different addresses.

Fake-IP returns a virtual address; that doesn’t mean the domain resolved incorrectly

In Fake-IP mode, the client may return a virtual address in the 198.18.0.0/16 range; the exact range depends on the configuration. The address maps the domain to its connection—it isn’t the destination site’s real server address. Seeing one on its own isn’t a fault. Check whether the connection is being intercepted correctly and whether the core still has the corresponding mapping.

• If only one app has a problem, check whether it uses its own DNS, has cached an old Fake-IP address, or bypasses the proxy.
• If the logs show an upstream resolution timeout, check whether the servers in nameserver are reachable from your current network. Don’t add a long list of DNS servers from unknown sources.
• If a node uses a hostname, check for a DNS bootstrap loop: the client needs the node to reach DNS, but needs DNS to resolve the node. Depending on your configuration, mihomo can use proxy-server-nameserver to resolve node hostnames. Check compatibility separately for older cores.
• If Secure DNS is enabled in your browser, temporarily turn it off for a comparison test. Restore it afterward if needed, and note which DNS path caused the difference.

Keep a copy of your current settings before changing nameserver or fallback. Whether fallback is enabled and how its results affect selection depend on the core and filtering configuration; it doesn’t simply mean “try the second server only if the first fails.” Use the logs and documentation for your current core to troubleshoot DNS instead of replacing the entire section with an unverified example.

Step 6: If the issue occurs only with TUN enabled, check routing and DNS interception

If explicit proxy works with TUN off but fails with TUN on, focus on the virtual interface, permissions, routing, DNS interception, or conflicts with other VPNs. Which connections TUN can intercept depends on routes, exclusions, and platform implementation; enabling TUN doesn’t guarantee that every app will use the proxy.

1. Make sure the client has the service or network permissions required by your platform. Check the startup logs for failures creating the interface or adding routes.
2. Pause other VPNs, accelerators, and duplicate Clash clients. On managed work devices, follow your organization’s requirements before changing security software or corporate VPN settings.
3. Check for custom route exclusions or per-app bypass settings. Make sure the affected app and destination address aren’t excluded.
4. Check that dns-hijack matches your current core configuration. Intercepting traditional DNS traffic doesn’t decrypt an app’s own HTTPS DNS requests.
5. Restore a single, straightforward interception setup and test again. Avoid running system proxy, multiple VPNs, and complex route overrides simultaneously while troubleshooting.

If small pages load but larger pages or downloads stall, consider MTU or path issues only after ruling out node and site problems. Don’t change MTU as your first step. Save the current value, change one setting, compare the same request, and revert if it doesn’t help.

Summarize your findings: use the evidence to pinpoint the issue

After these checks, you should be able to tell whether the problem is an invalid configuration, a local port that isn’t listening, an app bypassing the system proxy, a misapplied rule, or a problem with the node or DNS path. If you still need help, the details below are more useful for diagnosing the issue than a screenshot that only says “connected, but nothing loads.”

• Operating system, client name and exact version, and core name and version. Find these in the client’s About page or startup logs.
• Actual listening port, system proxy and TUN status, and whether the issue affects only one browser.
• Results for the same URL using an explicit proxy, Rule mode, and Global mode, plus the exact time of each test.
• The rule, proxy group, and log error for the failed request. Hide account details, subscription tokens, and sensitive addresses.

When you’re done, restore any temporary changes to proxy mode, browser Secure DNS, and log level. Keep only changes you’ve confirmed are effective. Before reinstalling the client, back up local overrides and rules. Reinstalling won’t fix an expired subscription, a dead node, or a site that’s refusing access.