Clash Connected but Websites Won’t Load: Troubleshooting Ports, Rules, and DNS

First, tell apart a running core, a successful node test, and working web access

When a Clash client says “Connected” or shows that the service is running, it only confirms that one part of the setup has started. Browser requests still depend on the app’s proxy settings, the local listening port, rule selection, the node connection, and the destination website. A latency reading from a node test only shows that the test address was reachable at that moment; it doesn’t prove that every website or protocol will work.

This guide covers common combinations of desktop clients and the mihomo core. Setting names vary by client, so use the listening port shown in the interface and the active configuration as your reference. First, note the client name and version, core version, active configuration name, and when the issue occurred. Don’t start by reinstalling the client, changing subscriptions, and editing DNS all at once.

Track three things you can reproduce

• Scope: Do all websites fail, or just one domain? Is the issue limited to the browser, or do terminal commands and other apps fail too?
• Request path: Are you using the system proxy, a browser proxy extension, or TUN mode? Is another VPN running?
• Evidence: Reload the page, then look for the domain in the client’s “Connections” list and check “Logs” for errors at the same time.

Step 1: Make sure your browser is using the system proxy

Using a common Clash Verge Rev interface as an example, check the toggle under “Settings” → “System Proxy,” then verify the actual proxy address in your operating system. Selecting a node in the client doesn’t automatically route all apps through it. The system proxy also can’t control apps that ignore system proxy settings.

1. Check the client for its actual “Mixed Port.” For example, if the interface shows 7897, the local proxy address should be 127.0.0.1:7897. Other clients may use 7890, so don’t assume the default.
2. In Windows 11, open “Settings” → “Network & internet” → “Proxy” and check the address and port under “Use a proxy server.” Note that an automatic configuration script may also affect the route.
3. On macOS, open “System Settings” → “Network” → your active connection → “Details” → “Proxies.” Check that the web proxy and secure web proxy point to the expected address.
4. In Firefox, open “Settings” → “General” → “Network Settings” → “Settings.” Confirm that Firefox uses the system proxy, or check the manual proxy settings. Proxy extensions in other browsers may override system settings too.

For troubleshooting, temporarily disable browser proxy extensions and use just one clearly defined proxy entry point. Don’t enter an HTTP mixed port as a SOCKS-only port, and don’t use the controller port as a traffic entry point: external-controller is for the management API, not web proxy requests.

Test the proxy directly, bypassing browser settings

Assuming the current mixed port is 7897, run the command below in Windows PowerShell. It uses curl.exe to avoid parameter parsing issues caused by an alias with the same name in some PowerShell environments. On macOS and Linux, replace the command with curl.

curl.exe --noproxy "" --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com/

Next, replace the test URL with the website that won’t load. If the request succeeds through the explicit proxy but fails in the browser, first check browser extensions, system proxy settings, cached connections, and the browser’s Secure DNS settings. There’s no need to switch nodes right away. A 403 or 405 means the server returned an HTTP response, but the site may restrict access or HEAD requests. Remove -I and compare; don’t treat that response alone as proof that the proxy is disconnected.

Step 2: Check the mixed port listener and look for port conflicts

If the explicit proxy request immediately fails to connect to 127.0.0.1, check the local listener first. The request hasn’t reached the node yet, so switching remote servers usually won’t help. On Windows, run this command in PowerShell:

Get-NetTCPConnection -State Listen -LocalPort 7897 |
  Select-Object LocalAddress, LocalPort, OwningProcess

Use the process ID from the results in Get-Process -Id 1234 to check whether the port belongs to the core you’re using. Here, 1234 is just an example—replace it with the ID from your results. On macOS, run this command to find the listening process:

lsof -nP -iTCP:7897 -sTCP:LISTEN

If you need to change the port, choose one that isn’t in use—for example, change 7897 to 17897—then reload the core settings. Also update the system proxy, browser extensions, and the terminal’s HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY settings. If you change the client but leave an old entry point in place, requests will keep going to the wrong port.

Step 3: Compare Rule mode with Global mode

Once the local entry point works, check the mode selected on the client’s “Proxies” page. Rule mode uses rules to choose a policy. Global mode uses the selected global policy. Direct mode sends traffic without a proxy node. These control how traffic is routed; they’re separate from the system proxy and TUN mode settings.

1. In Rule mode, visit the affected website and note the rule, policy group, final node, and any errors in the connection details.
2. Briefly switch to Global mode and explicitly select a working node in the global policy. The comparison won’t mean much if the global policy is still set to DIRECT or REJECT.
3. Visit the same website again. If it works in Global mode but not Rule mode, focus on the rules and the policy groups they point to.
4. When you’re done testing, switch back to Rule mode so you don’t leave a temporary diagnostic setting in place.

If both modes fail, check the logs for node connection timeouts, authentication failures, TLS handshake failures, or certificate errors. You can test another node for comparison, but keep the URL and entry point the same. A successful latency test followed by a failed website request may point to egress restrictions, restrictions on the destination site, or node protocol settings. Latency alone can’t rule out a node issue.

