Clash Connected but No Internet? Troubleshoot System Proxy, DNS, and More

1. Separate Connection Status from the Actual Request Path

When a client shows “Running” or “Connected,” it usually means only that the core has started or a system VPN interface has been created. A successful node latency test only confirms that the test address was reachable at that moment. Browser requests still need to pass through the proxy listener, match a rule, select a proxy group, connect to a node, and resolve the domain. A failure at any step can prevent a page from loading.

Save your current configuration first, and note the client name, client version, core name, and core version. Clash is a common name in the configuration ecosystem; Clash Meta later became known as mihomo. Different clients bundle different cores and menus, so don’t assume a toggle in one interface exists in every version.

Start with Three Baseline Checks

1. Temporarily turn off the system proxy and TUN, then try a website that normally works without a proxy. If it still won’t load, check Wi-Fi, your gateway, any captive portal, and system networking first. Don’t start by changing proxy rules.
2. Restore your original settings and test the same URL in a browser and from the command line. Keep the test target consistent so differences between websites aren’t mistaken for a client problem.
3. Open the client’s Logs and Connections pages. Note the test time, target domain, matched rule, proxy group, and exact error. Before sharing logs, redact subscription URLs, passwords, tokens, and node credentials.

2. Check the System Proxy and Local Listening Port

The system proxy affects apps that use system proxy settings; it doesn’t route every program. Browser extensions, Firefox’s separate proxy settings, and terminal environment variables can override those settings. The examples below use 127.0.0.1:7890 as an HTTP or mixed listener. Check the active configuration for the actual port—don’t assume every client uses 7890.

Check the Proxy Settings for Your Platform

• Windows 11: Open Settings → Network & internet → Proxy → Manual proxy setup. If you use a manual proxy, make sure the address and port match the client. If you use a setup script, check its URL and remove any untrusted, outdated scripts.
• macOS: Open System Settings → Network → select your current network service → Details → Proxies. Check the web proxy, secure web proxy, or automatic proxy configuration. After switching between Wi-Fi and Ethernet, verify the settings for the active service.
• Android: Most Clash-based clients route traffic through the system VPN service. Check VPN permissions, per-app routing lists, and whether another VPN is using the single active VPN connection. Desktop manual proxy instructions don’t apply here.

Test with an Explicit Proxy

# Use curl.exe in Windows PowerShell; use curl on macOS/Linux
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/

The first command explicitly uses the local proxy; the second bypasses proxy environment variables and attempts a direct connection. The domain is for demonstration only—replace it with the site you’re troubleshooting. If the first command works but the browser doesn’t, check the browser’s proxy source and extensions. If you see Failed to connect to 127.0.0.1, check the local listener before changing the remote node.

When HTTPS traffic goes through an HTTP proxy, 200 Connection established in the output means only that the CONNECT tunnel was created. You should also see an HTTP response from the destination site. A 403 or 405 means the server responded, but doesn’t mean the page itself is accessible. Some sites also reject HEAD requests; try again without -I.

3. Check for Port Conflicts and Stale Processes

An open client window doesn’t mean the core successfully bound its port. If two clients start at once, common errors include address already in use and bind failures. The system proxy may still point to 7890 while an old client—or a background service with an invalid configuration—owns that port.

# Windows PowerShell: find the process listening on a port
Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS: find the process listening on a port
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux: find the process listening on a port
ss -ltnp 'sport = :7890'

1. Identify the program associated with the listening process and confirm that it belongs to the current client. In Windows, use the Details tab in Task Manager to look up the PID.
2. Exit any clients and background services you no longer use, then restart the client you want to use. Don’t terminate system processes based on a port number alone.
3. If you switch to another available port, such as 7892, update the system proxy and test commands as well. Then check which port is actually listening.

port usually provides an HTTP proxy listener, socks-port provides a SOCKS listener, and mixed-port accepts both HTTP and SOCKS connections. Sending an HTTP request to a SOCKS-only port may fail. external-controller is a control API, not a web proxy listener—don’t enter its port in your system proxy settings.

4. Check Proxy Group Selection and Rule Matching

Successfully importing a subscription only means the configuration loaded. A proxy group referenced by a rule may still be set to DIRECT, a dead node, or another nested group. Open the connection details, find the request for the target domain, and follow the proxy chain to its final exit. Don’t rely only on the node name shown on the home screen.

Narrow It Down by Switching Modes

