Clash Node Timeout or Connection Failure? A Step-by-Step Troubleshooting Guide

1. First, tell a failed latency test from a failed connection

In Clash, Timeout means only that an operation did not finish within the allotted time. It does not necessarily mean the node is down. Latency tests usually send a request through the node to a test URL, measuring the entire request path—not just network latency to the server. An unreachable test site, a DNS lookup failure, or a TLS handshake problem can all cause a timeout.

This guide uses Clash Verge Rev with the mihomo core. Open the Proxies page and note the current mode, target policy group, and selected node. Then open Connections and Logs and keep the entries from when the problem occurred. Interface labels may vary slightly by version; use the actual port and configuration values in your setup.

• Only one node fails: Check that node’s address, port, protocol settings, and server status first.
• All nodes fail: Check your local proxy, subscription account, DNS, and current network first. Don’t change multiple nodes at once.
• Latency test fails, but websites load: Check the test URL and timeout threshold. Don’t delete a node based on its test color alone.
• Latency test passes, but websites won’t load: Check whether the app is routed through the core, which rule matches, and the actual policy chain in use.

2. Check the system proxy, listening port, and local connection

Make sure the app is passing requests to the core

In Settings, check the System Proxy status and configured proxy port. Then verify the address actually set in your operating system’s network settings. On Windows 11, go to Settings → Network & internet → Proxy → Manual proxy setup. A typical local proxy address is 127.0.0.1; the port must match the one the client is listening on.

Don’t assume the port is always 7890 or 7897. The example below uses the current configuration value mixed-port: 7897. mixed-port accepts both HTTP and SOCKS requests. In Windows PowerShell, run:

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

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

On macOS or Linux, use the following command to check the same endpoint. If your configured port is different, change the number in the command first.

lsof -nP -iTCP:7897 -sTCP:LISTEN
curl --noproxy "" --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com/

• Immediate error connecting to the local port: The core may not be running, or the port may be different. Fix the local listener first; there’s no need to troubleshoot remote nodes yet.
• Logs show address already in use: Another process is using the port. Check which process it is, close any duplicate proxy clients, or change the port in the client and sync the system proxy again.
• The command works, but the browser doesn’t: Check browser proxy extensions, separate proxy settings, and stale connections. Close old connections and try again.

This curl command only checks whether a request can reach the local proxy. It doesn’t confirm that the rules ultimately selected a remote node; the request could still match DIRECT. Check the Connections page as well. An HTTP response doesn’t guarantee the target service is usable, but it does show that the request reached the response stage.

Test TUN and the system proxy separately

The system proxy affects only apps that follow system settings. TUN uses a virtual network adapter and routes to capture traffic. If the problem occurs only with TUN enabled, note the original settings, then turn TUN off and establish a baseline using the system proxy and the explicit proxy command above. If the baseline works, check TUN service permissions, routes, and conflicts with other VPNs.

Back up your configuration before making changes. Don’t use permanently disabling the system firewall as a substitute for troubleshooting, and don’t remove a virtual network adapter unless you know what it does. On managed devices, check with your administrator before changing routes or security policies.

3. Check subscription updates, account status, and active configuration

Open the Profiles page and make sure you’re using the expected subscription, not an older local configuration. Update the subscription once and check the result. A successful download means only that the configuration file was retrieved—it doesn’t confirm that your account has data remaining, that every node is online, or that the new configuration is active.

1. Check your provider account for its expiration date, remaining data, and connection limits. If traffic usage isn’t shown, refer to your account dashboard.
2. Compare the node count and names before and after the update to see whether your provider changed any server endpoints or protocols.
3. Make sure the configuration is active, then check the selected policy group again on the Proxies page.
4. If the update fails, distinguish an HTTP error from a subscription request, a download timeout, and a configuration parsing error. Don’t lump them all together as node timeouts.

HTTP 401 or 403 errors may indicate invalid credentials, access restrictions, or an account issue; check your provider’s guidance. YAML parsing errors usually occur before the core loads the configuration. Fix the subscription content or compatibility issue instead of repeatedly running latency tests.

4. Check DNS: is the node hostname failing, or the destination hostname?

Proxy connections may involve at least two DNS lookups: one for the node server and another for the website you’re visiting. If the first fails, the core can’t resolve the remote server’s address. If the second fails, the node itself may be fine while a particular website remains unavailable. The specific hostname in the logs is more useful than a generic “DNS issue.”

