Clash Connected but Websites Won’t Load: Troubleshoot Proxy, DNS, and Rules

First, distinguish a running client from a working connection

“Connected” in a Clash client may mean the core is running, a configuration has loaded, or a VPN interface has been established on mobile. It doesn’t mean the target website has responded successfully. A latency reading next to a node only shows that the test address was reachable via that route; it doesn’t verify the website you’re troubleshooting.

Keep one website that you know works directly and one that actually fails open. Change one setting at a time, and note the browser error, request time, and connection logs. This helps you tell whether a change fixed a specific layer or the issue just happened to clear up.

Save your current settings: Note the configuration name, operating mode, mixed port, selected proxy group, and whether System Proxy and TUN are enabled.
Rule out basic network issues: Temporarily turn off the system proxy and TUN managed by the client, then test a website directly. Hotel, campus, and public Wi-Fi may require you to sign in first.
Avoid running multiple traffic-routing tools at once: Other VPNs, proxy apps, and browser extensions can change where traffic goes. Pause them one at a time, then restore your original settings after testing.
Check which core is running: Look in the client’s About page or startup logs to see whether it uses mihomo. Menus, DNS fields, and TUN features vary between clients and cores.

Layer 1: Make sure browser traffic reaches the local proxy

Check the system proxy address and local listener

The system proxy only works for apps that honor proxy settings; it doesn’t automatically route traffic from every program. In Windows 11, check the manual proxy under Settings → Network & internet → Proxy. On macOS, go to System Settings → Network → your current network service → Details → Proxies. Labels may vary by OS version.

On the same computer, an HTTP proxy usually uses 127.0.0.1 and the active mixed port. If you use an automatic proxy script, check that the current client is still serving the PAC URL. A browser proxy extension or Firefox’s separate connection settings can override the system configuration.

Use the command line to bypass automatic system proxy detection and specify the local port explicitly. These commands only apply to the current request and don’t change system settings. On Windows, use curl.exe to avoid environments where PowerShell treats curl as an alias for another command.

# macOS / Linux
curl -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

# Windows PowerShell
curl.exe -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

example.com is a real domain used here to illustrate the commands. Run the same test against the website that won’t load. -I sends a HEAD request; a 403 or 405 still means you received an HTTP response, but doesn’t confirm that the page itself will load properly.

Test result	Likely cause	Next step
Connection to 127.0.0.1:7890 refused	Nothing is listening on that port, the core isn’t running, or the port is incorrect	Check the startup logs and configured listening port
Explicit proxy returns a response, but the browser still fails	System proxy isn’t active, or the browser uses separate proxy settings	Check proxy extensions, PAC, and browser connection settings
Local proxy connects, then times out	The local entry point works; the issue may be DNS, rules, or outbound routing	Check the core’s connection logs around the request time
A 407 response appears	The proxy requires authentication	Check local proxy authentication settings and request credentials

Verify with the connection list, not just the toggle

Open the client’s connection list, refresh the target website, and look for the same domain or destination IP. Requests using the regular system proxy should usually appear in the connection log. If there’s no new entry, check the browser’s proxy settings first; don’t change DNS yet. If TUN is enabled, even a regular direct command may be routed through it, so a command without an explicit proxy doesn’t necessarily bypass the client.

Layer 2: Distinguish system DNS, core DNS, and proxy-side resolution

If a page shows ERR_NAME_NOT_RESOLVED, first find out which component is resolving the domain. The browser may use Secure DNS, the operating system may query the router, mihomo may use a separate upstream, or the proxy protocol may pass the domain to a remote server. These paths can return different results.

Check system DNS first, then compare proxy requests

# Replace example.com with the domain that is actually failing
nslookup example.com

# SOCKS5: resolve the destination domain locally
curl -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5://127.0.0.1:7890 https://example.com/

# SOCKS5h: pass the destination domain to the SOCKS proxy
curl -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7890 https://example.com/

On Windows, use curl.exe for the last two commands. A mixed port can accept both HTTP and SOCKS requests; if you only have an HTTP port configured, use the actual SOCKS listening port instead. socks5h passes the destination domain to the local SOCKS proxy. Whether the core or a remote server resolves it still depends on the rules and outbound protocol.

Local resolution fails, but the proxy request succeeds: Check system DNS, browser Secure DNS, and whether they use different network routes.
Both requests fail: Don’t assume DNS is the cause. Check the core logs for resolution timeouts, rule matches, or outbound connection failures.
System resolution succeeds, but the browser still errors: Check browser Secure DNS; it may not be using the result returned by the system resolver.

Understand the limits of fake-IP and DNS hijacking

When mihomo uses fake-ip mode, it’s normal for client DNS queries to return mapped addresses. A common default range is 198.18.0.1/16. That address alone doesn’t mean DNS has been poisoned. What matters is whether the same core continues to handle the connection and retains the domain mapping.

If the system receives a fake IP but TUN or the related routes are disabled, apps may not be able to reach that address. Restore a consistent traffic-routing setup before clearing caches. After changing DNS, run ipconfig /flushdns on Windows. On macOS, run the two commands below, then close existing connections and test again:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Layer 3: Check rule matches and the selected proxy group

