Troubleshooting Clash Node Timeouts

1. Tell a Failed Latency Test from a Real Connection Failure

When the Clash client reports a “timeout,” it usually means a probe did not complete within the allotted time. That alone doesn’t prove the node is down. Latency tests typically use a selected node to reach a test URL. A DNS lookup failure, an unreachable remote port, a failed protocol handshake, or an inaccessible test site can all produce similar results. Record the error and how widely it affects connections before changing settings. This helps distinguish an unreachable test URL from a failure affecting every node.

Use These Three Checks to Choose Where to Start

• Only one node fails: Keep the current configuration and try another node in the same group to reach the same site. If it works, check the affected node’s service status and settings first.
• All nodes fail: Check your local network, system clock, subscription status, and core logs first. Don’t immediately change ports across all nodes.
• The latency test fails, but websites load: Check whether the test URL is reachable and whether the website traffic actually uses the selected node. Browser cache or direct-connection rules can make it appear that the proxy is working when it isn’t.

In the client’s “Connections” or “Logs” view, check the destination domain, matched rule, and actual route for a new request. For example, if a website request matches DIRECT, that only confirms direct access is working—it doesn’t show that the selected proxy node is available. View names differ between clients, so follow the actual interface and the configuration used by the running core.

2. Check Your Network and System Clock with the Proxy Off

Quit any other proxy or VPN, then temporarily turn off the client’s system proxy and TUN mode. If your browser has its own proxy settings, reset it to use the system settings. Test a site you can normally access directly to confirm your basic connection works. On public Wi-Fi, complete the network sign-in first. If direct access fails, troubleshoot your Wi-Fi, router, or ISP connection before investigating Clash.

Work Through These Basic Checks

1. In Windows 11, check for a manually configured proxy under Settings → Network & internet → Proxy. With the client closed, there shouldn’t be a proxy setting pointing to an inactive local port.
2. Go to Settings → Time & language → Date & time, turn on automatic time, and select “Sync now.” Check the actual date and time, not just the displayed time zone.
3. On macOS, check automatic time under System Settings → General → Date & Time. Find network proxy settings under Network → your current network service → Details → Proxies.
4. Once your basic connection is working, start just one proxy client. Test with the system proxy first. When that works, re-enable TUN to avoid introducing virtual network adapters and routing changes at the same time.

TLS certificates are valid only within a defined time range, so an incorrect system clock can cause the handshake to fail immediately. Not all protocols use the same time-sync mechanisms, however. Syncing your clock is an essential first check, not a universal fix for every timeout.

3. Check That Your Subscription Is Active and Up to Date

Being able to download a subscription doesn’t mean your account still has data available or that every node is online. Check your service account for its expiration date, remaining quota, maintenance notices, and client restrictions. If the account has been deactivated, resolve its status first; changing DNS repeatedly won’t restore a deactivated service.

1. In the client’s “Subscriptions” or “Profiles” view, find the entry you’re using, update it, and check the timestamp and result.
2. Make sure the updated configuration is still selected and has loaded into the core. If the download succeeded but parsing failed, the client may still be running the old configuration.
3. Check which node the selected group is actually using. The current exit node in an auto-select or failover group may differ from the node you selected manually last time.
4. If the logs show an unknown proxy type, a missing field, or a reference to a nonexistent policy group, address configuration compatibility first. Don’t mistake it for a network timeout.

4. Check the Node Domain and Remote Port

Once you’ve confirmed the subscription is working, determine whether the domain fails to resolve or resolves successfully but its port can’t be reached. Check the node’s server and port; don’t confuse the remote node port with the local HTTP proxy listening port. In the commands below, example.com and 443 are examples only. Replace them with the actual server domain and port for your node. They do not represent a working node.

# Windows PowerShell: resolve the domain, then test the TCP port
Resolve-DnsName example.com
Test-NetConnection -ComputerName example.com -Port 443

# macOS: resolve the domain and test the TCP connection
nslookup example.com
nc -vz -G 5 example.com 443

