Clash connected but websites won’t load: System Proxy, Port Conflicts, and Rules Troubleshooting Checklist

First, distinguish “the client is running” from “requests are going through the proxy”

Open the client’s Connections and Logs pages, then reload the website that won’t load. A “Running” status, an active system tray icon, or a latency reading for a node only confirms that some components are working. It doesn’t prove that your browser’s request went through the proxy—or that the site is reachable.

Clash is a commonly used name for a family of proxy cores and clients. Clash Meta continued development under the name mihomo. The controls vary between graphical clients. This guide refers to Windows 11 system settings, common client features such as System Proxy, Proxy Mode, Connections, and Logs, and mihomo configuration fields. Port examples use 7890; always check your active configuration before making changes.

1. Record the current setup: Note the client name, core version, active profile, selected node, mixed port, and whether TUN is enabled.
2. Rule out a basic connection problem: Turn off the system proxy and TUN, then visit a site that normally works without a proxy. If it still fails, check your Wi-Fi, gateway, broadband authentication, or campus network sign-in.
3. Keep testing focused: Run only one client, test the same URL each time, and change one setting at a time.
4. Check for requests: If no connection appears after a reload, check how traffic enters the client. If a request is logged but fails, check the outbound node, rules, and DNS.

Check the system proxy: Is your browser reaching the local port?

Check the address, port, and proxy exclusions

In Windows 11, go to Settings → Network & internet → Proxy → Manual proxy setup → Edit. The server address for a standard browser HTTP proxy should match the address the client listens on. If it listens on localhost only, enter 127.0.0.1. Use the actual HTTP or mixed port, such as 7890. Don’t enter the controller API port in the proxy settings.

On macOS, go to System Settings → Network → your current network service → Details → Proxies. Check both the web proxy and secure web proxy. Names may vary slightly by macOS version. If you use automatic proxy configuration, make sure the PAC URL is reachable and its rules don’t send the target domain direct. Check the proxy bypass list to ensure the domain hasn’t been excluded by mistake.

• After restarting the client, check the system settings again. When an old process exits, it may restore a different set of proxy values.
• In Firefox, go to Settings → General → Network Settings → Settings and select “Use system proxy settings,” or enter a proxy manually.
• Temporarily disable browser proxy extensions to make sure they aren’t overriding the system proxy. Browser settings may also be controlled by your organization.
• The system proxy doesn’t handle every app. Terminal tools, games, and some store apps may need their own proxy settings, or TUN after you’ve confirmed the regular proxy works.

Test with an explicit proxy request to bypass browser settings

In Windows PowerShell, use curl.exe to avoid the legacy PowerShell curl alias. This command sends a request through the local HTTP proxy and times out after 15 seconds. example.com is just a connectivity test; replace it with the site that’s actually failing and run the test again.

curl.exe -v --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:7890 https://example.com/ -o NUL

On macOS and Linux, run the equivalent command:

curl -v --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:7890 https://example.com/ -o /dev/null

If the command gets an HTTP response but the browser still fails, check browser extensions, custom proxy settings, and cached connections. If you get a connection refused error for 127.0.0.1:7890, check the local listener first—don’t immediately replace your subscription. Treat a 403 separately from a network timeout: an HTTP service responded, but the site or an intermediary may have denied access.

Check port conflicts: Make sure the current core owns the listener

mixed-port provides a combined HTTP and SOCKS proxy endpoint; external-controller is for the control API. They serve different purposes. Don’t enter 9090 from the sample configuration in your browser’s proxy settings. Use this snippet only to check field names, not as a replacement for your full subscription:

mixed-port: 7890
allow-lan: false
mode: rule
external-controller: 127.0.0.1:9090

In Windows PowerShell, check which process is listening:

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

Enter the OwningProcess number from the output in Get-Process -Id to see the process name. On macOS, use the first command; on Linux, use the second. Some process details may require additional permissions.

lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -ltnp 'sport = :7890'

Don’t force-close an unfamiliar process just because it’s using a particular port. Check its name and source first. If you change the mixed port to 7891, update the system proxy, browser-specific proxy settings, and terminal environment variables too. Otherwise, requests will still go to the old port.

Check the proxy node: A latency reading doesn’t mean the site is reachable

Open the Proxies page and find the policy group actually used for outbound traffic. A group may point to another group, or it may select DIRECT. A highlighted node in the interface doesn’t prove that the current connection is using it. Open the connection details and check the requested domain, policy chain, and final outbound node.

1. Select a different node in the same policy group, close the existing connection, and reload the site.
2. Temporarily switch to Global mode, explicitly select a proxy node in the global policy group, and repeat the same request.
3. If Global mode works but Rule mode doesn’t, check which rule matches. If both fail, focus on the node and your local network.
4. Check your provider’s account page to see whether your subscription has expired, your data allowance is used up, or a node is undergoing maintenance.