Check system DNS first, then DNS in the core

On Windows, run Resolve-DnsName example.com. On macOS or Linux, run nslookup example.com to see whether system DNS returns a result. To check the actual node, use the hostname in the server field of your subscription. Don’t use a subscription URL containing credentials as the node hostname.

These commands check the system DNS path; they don’t directly verify DNS inside mihomo. If your configuration has dns.enable enabled, also check the configured nameserver, proxy-server-nameserver, and related policies. The latter specifies the upstream DNS servers used to resolve node hostnames. With DoH, also account for the initial lookup needed to resolve the DoH server’s hostname.

• Logs show lookup or no such host: Check the hostname spelling and whether the upstream DNS server is reachable. Determine whether the failure is in system DNS or core DNS.
• DNS returns an address, but the request still times out: Check the connection to that address and port. Not every timeout is a DNS issue.
• You see an address in 198.18.0.0/16: This can be a normal mapping in Fake-IP mode. Check whether the core is handling the request instead of treating the address alone as proof of a DNS error.

Don’t add a long list of public DNS servers all at once. Keep the original configuration, then check whether the upstream DNS server is reachable on your current network. If DNS requests must go through the proxy while starting a node depends on that same DNS path, you can create a circular dependency. For an introduction to DNS and traffic routing, see the protocol guide.

5. Find where the connection fails in the logs

Open the Logs page. Before reproducing the issue, clear the view or note the time, then send just one request. If standard logs aren’t enough, temporarily set the log level to debug. Switch back to info when you’re done to avoid generating excessive logs. Logs may contain visited hostnames and server addresses, so redact them before sharing.

A single error usually isn’t enough to identify the cause. For example, EOF can result from a protocol mismatch or a remote server closing the connection. Look for the earliest relevant error, not just the final “request failed” message. If all requests fail while the configuration is loading, fix the configuration first, then troubleshoot the network.

6. Check node protocol settings and the remote port

Once the local proxy, subscription, and DNS are working, check the node’s server, port, and protocol. A TCP port test can show whether a connection can be established, but it can’t verify authentication, encryption, or proxy forwarding. On Windows, use Test-NetConnection with the actual server and port to test TCP. The same result can’t be used to draw conclusions about UDP protocols.

• Shadowsocks: Check the cipher method, password, and plugin requirements. The method must match the server configuration.
• VMess / VLESS: Check the UUID, transport, and TLS settings. Fields such as VLESS flow must match the server configuration.
• TLS / WebSocket: Check SNI, Host, and the path. The server address, TLS name, and HTTP Host may differ; don’t blindly change them all to the same IP.
• REALITY: Check the public key, short-id, server-name, and other settings provided by your service provider. A server address alone isn’t enough.
• Hysteria2 / TUIC: These usually rely on UDP. If TCP nodes work on the same network but these nodes don’t, check whether the network restricts UDP or local security policies are blocking it.

If you see a certificate error, first sync your system date, time, and time zone. Then confirm that the server certificate and hostname match. Don’t treat skipping certificate verification as a permanent fix. If the configuration contains fields unsupported by the core, note the actual client and core versions, then check compatibility against your provider’s requirements. Don’t assume protocol support based only on the client version shown in the interface.

7. Finish by checking rule matches and cross-testing

Return to the Connections page, reopen the target website, and check the matching rule, policy group, and final node. In Rule mode, some requests matching DIRECT is expected. REJECT means a rule blocked the request; it isn’t a node timeout. Policy groups may also contain nested auto-select groups, so choosing a group at the outer level doesn’t necessarily select a specific node.

Keep comparisons focused to avoid unnecessary changes

1. Keep the node and destination the same. Compare system proxy requests with explicit proxy requests to check whether the app is being routed through the proxy.
2. On a network you’re authorized to use, compare your current connection with a mobile hotspot. If the issue occurs on only one network, check that network’s DNS, port, or UDP restrictions first.
3. Keep the network unchanged and switch to another known-good node. If only one node fails, send your provider the node details and the time of the issue.
4. If you temporarily switch to Global mode to rule out routing rules, restore the original mode afterward and check the connection path again.

When contacting support, include your operating system, client and core versions, the time and time zone of the failure, node protocol, whether TUN is enabled, redacted logs, and results from two comparison tests. A screenshot showing only red latency results isn’t enough: it doesn’t show which stage of the request failed.