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

1. First, clarify what “Connected” means

A Clash GUI showing that the core is running, the system proxy is enabled, or a node has a latency value doesn't mean your browser has successfully reached a website through that node. A web request passes through several layers: the app's proxy settings, the local listening port, rules and proxy groups, the node connection, DNS resolution, and the destination site. A failure at any layer can leave you with a working-looking client and a browser that spins endlessly.

First, note the client name, core type, active configuration, mode, and local proxy port. Menu names vary across Clash, Clash Meta (now mihomo), and different GUI clients. Use the labels shown in your current client for items such as “Proxy,” “Connections,” and “Logs”; find system settings under the menus for your operating system.

1. Save a copy of your current configuration and note the original system proxy and TUN settings.
2. Choose a website that reliably reproduces the problem. Change one setting at a time, then try again.
3. If other proxies, VPNs, or browser proxy extensions are running, quit them first to prevent multiple tools from repeatedly changing system settings.
4. Temporarily turn off Clash's system proxy and TUN, then test whether ordinary websites load directly. Restore the original settings afterward.

2. Make sure the system proxy points to the right port

The system proxy tells apps that follow this setting which local address to send requests to. It doesn't route traffic for the entire device, and it doesn't guarantee that command-line tools, games, or standalone apps will use the proxy. A browser proxy extension may also override the system setting.

Where to check on Windows and macOS

• Windows 11: Go to Settings → Network & internet → Proxy. Check the address and port under “Manual proxy setup,” and make sure no unexpected setup script is enabled.
• macOS: Go to System Settings → Network → your current network service → Details → Proxies. Check the web proxy, secure web proxy, and automatic proxy configuration settings.
• Android: Proxy clients often route traffic through a VPN interface, so desktop system HTTP proxy checks don't apply. Check VPN authorization, per-app proxy settings, and the app exclusion list.

Suppose your configuration uses 7890 as the mixed proxy port. The system proxy on your device should usually point to 127.0.0.1 on port 7890. This is only an example; use the listening port shown in your client. An HTTP proxy can tunnel HTTPS traffic with CONNECT, so don't change the system proxy address to a remote node just because a website uses HTTPS.

# Example local proxy settings; not a complete subscription configuration
mixed-port: 7890
allow-lan: false
mode: rule

mixed-port accepts both HTTP and SOCKS proxy connections. If your configuration uses separate port and socks-port settings, make sure you distinguish between them; don't enter a SOCKS-only port as the system HTTP proxy. After making changes, reload the configuration in the client and check the active port shown in its interface. A GUI override may not match the configuration file.

3. Narrow it down with a port check and an explicit proxy test

The system proxy can look correct while nothing is listening on the local port, leaving the browser unable to connect. Check the client logs for startup or configuration errors, address already in use, or bind errors. If a port is occupied, identify the process using it instead of terminating an unfamiliar system process.

Check whether port 7890 is listening

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

# macOS or Linux with lsof installed
lsof -nP -iTCP:7890 -sTCP:LISTEN

On Windows, use the process ID you found with Get-Process -Id to check the process name. macOS and Linux output usually shows the process directly. If nothing is listening, check whether the core actually started, whether the port has changed, and whether the listening address includes 127.0.0.1. If two copies of the client are running on the same device, quit the one you aren't using.

Bypass system settings and specify the proxy directly

On Windows, use curl.exe to avoid differences in how older PowerShell versions handle the curl alias. On macOS and Linux, you can replace curl.exe in the commands below with curl. The commands use example.com as a basic connectivity test; then replace the URL with the site that's actually failing and compare the results.

# Send the request explicitly through the local HTTP mixed proxy port
curl.exe --noproxy "" -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

# Control test without an application-layer proxy
curl.exe --noproxy "*" -I --connect-timeout 10 --max-time 20 https://example.com/

Note: --noproxy "*" only bypasses the application-layer proxy. If TUN is still enabled, the virtual network interface may still capture the request, so this isn't a true direct-connection test. Some sites don't accept HEAD requests. If you get 405, remove -I and try a regular GET request.

4. Check the proxy group, not just the latency

A node latency test usually checks only one test address. A successful test doesn't mean every website is reachable. A successful subscription update only confirms that the configuration downloaded and parsed; it doesn't mean the node is available, your account has data remaining, or the destination site allows traffic from that exit IP.

1. Open the client's “Proxy” or “Proxy Groups” page and find the group handling the traffic you're testing.
2. Check whether the group ultimately selects a specific node, another proxy group, DIRECT, or REJECT.
3. Manually select a known-working node and reconnect to the website. Don't stop troubleshooting after a single latency test.
4. If proxy groups are nested, check the final selection at every level. An outer group can show “Proxy” while an inner group routes directly.

You can briefly switch to Global mode as a comparison, and make sure the Global group has an actual node selected. If Global mode works but Rule mode doesn't, focus on the rules and groups. If both fail, check the node handshake, network blocking, or DNS. Restore your original mode afterward; don't treat Global mode as a permanent fix.

5. Check connection logs to see which rule matched

Rule mode typically checks rules in configuration order and applies the associated policy at the first match. A broad rule placed too early can prevent later domain-specific rules from taking effect. Don't guess based on rule names. In “Connections” or “Logs,” check the test domain, matched rule, policy, and final node.