Step 4: Check rule order, policy groups, and the final egress

mihomo rules are generally evaluated from top to bottom, and the first matching rule determines the policy. An earlier rule may send a domain to a direct or reject policy, preventing a later, correct rule from taking effect. Use the actual match shown in the “Connections” details as your reference—don’t just search the configuration to see whether the domain appears.

Check the connection details before editing the configuration

• Matched DIRECT: Check whether a direct connection is expected and whether a broad domain-suffix or IP rule matched first.
• Matched REJECT: Check blocking rules and remote rule sets. Make sure they’re not also blocking domains the website needs to load.
• Matched a proxy group: Expand the group and check its selection. A group called “Proxy” doesn’t guarantee that traffic goes to a remote node; it may be set to direct or to another group.
• Matched MATCH: Check the fallback policy. This usually means none of the earlier rules covered the request.

The example below shows rule order only; it isn’t a complete configuration you can use instead of your subscription. PROXY must match the name of a node or policy group in your existing configuration:

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,LAN,DIRECT
  - MATCH,PROXY

Real websites often request separate domains for sign-in, static assets, and APIs. The homepage HTML may load successfully while the page keeps spinning because an API domain matched a different rule. Open the browser’s Developer Tools and check the “Network” panel for failed request domains, then look for those domains in the client’s connections list.

Subscription updates may overwrite changes made directly to subscription content. For rule changes you need to keep, use the client’s override, merge, or extended configuration features, and confirm that the changes appear in the active configuration. Don’t replace all the existing nodes and policy groups in your subscription with an example from the web.

Step 5: Check system DNS and mihomo DNS separately

DNS issues often show up as domain lookup timeouts, failed resolution, or results that can’t be used to connect. First, identify which resolver is handling the request: the system resolver, the browser’s Secure DNS, the core’s DNS, or the remote proxy server. They may use different paths, so a single nslookup test doesn’t prove that the entire proxy route is working.

Compare DNS results by request path

1. Run nslookup example.com and note the DNS server used by the system and the result. Then repeat the test with the domain that’s actually failing.
2. Search the client logs for the target domain. Check whether the core’s DNS lookup failed or whether resolution succeeded and the node connection failed afterward.
3. If only the browser is affected, note your current settings and temporarily change the browser’s “Secure DNS” setting for comparison. Restore the original setting afterward, unless you’ve confirmed the new one works.
4. If your configuration uses encrypted DNS, check that the DNS server itself is reachable. Switching to a resolver the current network can’t reach will only add another timeout.

When testing SOCKS, it’s also worth distinguishing socks5:// from socks5h://: in curl, the latter lets the proxy resolve the target domain. If the current port supports SOCKS, run this comparison request:

curl.exe --noproxy "" --proxy socks5h://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com/

If remote resolution works but local resolution fails, focus on the local DNS path. Still, use the connection logs to interpret the results; a single request isn’t enough to establish the cause.

After correcting the relevant settings in Windows, you can run ipconfig /flushdns to clear the system DNS cache, then close and reopen the browser. Clearing the cache is a final cleanup step, not a substitute for fixing an incorrect DNS upstream, route, or hijack configuration.

Step 6: Test TUN, routing, and other VPNs separately

If the explicit HTTP proxy works but traffic fails with TUN enabled, the issue is more likely to involve the virtual adapter, routing, or DNS interception. TUN routes traffic through a virtual network interface, so apps don’t need to follow the system HTTP proxy. However, insufficient service permissions, route conflicts, or another VPN changing network settings at the same time can send traffic down the wrong path.

• In the client’s “Settings,” check that the service mode or related service is running, then check the “TUN Mode” toggle. If the client requires service permissions, follow its on-screen instructions to install the service.
• If your network policy allows it, temporarily turn off TUN, leave the system proxy enabled, and test the same URL in the same browser.
• If only TUN fails, check settings such as tun.auto-route and tun.dns-hijack in the active configuration. Also check for route conflicts with other VPNs or virtual network adapters.
• If only some HTTPS pages hang, use the logs and packet captures to investigate issues such as MTU or IPv6 routing. Don’t treat an arbitrary MTU value as a universal fix.

Company devices and managed networks may require specific VPN, certificate, and DNS policies. Contact your administrator to confirm compatibility; don’t bypass network management by disabling security components. On a personal device, stop duplicate proxy apps before considering removal of leftover services.

Record your findings and check your settings before restoring normal use

Use the results below to quickly identify which layer to investigate next. Recording the specific error is more useful than just writing “can’t connect,” and makes it easier to check whether the issue returns after a restart or subscription update.

When reporting an issue, include the client and core versions, operating system version, actual mixed port, proxy mode, TUN status, reproduction steps, and error logs from the same time period. Before sharing screenshots or configuration files, remove subscription URLs, authentication details, controller API keys, and personal browsing history.

Before returning to normal use, switch back from temporary Global mode to your intended mode, check that the browser and terminal aren’t using an old port, then retest the affected website and its sign-in, image, and API requests. For the basics, see the Clash Setup Guide. To continue troubleshooting by error type, visit the Troubleshooting page.