Global mode changes routing after traffic reaches the core; it doesn’t automatically route every app through the core. Switch back to Rule mode after testing. Node latency is usually measured against a test URL set in the client. It only confirms that test request worked at that moment—a reading of 150 ms doesn’t mean video, sign-in, or a specific site will work.

Check for a misrouted request: Find the first matching rule

Rule mode evaluates rules in order, and the first match determines how a connection is routed. Common causes include a domain matching a direct rule, a broad rule appearing too early, or a rule pointing to a policy group that ultimately selects an unavailable node. Don’t just look at the final MATCH rule; check the rule recorded in the connection details for that request.

This example shows how rule order works. DIRECT and REJECT are built-in policies. This snippet isn’t a complete configuration and shouldn’t be added directly to an active subscription:

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

In this snippet, example.com and its subdomains match the direct rule first. Any other request that doesn’t match is rejected. If you reverse the two lines, the first MATCH rule catches every request, so the domain rule never runs. This is a common reason a rule appears to have no effect.

• Matched DIRECT but the request failed: Check whether the domain should be accessed directly. If it needs a proxy, move a more specific domain rule above the relevant broad rule.
• Matched REJECT: Check ad-blocking and custom block rules for false positives affecting sign-in, CAPTCHA, or static asset domains.
• Matched a proxy group but still failed: Check which node the group ultimately selected; don’t rely on the group name alone.
• The problem returned after a configuration update: Use the client’s override or merge feature to save custom rules, rather than editing content that a subscription refresh will overwrite.

After changing rules, close the affected connection and test again. The browser may reuse an existing HTTP/2 connection, so a simple refresh might not trigger a new routing decision. A page may also request resources from several domains. If the main page loads but images or sign-in fail, check the connection logs for the failed resources.

Check DNS and TUN: Separate name resolution problems from traffic-capture issues

Identify DNS errors first

If you see Could not resolve host, no such host, or a DNS timeout in the logs, first find out which component is resolving the domain. Browser Secure DNS, system DNS, and mihomo’s DNS module may use different paths. On Windows, nslookup example.com tests the response from the system-selected DNS server by default; it doesn’t confirm that mihomo’s internal resolution works. Check the logs for the actual request.

With fake-IP enabled, an address in the 198.18.0.0/15 range isn’t necessarily a problem. The core may assign it as a mapped address for a domain; the proxy needs to capture the traffic to restore the domain name. If you turn off TUN while the browser still has one of these addresses cached, requests may continue to fail. Restore a consistent DNS and traffic path before restarting the browser. On Windows, run ipconfig /flushdns if you need to clear the system DNS cache.

Don’t replace every nameserver and fallback value with random public DNS addresses. First make sure the upstream DNS server is reachable on your current network using its configured address and transport. If the upstream server is specified by a domain name, also consider how that name is resolved at startup. You can temporarily disable browser Secure DNS for comparison, then restore it once you’ve identified the issue.

Test TUN separately, after the regular proxy works

TUN captures traffic through a virtual network interface and involves more moving parts than the system proxy. If an explicit proxy command succeeds but enabling TUN breaks access across the network, check the client service permissions, virtual interface, routing, and DNS interception. Don’t keep switching nodes at random.

1. Turn off other VPNs, virtual networking tools, and proxy clients. Leave only the current client running to rule out routing conflicts.
2. Make sure the service mode or permissions required by the client are enabled, then check the TUN startup logs for errors.
3. Turn off TUN and test the system proxy on its own. Then enable TUN and configure the system proxy as recommended by the client to avoid duplicate routing paths.
4. Use route print (Windows) or ip route (Linux) to compare routes before and after switching. Handle any internal routes required by your organization separately.

mihomo’s TUN configuration can use dns-hijack to capture matching DNS requests, but hijacking port 53 doesn’t capture every form of encrypted DNS. Browser DoH uses HTTPS traffic and must be handled through the relevant rules and DNS setup.

Use the error to narrow it down: Record a minimal, reproducible case

For certificate errors, first sync your system date and time. Check whether the network requires sign-in and whether your organization performs HTTPS inspection. Don’t treat disabling certificate verification as a routine fix. For 403 or 429 responses, don’t keep refreshing: the proxy connection may already be working, while the site is rejecting the request based on its access policy or rate limits.

If you need help, include the client and core versions, OS version, time of the issue, target domain, system proxy and TUN status, explicit proxy test results, and error logs from around the same time. “The browser won’t load the site” is less useful than “The local port accepts connections, the request matches a policy group, but the final node times out on outbound.”