1. Separate “core is running” from “websites are reachable”
A client’s status usually only tells you that the core has started or the system proxy is enabled. A successful latency test only confirms that a test request worked at that moment. When your browser visits a different domain, it may use a different rule, policy group, or DNS path. So don’t assume the website is at fault just because the client says “Connected,” and don’t change the port, DNS, and rules all at once.
Before troubleshooting, note the client name, core type, active configuration, operating mode, and local listening port. Clash and Clash Meta (now called mihomo) don’t support exactly the same configuration options, and menus vary between clients. This guide uses feature names such as “System Proxy,” “Connections,” and “Logs”; operating system menus include their specific paths.
- Make sure the configuration is selected and active—not just successfully downloaded as a subscription.
- Note the browser error, such as
ERR_PROXY_CONNECTION_FAILED,ERR_NAME_NOT_RESOLVED, or a connection timeout. - Choose one failing URL as your test case. After each change, retry the request and record the result.
- Temporarily quit other proxy clients, browser proxy extensions, and network acceleration tools to prevent multiple apps from changing proxy settings at once.
2. Turn off the proxy and check your baseline network connection
First, turn off the client’s system proxy and TUN, then check for any manual proxy settings left in the operating system. In Windows 11, go to Settings → Network & internet → Proxy. On macOS, go to System Settings → Network → your current connection → Details → Proxies. If you use a PAC auto-configuration script, note its URL so you don’t confuse PAC settings with a manual proxy.
Next, visit a site that should be directly accessible on your current network, and check whether the Wi-Fi network requires sign-in. On hotel, campus, or public Wi-Fi, the client can start normally but won’t bypass an unfinished captive portal login. You can run this command in a terminal to see whether a direct HTTPS connection works:
curl -I --noproxy "*" --connect-timeout 10 https://example.com/On Windows, use curl.exe to avoid older versions of Windows PowerShell interpreting curl as a different command. This tests only the specified site, so a failure doesn’t prove that your entire network is down. Retry with another site that’s normally accessible on your network or with a phone hotspot. If you can’t reach your router’s admin page or other normally accessible sites with all proxies off, troubleshoot network access, sign-in, or system network settings first.
3. Check the system proxy address and local listening port
Check the port before enabling the system proxy
Find the HTTP or mixed port in the client settings, then compare it with the proxy address in your operating system. For example, if the configuration listens on mixed-port: 7890, you can set the manual proxy on the same computer to 127.0.0.1:7890. 7890 is only an example, not a universal default. If the client shows 7897, use that actual value in both the command and system settings.
HTTP proxy ports and SOCKS-only ports aren’t interchangeable. If the system points to a port that isn’t listening, your browser will often report a proxy connection failure. You can bypass the system proxy settings and explicitly specify an HTTP proxy to test the connection:
curl -I --proxy http://127.0.0.1:7890 --connect-timeout 10 https://example.com/- Explicit proxy works, but the browser fails: Check whether another program changed the system proxy, a browser extension overrides the settings, or the browser uses a separate proxy configuration.
- Immediate “Unable to connect to 127.0.0.1” error: First check that the core is running and the port is listening. There’s no need to change the remote node yet.
- Shows 200 Connection established, then fails: This only means the HTTP proxy accepted the tunnel request. It doesn’t confirm that the subsequent TLS handshake or web response succeeded.
- Returns 407: Check whether the local proxy requires authentication. Don’t mistake an authentication failure for a node timeout.
Confirm that the current client owns the listening port
In a Windows terminal, run the following command to check the listening state and process ID. On macOS, use the second command to see which process is listening:
netstat -ano | findstr ":7890"
lsof -nP -iTCP:7890 -sTCP:LISTENIn the Windows output, check the local address and LISTENING status, then go to Task Manager → Details and match the process by PID. The mere appearance of the port number doesn’t mean it’s listening correctly. If an old client is using the port, quit it normally or assign the current client an unused port and update the system proxy to match. For use on this computer only, you usually don’t need to enable “Allow LAN.”
4. Use connection logs to identify rules and policy groups
Keep Rule mode enabled, open the client’s “Connections” or “Logs” page, then reload the page that fails. Note the destination domain, matched rule, policy group, and final outbound route. Existing long-lived connections may continue using the old route after you switch nodes, so close the relevant connection or restart the browser before testing again. If there’s no record, first make sure the logs aren’t filtering out the request. If it’s still missing, go back and check the proxy entry point.
| What you see | Check first | What to do next |
|---|---|---|
| The destination connection matches REJECT | Domain rules, rule sets, and ad-blocking rules | Find the specific rule and check whether it’s mistakenly blocking a login, verification, or static asset domain |
| The destination connection uses DIRECT | Whether the site should be accessed directly on your current network | Check the matched domain rule and the final fallback rule |
| The connection uses a proxy group but still times out | The node actually selected in the group and any nested policy groups | Switch to another working outbound node and retry the same URL |
| Only some resources fail to load | The outbound routes used by images, scripts, and API requests | Check each failing domain, not just the main site domain |
Clash evaluates rules in order, and the first match takes effect. A broad DOMAIN-SUFFIX rule near the top can prevent a more specific rule below it from being reached. If you suspect a rule issue, briefly switch to Global mode and explicitly select a working node for comparison. If the same URL works in Global mode but not Rule mode, compare the outbound route and matched rule instead of leaving Global mode on to mask a configuration problem.
5. Tell system DNS issues apart from core DNS issues
A browser’s domain resolution error doesn’t necessarily mean the system DNS is at fault. The system resolver, browser Secure DNS, core DNS, and remote node may all be involved; the actual path depends on the proxy method and configuration. First, run this command to check the system resolver’s response for the target domain:
nslookup example.comA successful nslookup only means the system-side query received a response; it doesn’t prove that the upstream used by the core is working. Conversely, a failed system query doesn’t mean a request that resolves the domain through the proxy will also fail. With an HTTP proxy for HTTPS, the client can usually see the destination domain. SOCKS tests also differ in where DNS resolution occurs: socks5:// and socks5h:// aren’t equivalent. Keep that distinction in mind when comparing results.
Check each step of the actual DNS resolution path
- Search the logs for
DNS,resolve, andtimeout. Check the domain that failed and the upstream address; don’t look only at the last timeout entry. - If DoH or DoT is enabled, make sure the upstream address is reachable. If the upstream is a domain name, also check that its bootstrap resolution doesn’t create a dependency loop.
- Temporarily turn off the browser’s “Secure DNS” setting for comparison, then restore it after testing. The browser’s own encrypted DNS connection may take a different path from the system resolver.
- With fake-ip enabled, an address in the
198.18.0.0/15range doesn’t automatically indicate a DNS error. Check whether the core intercepts the subsequent connection and correctly restores the domain name.
After changing DNS on Windows, run ipconfig /flushdns to clear the system cache. You may also need to clear the core and browser caches separately. Don’t use direct access to a site’s IP as a substitute for a full test: HTTPS sites rely on the domain name for certificate verification, SNI, and virtual host selection, so an IP address failure may have nothing to do with DNS.
6. Check TUN only after the system proxy works
If explicit proxy and the browser’s system proxy both work, but the network fails only when TUN is enabled, focus on the virtual network adapter, routing, and DNS interception. TUN handles IP traffic routed through the virtual adapter, but it doesn’t guarantee that every app or network environment will be configured correctly automatically. Insufficient permissions, driver problems, or routes added by another VPN can all send traffic through the wrong interface.
- Permissions and services: Make sure the required service mode or administrator approval is in place, and check that the core explicitly reports a successful TUN startup.
- Routing conflicts: Temporarily disconnect other VPNs, then compare routes before and after enabling TUN with Windows
route printor macOSnetstat -rn. - DNS interception: Check that
dns-hijackin the configuration matches the actual DNS path. Don’t assume that intercepting standard port 53 will also intercept browser DoH. - IPv6 routing: When a domain returns both A and AAAA records, check the IPv4 and IPv6 routes and interception separately. Don’t assume all traffic is working just because an IPv4 test succeeds.
If pages load but large images or downloads stall, you can also investigate packet loss, MTU, and protocol differences. Do this only after confirming that the proxy entry point, rules, and DNS are working. Changing MTU without evidence adds variables and makes the original issue harder to reproduce.
7. Check the upstream and browser if only certain sites fail
If the same site fails in multiple browsers while other sites work, try another node for that destination and check the subscription status, node protocol settings, and system time. An inaccurate system clock can cause TLS certificate verification to fail. A successful subscription update only confirms that the configuration downloaded; it doesn’t mean every node is still working.
If only one browser has the issue, test with a new profile that has no extensions enabled, then check its separate proxy settings, Secure DNS, cache, and site permissions. Incognito mode may still allow some extensions to run, so it doesn’t rule out all extensions. If you encounter a certificate error, note the error code and certificate issuer. Don’t install an untrusted root certificate just to dismiss the warning.
Low node latency but slow websites can also result from the site’s distance, packet loss, limited bandwidth, or server-side throttling. A single latency test can’t replace a real web request. Compare the same URL on the same network and at the same time of day; otherwise, you may wrongly attribute a difference to a setting you just changed.
8. Record your findings and restore your usual settings
When you’re done troubleshooting, switch back to Rule mode, undo temporary changes that didn’t help, and confirm that the system proxy port matches the client before deciding whether to enable TUN. If the entire network stops working after you quit the client, first check whether the system still points to a local proxy that’s no longer listening. Don’t reset the whole network straight away.
If you need more help, reproducible details are more useful than “it says connected but nothing loads.” Gather the information below, and redact subscription URLs, access tokens, node passwords, your public IP address, and other sensitive data:
- The exact versions of your operating system, client, and core, and whether you’re using the system proxy or TUN.
- The failing domain and browser error code. Don’t share the full URL if it contains a login token.
- The local listening port, result of the explicit proxy test, and whether a direct connection works.
- The matched rule, policy group, final outbound route, and relevant error logs for the same request and time period.
- What changed after switching nodes, turning off TUN, or changing networks.
Follow this order: local network → proxy entry point → listening port → rule and outbound route → DNS → TUN and upstream. Change one thing at a time and verify it with the same request. That’s how you turn a status that merely “looks normal” into a connection result you can explain.