If the domain lookup fails, first check that the node domain is spelled correctly and hasn’t expired, then check your network’s DNS service. If you use mihomo’s built-in DNS, also check which resolution path is used for the node server’s domain. The proxy-server-nameserver setting can specify DNS servers for resolving proxy node domains, but its suitability depends on your version and DNS configuration. Adding the setting alone doesn’t guarantee that the resolution path is correct.

TcpTestSucceeded: True only confirms that one TCP connection succeeded. It doesn’t verify authentication, TLS, or the proxy protocol handshake. For UDP-based protocols such as Hysteria2 and TUIC, a TCP port test can’t confirm availability. Standard ping uses ICMP; a server may ignore ICMP and still provide proxy service normally.

Compare the Connection Using a Mobile Hotspot

Keep the client, subscription, and node unchanged. Switch your computer from Wi-Fi to a mobile hotspot, then try a new connection. If the hotspot works but the original network continues to time out, the issue is more likely related to the original network path, UDP restrictions, routing, or outbound filtering—but that alone doesn’t prove a port is blocked. Compare logs from the same time period and check the server status before drawing conclusions. Follow your organization’s network policies on corporate or campus networks; don’t change managed security settings without permission.

5. Check Core Compatibility and Protocol Settings

Clash is a common name across the client ecosystem and core configurations, but that doesn’t mean every core supports the same protocols. Clash Meta later continued development under the name mihomo; older cores may not recognize newer protocols or fields. Note the client and core versions from the About page, core information, or startup logs, then compare them with your subscription provider’s requirements. Updating the client interface without changing the core that actually runs may leave compatibility issues unresolved.

Use the current configuration from your provider as the source of truth. Don’t change every port to 443 based on guesswork or switch transport types at random. The server name may differ from the node’s connection domain. Changing server to an IP address can also alter DNS resolution and affect certificate validation. If you get a certificate error, fix the clock, server name, or server certificate rather than routinely disabling certificate verification.

6. Check Traffic Routing When the Node Works but an App Doesn’t

If the built-in test succeeds but your browser or another app still times out, check whether its traffic reaches the client, which rule it matches, and whether it’s routed to the wrong policy group. System proxy and TUN are different ways to capture traffic. Enabling one doesn’t guarantee that every app will use the same exit as expected.

Check the Local Listener First, Then the Rules

If your current configuration explicitly sets mixed-port: 7890, use the command below to send one HTTPS request through the local HTTP proxy. 7890 is an example, not a standard port for every client. Confirm the listening port in your actual settings or configuration first.

# Use curl.exe in Windows PowerShell to avoid command alias differences
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://example.com/

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

• Connection to the local port is refused: Check that the core is running, the listening port matches, and no other program is using it. On Windows, use netstat -ano | findstr :7890 to check listening entries and their PIDs.
• The request reaches the client, but the remote handshake fails: Recheck the node address, protocol settings, and remote network. There’s no need to keep changing your browser’s proxy settings.
• The request matches REJECT: Check the rule order and source. Rules are evaluated in order, and the first match determines what happens. Fix the rule rather than simply switching nodes.
• It fails only with TUN enabled: Check service permissions, the virtual network adapter, DNS interception, and routing conflicts with other VPNs. Restore the verified system-proxy route first, then enable TUN features one at a time.

A successful HTTP response only proves that the individual request completed. Check the logs to confirm its actual route. Connection reuse may also keep an old node connection alive, so send a new request after switching nodes. If needed, close only the relevant old connections instead of clearing the entire configuration.

7. Gather a Minimal Reproduction Before Reporting the Issue

If these checks don’t identify the cause, a clear record of the issue is more useful than a screenshot that just says “timeout.” Change one thing at a time and record the result before and after. Don’t change the subscription, DNS, core, and network all at once, or you won’t know which change made a difference.

1. Record your setup: Operating system, client version, actual core version, and whether system proxy or TUN is enabled.
2. Record the scope: One node or all nodes; latency test only or real HTTPS requests too; and whether the problem affects a specific app.
3. Record the comparison: Results for the same node on the original network and mobile hotspot, the test time, and where the failure occurred. Don’t present example values as measured results.
4. Record the logs: Temporarily increase the log level, reproduce the issue once, and capture the relevant time period. Redact sensitive information before sharing, then restore your usual log level when you’re done troubleshooting.