Clash Connected but Websites Won’t Load? A Step-by-Step Troubleshooting Checklist

A client showing “Connected” and a latency number beside a node only proves that the Clash core is running or that a single test request received a response. Whether your browser can load websites also depends on traffic reaching the listening port, rules selecting the right exit, DNS returning usable results, and the selected node completing a real TLS connection. Avoid flipping several switches at once; verify each layer from the traffic entry point outward.

Step 1: Separate a Network Outage from a Proxy-Path Failure

Fully quit Clash instead of merely closing its window. Confirm that the system proxy is disabled, then visit a local network resource and a regular website. If direct access fails too, the problem is usually with Wi-Fi, Ethernet, the router, a captive portal, or the ISP connection—not Clash configuration.

Run three basic tests

1. Open your router’s management address, such as 192.168.1.1. If it loads, the path from your device to the local gateway is working.
2. Run ping 1.1.1.1 in a terminal. Some networks drop ICMP packets, so a timeout alone does not prove that the network is down; continuous replies do confirm that the basic IP path is available.
3. Run nslookup example.com. If the IP path works but name resolution times out, troubleshoot the system DNS or router DNS first.

Hotels, airports, and campus networks often require browser-based authentication. After joining one, temporarily disable the proxy and visit a regular HTTP page to trigger the captive portal. Complete authentication before starting Clash. Until authentication is complete, a node may still occasionally show a latency value while subsequent HTTPS requests are intercepted by the gateway.

Step 2: Confirm That the System Proxy Points to Clash

The “system proxy” sends browsers and apps that follow the operating system’s proxy settings into Clash. If the core is running but the system proxy is disabled, browser connections usually will not appear in the logs and websites will continue using a direct connection. In Clash Verge Rev 2.x, check Settings → System Settings → System Proxy; in Clash for Windows 0.20.39, check System Proxy on the main screen. Labels vary slightly between clients, but the final settings should use the local loopback address and the port actually being listened on.

Verify the listening address and port

A common configuration uses mixed-port: 7890, which accepts both HTTP and SOCKS5 requests. Other configurations use port: 7890 and socks-port: 7891 separately. These are only typical values; always use the port shown in the current configuration and the client’s settings.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

On macOS 15, go to System Settings → Network → the active network interface → Details → Proxies to inspect the web proxy and secure web proxy. The server is usually 127.0.0.1, and the port should match Clash’s HTTP or mixed port. On Windows 11, check Settings → Network & internet → Proxy for the manual proxy. If it still points to a port used by another client that has already exited, browser requests will fail immediately.

Test the local proxy without the browser

Assuming the mixed port is 7890, run this in a macOS or Linux terminal:

curl -I -x http://127.0.0.1:7890 https://cp.cloudflare.com/generate_204
curl -I --socks5-hostname 127.0.0.1:7890 https://example.com

In Windows PowerShell, explicitly call curl.exe to avoid differences caused by command aliases:

curl.exe -I -x http://127.0.0.1:7890 https://cp.cloudflare.com/generate_204

If the connection to 127.0.0.1 is refused immediately, the port is not listening, the port is incorrect, or the core has stopped. If the request appears in the logs and then times out, the local entry point is working; continue by checking the node, DNS, and rules.

Step 3: Rule Out Port Conflicts and Core Startup Failures

When multiple proxy clients run at the same time, the most common conflict is that they all try to listen on 7890. The UI may still appear normal, while core logs show address already in use, bind failed, or another listener error. Even if the system proxy points to 127.0.0.1:7890, that port may belong to a different process.

Find which process owns the port

On macOS and Linux, run:

lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN

On Windows, run this in PowerShell:

Get-NetTCPConnection -State Listen -LocalPort 7890
Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 7890).OwningProcess

7890 is typically the proxy entry point, while 9090 is commonly used for the external control interface; they serve different purposes. Do not enter the control port as the system proxy port. After confirming a conflict, quit the old process or change the current configuration’s mixed port to something such as 7897, then update the system proxy accordingly. Changing only the YAML without updating the operating system proxy creates a new port mismatch.

Step 4: Verify That the Node Can Handle a Real Web Request

A latency test is not the same as full connectivity. The client may send one small HTTP request to a test URL, while loading a webpage involves DNS, TLS 1.3, HTTP/2, multiple domains, and sustained data transfer. A node showing 82 ms may still suffer from packet loss, congested egress, interrupted certificate handshakes, or restrictions imposed by the destination site.

Switch exit nodes methodically

1. Temporarily set the proxy mode to Global and select a specific node instead of an automatic policy group.
2. Visit https://cp.cloudflare.com/generate_204; a normal result is usually HTTP 204.
3. Then open websites operated by two different network providers to avoid misdiagnosing a single site outage or maintenance window.
4. Switch to a node in another region or on a different route and repeat the test. If only one node fails, treat it as a node-side problem first.

If every node times out during connection, check whether the subscription has expired, whether the node domain resolves, whether the device clock is accurate, and whether the current network restricts the protocol. A clock offset of only a few minutes can cause TLS certificate verification to fail. On macOS, enable automatic time in System Settings → General → Date & Time; on Windows 11, go to Settings → Time & language → Date & time and select Sync now.