1. In Rule mode, visit the target and note the matched rule and policy. Rules are generally evaluated in order, so a broad rule near the top may catch the request first.
2. Briefly switch to Global mode and confirm that the GLOBAL group actually selects the node you want to test. Global mode can also select DIRECT, so don’t rely on the mode name alone.
3. Reload the page and watch for a new connection. If Global mode works but Rule mode doesn’t, check the rule order, whether rule sets loaded, and the selections in the relevant proxy groups.
4. Switch back to Rule mode after testing. Global mode is a diagnostic tool; it won’t fix DNS, a dead node, or a local port problem.

# Rule order example: for illustration only; don’t replace your full subscription
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

In this snippet, example.com and its subdomains match the direct rule first; only the final rule sends all other requests to PROXY. PROXY must be an existing proxy or proxy group in your configuration. If the target requires a proxy, an earlier direct rule can explain why other sites work but that one doesn’t.

After switching nodes, establish a fresh test connection. Browser connection reuse may keep the old route alive; if needed, close only the relevant active connection and try again. A node showing a latency value doesn’t guarantee that the target site is reachable—or that the node supports the UDP transport the request needs.

5. Use the Error to Check DNS and Resolution Paths

Common clues for DNS problems include no such host, lookup failed, and resolution timeouts. But i/o timeout can also occur while connecting to a node or destination, so check the target address in the logs. First determine whether the node’s hostname or the website’s hostname failed to resolve; the two require fixes in different places.

Distinguish System DNS from Core DNS

# Query the system's default resolver
nslookup example.com

# Use only if the core is actually listening on 127.0.0.1:1053
# Requires dig to be installed on the system
dig @127.0.0.1 -p 1053 example.com A

A successful nslookup doesn’t prove that core DNS is working; the two may use different upstream resolvers. A failure also doesn’t prove that requests resolved through the proxy will fail. A domain accessed over HTTP CONNECT may follow a different resolution path from an app that resolves the domain locally before connecting.

In mihomo DNS settings, fields such as nameserver, nameserver-policy, and proxy-server-nameserver affect different scenarios. Check that your core version supports the fields you use. If rules determine which upstream handles DNS, also check for a circular dependency: DNS access requires a node, but connecting to the node requires DNS. Don’t paste an entire DNS block from another subscription.

Fake-IP and Browser Secure DNS

Fake-IP mode returns a virtual address for later mapping; it isn’t the destination site’s real address. Common configurations use the 198.18.0.0/16 range. Seeing an address in that range doesn’t by itself mean DNS has been poisoned; check whether the subsequent connection still reaches the same core that handles the mapping. Add an entry to fake-ip-filter only when you’ve confirmed an app compatibility issue that requires the real IP.

With Secure DNS enabled, a browser may bypass the system resolution path you expect. Temporarily turn it off to compare results, then restore your preferred settings. After changing DNS, run ipconfig /flushdns on Windows to clear the system cache. Browsers and the core may also have their own caches, so test them separately. Don’t treat permanently disabling security features as a general fix.

6. Check Routing and Permissions Only If TUN Fails

If access works with TUN off and an explicit HTTP proxy, but fails with TUN on, check the virtual network adapter, system routes, DNS interception, and other VPNs first. TUN routes traffic through a virtual network interface; what it captures still depends on routing and exclusion settings. It doesn’t guarantee that every app or protocol will work automatically.

• Permissions: Desktop clients often need administrator privileges or a helper service to create the interface and change routes. Check whether the service is running instead of repeatedly toggling the setting.
• Routes: Use route print on Windows, netstat -rn on macOS, or ip route on Linux to inspect routes. Save the output first; don’t delete the default route.
• Interface selection: When Ethernet, Wi-Fi, and virtual machine adapters are connected at the same time, the automatically selected exit may not be the one you expect. Temporarily limit testing to a single interface with working internet access.
• VPN conflicts: Corporate VPNs, other proxies, and virtual networking tools can change routes. If permitted, quit them one at a time to compare results. On managed devices, follow your organization’s policies.
• Protocol and MTU: If small requests work but large pages or downloads stall, check UDP, path MTU, and fragmentation. Don’t change the stack or MTU values at random without evidence.

7. Pinpoint the Cause and Restore Your Settings

After these checks, place the issue in a specific category. Useful troubleshooting notes should state which entry point and destination you tested, which mode was active, and what error appeared—not just “it still won’t connect.” Use the results table below for a final check.

After fixing the issue, restore Rule mode, your original security settings, and any required network interfaces. Then retest a subscription update and your commonly used sites. If subscription updates overwrite local changes, use the client’s supported override or merge mechanism to preserve them. Verify the merged runtime configuration—not just the original text in the editor.

When asking for help, include the client and core versions, operating system version, system proxy or TUN status, actual listening port, test command, and redacted logs from the same time period. Focus on one reproducible request at a time; that usually makes the cause easier to find than reinstalling the client.