Clash Connected but No Internet? Troubleshoot Subscriptions, Modes, and DNS

First, distinguish “the core is running” from “the request succeeded”

When a Clash client shows “Connected,” it may only mean the GUI has connected to the local core or enabled the system proxy. That doesn’t prove your subscription’s nodes are working or that browser requests are using the right policy group. The full request path is: app sends a request → local proxy or TUN intercepts it → rules are matched → a policy group is selected → a node connects → the destination website responds. A failure at any point can leave a page spinning indefinitely.

Clash is a common name for a family of proxy cores and configuration ecosystems. Clash Meta later continued development under the name mihomo. Menus, override mechanisms, and core capabilities vary between GUI clients. Before troubleshooting, note the actual version on the client’s About or Core page. Use fields supported by that core, and don’t replace your current subscription with someone else’s entire YAML file.

Set up a repeatable test

1. Note the current configuration name, proxy mode, selected node in the policy group, HTTP or mixed port, and whether TUN is enabled.
2. Temporarily disable other VPNs, proxy clients, and browser proxy extensions to prevent conflicts. Keep any security software required by your organization enabled.
3. Choose one website you can normally access directly and one that requires your current proxy route. Use the same URLs for every test.
4. Open the client’s connection list and logs. Reproduce the issue once at Info level; briefly enable Debug only if you need more detail.

Step 1: Check that your subscription is valid and its configuration is loaded

“Subscription update successful” only means the client completed an update; it doesn’t mean your plan still has data or that the downloaded configuration is the one currently in use. Open the configuration or subscription page and confirm the right profile is selected. Then check the proxy page for the expected nodes and policy groups. If you still see old nodes, first make sure you didn’t update a different subscription that isn’t enabled.

• Plan status: Check your provider’s account page for the expiration date, remaining data, and device limit. Usage shown in the client often comes from subscription response headers and may be missing or delayed.
• Download errors: HTTP 401 or 403 usually indicates an authentication failure or access restriction; 404 may mean the URL is no longer valid; 429 means requests are being rate-limited. Don’t keep clicking Update.
• Invalid content: If the logs show a YAML parse error, an unknown field, or a missing policy group, check configuration compatibility first. HTML from a login or error page can’t be used as a Clash configuration.
• Remote resources: The main configuration may load while updates to proxy-providers or rule-providers fail, leaving nodes missing or rules different from what you expect.

If your subscription can only be updated through a proxy and all current nodes are unavailable, try another working network or an official backup subscription URL if your provider allows it. Don’t paste your full subscription URL into an unfamiliar converter or public forum: its access token is usually equivalent to your account credentials.

Step 2: Test nodes instead of relying on latency numbers

A successful latency test only shows that a probe got a response from a specific test address at that moment. Reaching the test server doesn’t mean you can reach your destination, and an 80 ms result doesn’t guarantee enough bandwidth. Web pages involve DNS, TLS, multiple resource domains, and sometimes UDP requests—far more than a single probe.

Manually select nodes to compare

1. Manually select a node in the policy group that handles the target traffic. This prevents an automatic selection group from switching routes while you troubleshoot.
2. Visit the target website and note the time, node name, and error in the logs. Switch to a different route and repeat the same request.
3. Try again using your phone’s hotspot. If the same node only fails on one Wi-Fi network, check that network for outbound restrictions, a captive portal, or DNS issues.

In the logs, connection refused usually means a connection target actively refused the request; i/o timeout means an operation didn’t complete in time. Check the target address in the error to identify which hop failed. Don’t enable certificate verification bypass just to hide a TLS error. First correct the system time and verify the node settings.

Step 3: Use proxy modes to narrow down the problem

In Rule mode, the rule list determines which policy handles each request. Global mode sends requests intercepted by the core to the global policy, while Direct mode connects to the destination directly. “Global” refers to the outbound policy; it doesn’t mean every app automatically uses Clash. Apps without a system proxy, explicit proxy settings, or TUN interception may still bypass the core.