In the logs, connection refused usually means the remote port rejected the connection; i/o timeout points more closely to a path timeout; TLS handshake timeout means the encrypted handshake after TCP did not finish in time. These messages indicate different failure layers and should not all be blamed on the client.

Step 5: Check Rule Matches and Proxy-Group Selection

In Rule mode, a request entering Clash may still be assigned to DIRECT, REJECT, or the wrong policy group. Typical signs include local websites working while specific sites outside mainland China fail, or the homepage loading while images, login APIs, and CAPTCHA resources do not. Websites often depend on multiple domains, so checking only the address-bar domain is not enough to verify the complete rule path.

Use connection records to identify the actual exit

Open the client’s Connections or Connections page, reload the target website, and inspect the matching rule, rule payload, and proxy chain for each domain. The mihomo core typically records the matched rule type and final path, for example:

example.com
Rule: DomainSuffix
Payload: example.com
Chains: Proxy Group → Singapore 01

If the target request matches MATCH → DIRECT, the preceding rules did not cover that domain. If it matches a proxy group whose selected node is unavailable, open the group and choose another node. If it matches REJECT, first determine whether it belongs to an ad-blocking or privacy rule set instead of deleting the entire rule group.

If switching temporarily to Global mode restores access, the problem is most likely in the rules or policy group. Fix it by adding a precise DOMAIN, DOMAIN-SUFFIX, or suitable rule set rather than leaving Global mode enabled permanently. For example:

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

Rules are matched from top to bottom, and the first match usually ends evaluation. Broad DOMAIN-SUFFIX or GEOIP rules placed incorrectly can intercept traffic before later, more specific rules. After editing, reload the Profile and confirm in the connection records that the new rule is actually being used.

Step 6: Diagnose DNS Interference, Fake-IP, and IPv6 Issues

If IP addresses are reachable but domain names will not load, or the browser remains on “Resolving host” for a long time, check DNS. Clash Meta, also known as mihomo, commonly supports the enhanced fake-ip and redir-host modes. Fake-IP returns a mapped address from a reserved range and lets the core restore the original domain; if application traffic bypasses Clash while using a Clash Fake-IP result, the request may never reach the real destination.

Compare system and proxy-side resolution

nslookup example.com
dig example.com
curl -v -x http://127.0.0.1:7890 https://example.com

If nslookup returns an address in the 198.18.0.0/16 range, it is usually a Fake-IP mapping rather than a real public address. Confirm that the system proxy or TUN is still working. Before quitting Clash, disable the system proxy and clear DNS settings managed by the client so the system does not continue sending queries to a local DNS port that is no longer listening.

A mihomo configuration can use a separate default resolver for upstream DNS hostnames and encrypted DNS to reduce interference with traditional UDP queries. The example fields are shown below; choose servers based on testing from your network:

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

If the issue occurs only on some IPv6-capable websites, temporarily disable IPv6 in the configuration for comparison. When a device has an IPv6 address but the IPv6 route is unstable, an app may try an unusable AAAA result first and fall back to IPv4 only after a timeout. Once confirmed, fix the router or upstream IPv6 path instead of treating every timeout as DNS interference.

Step 7: TUN Mode Is Enabled but the Internet Still Does Not Work

TUN mode creates a virtual network interface that covers apps which ignore system proxy settings and some UDP traffic. It relies on a system service, administrator privileges, routing tables, and DNS hijacking working together. An enabled switch in the UI does not prove that the virtual interface and routes were created successfully.

First determine whether the failure is specific to TUN

1. Disable TUN and enable only the system proxy.
2. Visit a test page in the browser and watch the connection records.
3. If the system proxy works but enabling TUN cuts off all internet access, focus on the service installation, virtual adapter, route conflicts, and firewall.
4. If both modes fail, return to the port, node, and DNS checks instead of repeatedly reinstalling the TUN service.

In clients such as Clash Verge Rev, check the service status under Settings → Service Mode or Settings → System Settings. If a client upgrade leaves the service version out of sync with the UI, stop the service first, then reinstall it through the client’s service-management entry. On Windows, also open Device Manager → Network adapters to verify the virtual adapter, and check whether another VPN, virtual machine network, or security tool is modifying routes at the same time.

On macOS, use route -n get default to inspect the default route and ifconfig to check whether the virtual interface exists. On Windows, run route print and Get-NetAdapter. If a virtual route remains after quitting the client, restart the relevant service or the operating system before testing again. Do not bulk-delete routes without knowing the destination networks.

Final step: Classify the failure from the logs instead of reinstalling immediately

Reinstalling the client only replaces program files; it cannot automatically fix unavailable nodes, incorrect subscription rules, stale system proxy settings, or upstream DNS problems. After completing the layered tests above, the failure should fall within a clearly defined area. Use the symptoms and directions below for a final check.

The most effective troubleshooting order is: confirm direct connectivity first, verify the local proxy port, then check nodes, rules, and DNS, and handle TUN last. At every step, watch both the terminal output and the client’s connection logs. Once you know where the request disappears, you can avoid aimlessly switching nodes, resetting configuration, or repeatedly reinstalling the client.