Clash Connected but No Internet? Follow This Troubleshooting Checklist

First, identify what “Connected” actually means

“System proxy enabled,” “VPN connected,” or “Core running” in a Clash client only means that the local proxy entry point is active. It does not confirm that the remote node works or that browser traffic has entered Clash. The full path includes at least seven stages: the app, the system proxy or TUN, the mihomo core, rule matching, DNS, the proxy node, and the destination website. A failure at any stage can leave the switch showing as enabled.

Do not change the node, DNS, rules, and TUN at the same time. Test one layer at a time and keep reproducible results for each step. Prepare three targets: a local router address, a site that works without a proxy, and a site that requires a proxy policy. This quickly shows whether the issue is in the local network, direct connection, or proxy path.

Narrow it down by four symptoms

Step 1: Confirm that the node, subscription, and policy group work

Open the client's Proxy or policy page and find the policy group currently carrying traffic. Many configurations use a top-level group named “Node Select,” “Proxy,” or “GLOBAL,” with another layer for automatic selection, failover, or regional groups. The node name shown on the home screen does not necessarily identify the final exit. Open each policy group and make sure the chain has not selected DIRECT, REJECT, or an inactive child policy group by mistake.

Do not rely on latency alone

Latency tests usually access the test URL configured in the profile. A result of 80 ms or 200 ms only means that URL responded at that moment. Connections to the target site can still fail because of TLS handshakes, congestion, server rate limits, or differences in UDP support. Select a known-stable node manually, visit two different domains in succession, and then review the connection log.

• Latency shows “Timeout”: switch to two nodes in different regions to rule out a single-node failure.
• All nodes time out: check the local network, subscription status, and DNS resolution for the node server domains.
• Latency is normal but websites fail: inspect policy matching, DNS, and TLS errors instead of repeatedly running speed tests.
• Only UDP apps fail: the node protocol or server may not provide working UDP forwarding, or TUN may not be intercepting UDP.

Refresh the subscription and check its update time

An expired subscription does not always appear as an “import failed” error. The client may retain the old configuration and continue showing its node list. Open the “Profiles” or “Subscription” page, run an update manually, and record the new timestamp and response. A 401 or 403 means you should check subscription access. For a timeout, first open the subscription domain over a direct connection. If the response cannot be parsed, you may have received a login page, notice page, or incompatible text format.

After updating, confirm that the newly refreshed profile is active rather than an older copy with the same name. Some desktop clients require you to click the profile again in the list to enable it. If the configuration uses providers, check their update times too: a successful main-profile update does not mean the remote node collection was synchronized.

Step 2: Check the local proxy port and system proxy

On desktop, the most common break point is a mismatch: the core listens on one port while the operating system or browser points to another. Typical setups use HTTP port 7890 and SOCKS5 port 7891, or enable only a mixed port such as 7890. Port numbers are not universal standards, so always use the values shown in the active configuration and client settings.

Test the local port directly before troubleshooting the browser

In Windows PowerShell, a macOS terminal, or a Linux shell, use curl with an explicitly specified proxy. The example below assumes the mixed port is 7890:

curl -I --max-time 10 -x http://127.0.0.1:7890 https://example.com
curl -I --max-time 10 --proxy socks5h://127.0.0.1:7891 https://example.com

If HTTP response headers appear, the basic path from the app to the local proxy and from the proxy to the destination is connected. An immediate “Connection refused” usually means the port is not listening or was entered incorrectly. A timeout after 10 seconds points you toward the node and DNS. If HTTP proxying works but SOCKS5 fails, verify that socks-port is actually enabled.

A local proxy request on a healthy network usually returns response headers within 0.2 to 3 seconds. This is not a node-quality benchmark, but if every request consistently hangs until a 10-second timeout, inspect the core log instead of waiting for the browser to recover.

Verify the proxy address actually configured on the system

• Windows 11 24H2: open “Settings” → “Network & internet” → “Proxy” and check the address and port under “Use a proxy server.” The address is commonly 127.0.0.1, and the port must match the client.
• macOS 15: open “System Settings” → “Network” → the current network → “Details” → “Proxies,” then check Web Proxy and Secure Web Proxy. When the client manages these settings automatically, do not enter a second set of ports manually.
• Android 15: Clash clients usually route traffic through the system VPN interface, so you should not also enter 127.0.0.1 as a manual Wi-Fi proxy.
• Browser: make sure no proxy extension is enabled at the same time. An extension pointing to an old port can override or bypass the system proxy.

If direct access works after disabling the system proxy, but every request fails immediately when it is enabled, the break is probably after the local proxy port. Check the log for connection refused, handshake timeout, or a missing policy group. If no website works even with the system proxy disabled, fix the Wi-Fi, Ethernet, gateway, or system DNS first instead of adjusting Clash further.

Step 3: Separate DNS issues from proxy issues

“IP works, domain does not” is a classic DNS clue. Clash Meta, now commonly provided by the mihomo core, can resolve domains locally, match rules, and map Fake-IP addresses. If DNS hijacking, unreachable upstream resolvers, or Fake-IP traffic interception is incomplete, the browser may spin indefinitely while some apps report that the network is unavailable.

First, check whether the domain returns an answer

Run a system DNS lookup from the terminal. On Windows, use nslookup example.com; on macOS and Linux, use dig example.com. With Fake-IP mode, an address in the 198.18.0.0/16 range can be expected. That address must continue through mihomo so the core can restore the domain and apply rules. Do not immediately treat 198.18.x.x as a DNS error.

Focus on queries that consistently time out, return SERVFAIL, or produce a Fake-IP address without sending traffic into TUN. If Fake-IP entries remain cached after TUN is disabled, websites may temporarily remain unreachable. Disable the proxy, flush the system DNS cache, then restart the core and TUN.