Even when traffic reaches the core and the domain resolves, a rule may send it to the wrong outbound. Clash-style rules are checked in order, so the first matching rule takes precedence. A trailing MATCH is the fallback when no earlier rule matches. The proxy group’s name alone doesn’t tell you which node handled the request.

Make sure the client is in Rule mode, not Direct mode. Global mode typically uses the global proxy selection and can help as a short-term comparison, but it shouldn’t be treated as a definitive diagnosis.
Find the failing domain in the connection details and note the matching rule type, rule, and proxy chain.
Check whether the rule targets DIRECT, REJECT, or a proxy group. Expand the group and confirm which actual node is selected.
Close existing connections to the website, then refresh the page. Established connections usually don’t move to a new outbound immediately after you switch proxy policies.

This is a minimal example of rule order, not a complete, ready-to-run configuration. It rejects one specified host and sends all other requests direct. Use a real domain and an existing proxy group in your own configuration, and follow your routing requirements.

rules:
  - DOMAIN,blocked.example.com,REJECT
  - MATCH,DIRECT

If you put MATCH,DIRECT on the first line, later domain rules won’t process those requests. Check rule-set order and load status too. A successful subscription update only means the configuration was fetched; it doesn’t confirm that every remote rule set downloaded successfully.

Narrow down the issue with a brief Global mode test

Temporarily switch to Global mode, select a specific node, and visit the same website. If Rule mode fails but Global mode works, compare the matching rules in the connection details. If both fail, check the outbound connection. Restore the original mode after testing so a local issue doesn’t affect other apps. Global mode may also change the DNS path, so confirm the results in the logs.

Layer 4: Verify the outbound node and target website

A node latency test usually targets a single test URL in the configuration. Success doesn’t mean every website, port, or UDP connection will work. A browser page may also request resources from several domains, including the main site, login services, and image hosts. A single failed resource can leave a page blank or loading indefinitely.

Compare two nodes: Keep the failing domain, proxy entry point, and operating mode the same; change only the final node. Close existing connections to that domain before trying again.
Check your subscription status: Verify the expiry date, data allowance, and node status shown by your provider. After updating the subscription, make sure the active configuration has actually switched to the new content.
Check the system clock: An incorrect time can break TLS certificate validation and time-based authentication. Enable automatic time synchronization, then check whether the error goes away.
Check protocol compatibility: If you see errors about an unsupported proxy type, encryption method, or configuration field, check that the current core supports it. Importing a subscription successfully doesn’t mean the core started every node successfully.

In the logs, connection refused usually means a destination actively refused the connection or nothing is listening on the port. i/o timeout only indicates that an operation timed out; it doesn’t identify whether DNS, the route, or the remote server is at fault. For x509 errors, check the certificate domain and validity period along with the system clock. Don’t hide the problem by disabling TLS certificate verification.

If only one website returns a 403, a regional restriction, or a CAPTCHA while other sites work, the request has reached the HTTP response stage. Check the site’s policies and the conditions of your outbound route. Repeatedly changing the local mixed port is unlikely to help.

Additional checks for TUN mode and browser-specific issues

System proxy works, but TUN fails

TUN routes traffic through a virtual network interface, involving permissions, routes, and DNS. If an explicit proxy test works but the connection drops only when TUN is enabled, check these components before reimporting your subscription. Look in the logs for interface creation failures, insufficient permissions, route errors, or DNS request timeouts.

In mihomo, tun.auto-route, tun.auto-detect-interface, and tun.dns-hijack control automatic routing, outbound interface detection, and DNS hijacking, respectively. Their behavior depends on the platform and client implementation. After switching Wi-Fi, unplugging Ethernet, or connecting to another VPN, the previous outbound interface and routes may no longer apply. Save the logs, restart TUN, then compare the same request.

Command-line requests work, but the browser won’t load websites

Temporarily disable browser proxy extensions. In Firefox, go to Settings → General → Network Settings and check whether a separate proxy is configured.
Check browser Secure DNS. You can turn it off briefly for comparison, then restore the original setting. Don’t change core DNS at the same time.
Open the developer tools’ Network panel and check whether the failed request is for the main document, a script, an image, or a login API.
If the logs point to UDP or QUIC, compare with a regular HTTPS request from the command line. A successful HTTP request doesn’t prove that the node supports UDP.

On Android, also check whether the client uses per-app proxy settings and whether the browser is on the exclusion list. Android Private DNS may also send lookups along a different path than expected. The VPN icon only confirms that an interface exists; use actual requests and client logs to diagnose the connection.

Restore your settings and keep a reproducible troubleshooting record

After troubleshooting, restore any temporary changes to Global mode, browser settings, and log levels. If you need to report the issue to a client maintainer or service provider, reproducible steps are more useful than a screenshot saying “connected but no internet.”

Record the operating system, client, and core versions, and note whether System Proxy and TUN are enabled.
Describe the scope: all websites, one website, one browser, or TUN mode only.
Include the explicit HTTP proxy test, DNS comparison, matched rule, and final outbound node type.
Capture the relevant logs from around the same request. Before sharing, redact subscription URLs, credentials, control interface secrets, and personal browsing history.

To check configuration fields, see the Advanced Config guide. For common installation and usage questions, visit the Help Center.