# Rule order example; Proxy must match a policy name in your configuration
rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,LAN,DIRECT
  - MATCH,Proxy

This example illustrates rule order; it's not a rule template for every subscription. MATCH is a catch-all rule and should come after rules that need to match first. If your configuration uses rule providers, check that the relevant provider loaded successfully and that its associated policy exists.

• No request in the logs: First check whether the app is actually sending traffic through the proxy. However, TUN exclusions, how domains are displayed, and the log level can also affect what you see, so don't draw conclusions from a single empty log entry.
• Fails after matching DIRECT: Check whether the site should use the proxy and whether an earlier direct-connection rule is too broad.
• Matches REJECT: Check whether a blocking rule is catching login endpoints, static assets, or verification domains by mistake.
• Main page loads, but images or login fail: Check the domains used by those resources individually. Adding a rule for only the main domain in the address bar may not be enough.

For rule field definitions, see Configuration Field Reference. Before editing a file generated by a subscription, use the client's supported override or merge features. Direct changes to a cached file may be overwritten the next time the subscription updates.

6. Tell apart system DNS, core DNS, and Fake-IP

DNS problems aren't always solved by switching to another server. System lookups, browser Secure DNS, core DNS, and proxy server address resolution may follow different paths. First use the logs to distinguish a failed lookup, a DNS request timeout, a timeout connecting to the remote IP, and a failed TLS handshake. Then decide which layer to change.

Successful system resolution doesn't mean the core can resolve names

Run nslookup example.com to check the system's default DNS path. But that path may not be used if the browser has Secure DNS enabled or the proxy core resolves names itself. If mihomo's nameserver is set to a DoH address, check that the DoH service is reachable, its hostname can be resolved initially, and DNS requests follow the configured route.

Setting an upstream to https://dns.example.com/dns-query doesn't automatically fix an unreachable network. This is a syntax example only; the example domain isn't a working DNS service. For nodes configured with a hostname, also check whether the node hostname fails to resolve. Otherwise, the node may depend on itself to reach the DNS service it needs to connect, creating a circular dependency.

A 198.18 address may be a normal Fake-IP result

In Fake-IP mode, DNS commonly returns addresses in the 198.18.0.0/16 range. These are used by the core for mapping and aren't the website's real public IP addresses. This alone doesn't mean DNS has been hijacked; what matters is whether the same core handles the subsequent connection and can find the matching domain mapping.

• If system or app caches still contain Fake-IP addresses after you close the client, connections may fail. Restore the normal DNS path first, then clear the cache and restart the affected app.
• If only local network domains, printers, or a particular app are affected, check fake-ip-filter and local DNS settings for the specific domains. There's no need to replace the entire DNS section right away.
• If your browser has its own Secure DNS setting enabled, temporarily switch it to use system DNS for comparison. Decide which resolution method to keep after testing.

# Windows: Clear the system DNS cache
ipconfig /flushdns

# macOS: Clear the system resolver cache; the second command requires administrator authorization
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Clearing the cache won't fix an incorrect upstream configuration, and it may not clear the browser's own cache. After changing DNS, reload the core configuration and start a new test connection. Avoid changing the upstream server, Fake-IP mode, and all routing rules at once; even if access returns, you won't know which change fixed it.

7. If the system proxy works but TUN doesn't, check traffic routing

TUN routes eligible traffic through a virtual network interface; it isn't the same entry point as the system HTTP proxy. The most useful comparison is to turn off TUN and test the browser with only the system proxy. Once that works, turn TUN back on and compare. Android's VPN interface is related to desktop TUN, but authorization and routing are platform-managed, so the menus won't be identical.

1. Check permissions and services: See whether the client asks you to install a service or grant VPN or network extension permissions. An enabled switch doesn't mean routing was established successfully if the required permissions are missing.
2. Rule out other VPNs: Another VPN, security app, or virtual network adapter may change the default route or DNS. Quit them one at a time under controlled conditions and compare.
3. Check DNS interception: Make sure the DNS listener and dns-hijack settings are supported by your core and platform. Don't assume all DNS traffic will be intercepted.
4. Check IPv6: If the failed connection uses IPv6, make sure your route, node, and configuration support that path. Disabling IPv6 resolution in the core may not stop an app from using an IPv6 address it already has.

Don't start by changing the MTU or disabling the firewall. Check MTU, path MTU discovery, or UDP forwarding only if small requests work, larger transfers consistently stall, and the route and node are confirmed to be working. When checking the firewall, start by verifying the client's allow rules rather than leaving system protection disabled.

8. Record what happened and wrap up by failure layer

If the checks above haven't identified the problem, documenting a failed request is more useful than saying you've reinstalled several times. Record the test time, destination domain, system proxy port, mode, proxy group, matched rule, and the first relevant error in the logs. If only one site fails, consider site maintenance, account restrictions, or limits on the exit IP.

For certificate errors, check system time, configuration, and the trust chain. Don't routinely bypass certificate verification. If you need to raise the log level temporarily, reproduce the problem once and then restore your usual level. Remove subscription URLs, access tokens, node passwords, and other identifying information before sharing logs.

You should be able to answer three questions: Did the browser send the request to the core? Did the core select the expected rule and node? At what step did DNS resolution and the remote connection succeed or fail? Check each in order to narrow “connected but no internet” down to a specific, fixable problem instead of blindly changing the system proxy, node, and DNS over and over.