1. Reproduce the issue in Rule mode first. Note the matched rule and outbound route shown in the connection list.
2. Temporarily switch to Global mode, explicitly select the node verified in the previous step, and open the same page again.
3. If Global works but Rule mode doesn’t, focus on rules, policy groups, and the direct DNS resolution path. If both fail, keep checking the proxy entry point and DNS.
4. When you’re done testing, switch back to Rule mode so traffic that doesn’t need a proxy isn’t sent through a global route long-term.

Step 4: Make sure the system proxy matches the local listening port

These commands assume the client is using mixed-port: 7890. 7890 is only an example—replace it with the actual port shown in the client. A mixed port accepts both HTTP and SOCKS proxy connections; don’t enter a standalone SOCKS port as an HTTP proxy. On a desktop, the local proxy address is usually 127.0.0.1. You don’t need to enable LAN sharing for a browser on the same computer.

Check system settings and test an explicit proxy request

On Windows 11, check manual proxy settings and setup scripts under Settings → Network & internet → Proxy. On macOS, go to System Settings → Network → your current network service → Details → Proxies. When the client controls the system proxy, these settings should match its actual listening port. Some browsers have separate settings. In Firefox, for example, check Settings → General → Network Settings → Settings and confirm whether it uses the system proxy or another manual port.

In Windows PowerShell, check that the port is listening, then test with an explicit HTTP proxy request. Use curl.exe to avoid interference from the same-named alias in older PowerShell versions.

Get-NetTCPConnection -State Listen -LocalPort 7890
curl.exe -I --connect-timeout 10 --max-time 20 -x http://127.0.0.1:7890 https://example.com/
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/

On macOS and Linux, use the request below for comparison. The URL is a public example; replace it with the site you can’t reach. -I sends a HEAD request. If the site doesn’t support HEAD, use -o /dev/null -v to send a regular GET request instead.

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

• Can’t connect to 127.0.0.1 right away: Check that the core is running, the port hasn’t changed, and the listening process belongs to the current client.
• Explicit proxy works, but the browser doesn’t: Check browser proxy extensions, PAC scripts, separate proxy settings, and stale cached connections first.
• HTTP 407 appears: Check whether the local proxy requires authentication. Don’t assume the remote node is at fault.
• The connection tunnel is established, then TLS fails: Establishing a tunnel doesn’t mean the page loaded successfully. Check the TLS error and core logs next.

--noproxy "*" only bypasses curl’s application-level proxy settings; it doesn’t bypass TUN or another VPN. To compare with a true direct connection, note the original state and temporarily disable the relevant traffic interception. Terminals may not use the desktop system proxy either. Check HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY to make sure an old environment variable isn’t sending requests to another port.

Step 5: Identify which layer is experiencing DNS failures

DNS can involve at least three different targets: the node server’s hostname, the domain you’re visiting, and the hostname of the encrypted DNS service itself. If the node server’s hostname can’t be resolved, the proxy tunnel may not even come up. If the destination hostname fails to resolve, only certain websites may be affected. And if the DNS upstream depends on a proxy route that isn’t established yet, it can create a dependency loop.

Check what’s happening before changing DNS

1. Look for log messages such as lookup, no such host, or DNS timeout, and note the domain involved.
2. On Windows, use Resolve-DnsName example.com; on macOS or Linux, use nslookup example.com to check system DNS, then compare the result with the client logs.
3. Check your browser’s Secure DNS setting. Built-in DoH can change the DNS resolution path. Briefly turn it off to retest, then restore it if needed.
4. Only if you’ve confirmed the system cache is stale, run ipconfig /flushdns on Windows and establish a new browser connection.

A successful system DNS query doesn’t prove the core’s DNS is working: they may use different upstreams. Conversely, a failed system query doesn’t necessarily prevent a proxied domain request from working, since the core or remote server may handle resolution. Don’t replace every DNS field based on a single nslookup result.