Review the DNS structure in the configuration

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  fallback:
    - tls://8.8.8.8:853

This example illustrates the relationship between fields; do not overwrite an existing subscription without checking it first. Port 1053 is only a common local listening value. During troubleshooting, verify that dns.enable is enabled, the listening port is not occupied by another program, and the upstream addresses are reachable on the current network. If the configuration references a hostname-based DoH service, the bootstrap path used to resolve that hostname must also work. Otherwise, you can create a loop in which resolving the DNS server depends on that same DNS server.

When the log shows repeated DNS timeouts, temporarily switch to another upstream set recommended by the configuration provider for comparison. Change only nameserver; leave the node, rules, and TUN unchanged. If service returns immediately, the issue is likely with the original upstream or its access path. If it still fails, check port 53 hijacking, the firewall, and TUN routes.

Step 4: Rule out conflicts between TUN, the system proxy, and other VPNs

The system proxy mainly affects apps that actively read proxy settings. Games, command-line programs, some store apps, and UDP traffic may ignore it. TUN mode uses a virtual network adapter and routes to intercept more traffic, but it is also more likely to conflict with corporate VPNs, virtual machine networks, container networks, accelerators, and security software.

Use switch combinations to identify the interception layer

1. First disable TUN and enable only the system proxy. Test the browser and the curl command above.
2. If the browser works again, the node and HTTP proxy are basically healthy; focus on TUN routing, DNS hijacking, or permissions.
3. Then disable the system proxy and enable only TUN. Test the browser and an app that does not read system proxy settings.
4. If each works alone but they fail together, check whether the client is installing duplicate routes or running two DNS interception paths.
5. Finally, restore the combination recommended by the client. Do not rely on repeatedly switching modes as a permanent workaround for a configuration error.

Common mihomo TUN fields include enable, stack, auto-route, auto-detect-interface, and dns-hijack. Supported stack options vary by operating system and client. If the current gVisor path behaves abnormally, compare it with system when the client supports that option. After changing it, fully restart the core rather than merely toggling the system proxy.

After enabling service mode or TUN on Windows, you need the appropriate permissions to create the virtual adapter and write routes. Open “Settings” → “Network & internet” → “Advanced network settings” to check the virtual adapter. On macOS, first-time setup usually requires allowing the extension under “System Settings” → “General” → “Login Items & Extensions” → “Network Extensions.” On Android, confirm that a VPN badge appears in the status bar and check the system VPN page for another always-on VPN occupying the only interface.

Check which network adapter is being detected

After a laptop switches from Ethernet to Wi-Fi, connects to a hotspot, or wakes from sleep, its default route may change. If auto-detect-interface does not identify the active adapter correctly, TUN traffic may be sent back through a virtual interface, creating a routing loop. A typical symptom is that all latency tests time out with TUN enabled and recover immediately when it is disabled. Restart the core first. If that does not help, disconnect unused virtual adapters and old VPNs, then reconnect to the network.

Step 5: Use logs to confirm rules, handshakes, and connection errors

If the first four steps do not locate the issue, temporarily set the log level to info or debug. Common locations include “Settings” → “Log level” or “Settings” → “Parameters” → “Core.” After enabling logs, reproduce the failed request once and immediately inspect its domain. Do not let latency tests and background updates fill the log with unrelated entries.

Look for these key log clues

Rules are matched from top to bottom, and matching normally stops at the first hit. A custom DOMAIN-SUFFIX, IP-CIDR, or process rule placed before general rules can send a destination to DIRECT or REJECT by mistake. For testing, temporarily switch to Global mode and select a working node. If Global mode restores access, the node and basic proxy path are probably fine, so focus on rules or providers. If it still fails, continue checking the node, DNS, and TUN.

Global mode is useful only for a short comparison, not as the final fix. Once the cause is confirmed, return to Rule mode and correct the rule-set source, policy group name, or custom override. Policy names in the configuration must exactly match the names referenced by rules; differences in capitalization, spaces, or symbols can cause loading errors or fallback behavior.

Retest in a fixed order to avoid a “coincidental recovery”

After making changes, stop the core for 5 seconds and start it again. Then verify, in order: local network, DNS, local proxy port, node, rules, and TUN. Do not check only whether one webpage opens. Test both direct and proxied domains, browser and non-browser apps, and behavior after switching Wi-Fi.

1. Close Clash and confirm that the basic network can reach the local gateway and direct sites.
2. Start the core and confirm that the configuration loads without YAML field or provider errors.
3. Run a curl test using 127.0.0.1 and the current mixed port.
4. Confirm the subscription update time, active node, and top-level policy group selection.
5. Check DNS results and DNS logs, distinguishing expected Fake-IP addresses from genuine timeouts.
6. Retest with the system proxy first, then enable TUN alone to identify which combination causes the conflict.
7. Restore Rule mode and use the log to confirm that the request matched the expected policy.

If the issue occurs only on a corporate, campus, or hotel network, consider restrictions on UDP, specific ports, or encrypted DNS. A phone hotspot is the most effective comparison: if the same device and configuration work on the hotspot but fail on the original network, the scope narrows to the LAN gateway, captive portal, or network policy. Complete the portal login before starting Clash to prevent hotel Wi-Fi's sign-in page from being blocked by proxy rules.

The key is to test the shortest path first, then add interception layer by layer. Nodes, DNS, the system proxy, and TUN can all produce the same “connected but no internet” symptom, but their test results differ. Keeping each step's port, timestamp, logs, and switch combination is usually faster than repeatedly reinstalling the client.