With fake-IP mode enabled, seeing a synthetic address from the configured fake-ip-range can be normal—for example, the commonly used 198.18.0.0/16. These addresses let the core map domains to connections; they aren’t real website addresses. If an app receives a synthetic address but its connection doesn’t return to the core handling it, the request will fail. Check routing, DNS interception, and conflicts with other VPNs instead of adding synthetic addresses to hosts.

Step 6: Check rule matches and the policy group’s final outbound route

If Global mode works but Rule mode fails, open the connection list, find the request by destination domain, and inspect the matched rule and policy chain. Rules are usually evaluated from top to bottom; a broad rule near the top can capture a request before a later rule applies. MATCH is the final fallback and shouldn’t come before rules you still want to take effect.

This example shows rule order only; it isn’t a complete configuration you can use to replace a subscription. It routes example.com and its subdomains through the policy group named “Web Proxy” and sends other connections direct. Before using it, make sure that group exists and has a working node selected.

rules:
  - DOMAIN-SUFFIX,example.com,Web Proxy
  - MATCH,DIRECT

• Matched DIRECT: Check whether a direct connection is expected and whether the website is reachable directly on your current network.
• Matched REJECT: Check whether a blocking rule or rule set incorrectly includes the destination domain. Don’t disable all protections at once.
• Matched a proxy group, but the request still fails: Expand the policy chain and check the final node in any nested groups. Groups with the same name don’t necessarily use the same outbound route.
• The main page loads, but images or sign-in fail: Check the CDN, authentication, and API domains. Those requests may match different policies.

Rule-set download failures, local client overrides, process rules, and subscription updates can all change the effective configuration. Check the running configuration and connection records, not just the original subscription file. After making a change, start a new connection; existing long-lived connections may keep using the old route.

Step 7: Check TUN, IPv6, and UDP only if needed

If an explicit proxy works in the browser but games, terminal apps, or other applications fail, first check whether those apps support proxies. Not every program follows the system proxy setting. Consider TUN only when you need to intercept more traffic. TUN still needs correct routing, permissions, and DNS; switching it on won’t automatically fix every issue.

• TUN and permissions: Make sure service mode or the required permissions are in place, and check the logs for virtual interface or route creation errors.
• Network conflicts: Temporarily disable another nonessential VPN and test again. Look for conflicts involving route priority, virtual adapters, or DNS interception.
• IPv6: Check whether the destination has an AAAA record and whether the connection is using IPv6. If IPv4 works but IPv6 fails, fix the relevant route or outbound path. Don’t disable IPv6 system-wide as a default workaround.
• UDP and QUIC: Some browsers use HTTP/3 over UDP 443. If TCP requests to websites work but UDP apps fail, check whether the node protocol, server, and local traffic interception support that UDP route.

If needed, briefly disable browser QUIC for comparison, but don’t treat it as a universal speed setting. If large pages stall while small requests work, also consider path MTU, packet loss, and network congestion. Keep a record of how to reproduce the issue, and don’t try a series of MTU values at random.

Wrap up: restore a minimal configuration and document the issue

Once you’ve identified the cause, restore Rule mode, your usual DNS settings, and the traffic interception you need. Revert temporary changes made only for comparison. Don’t leave the system proxy pointing to an inactive port after closing the client. If no websites load after you quit, first check whether the system proxy still points to 127.0.0.1:7890 instead of immediately reinstalling your browser.

Include this information when reporting the issue

• Operating system, client, and actual core versions; whether TUN, the system proxy, and browser Secure DNS are enabled.
• When the issue occurred, the destination domain, reproducible steps, and whether it affects every website or just a few.
• How the same destination behaves in Rule mode, Global mode, with another node, and on another network.
• Redacted error logs, the matched rule, and the final outbound route. Don’t share subscription tokens, node passwords, or credentials from your full configuration.

“I restarted several times” is less useful than “the explicit proxy works, but the browser fails” or “Global works, but Rule mode fails after matching DIRECT.” Evidence from each stage of the request path narrows the problem down to the app entry point, node, DNS, or rules—and avoids new issues caused by repeated configuration changes.