Troubleshooting Clash node timeouts and connection failures: network, DNS, and server checks

First, distinguish a failed speed test from a failed connection

When a Clash client reports a “timeout,” it usually means a request to a specific test endpoint did not finish in time. That does not necessarily mean the node server is offline, nor does it prove the subscription is invalid. The test endpoint, DNS, node handshake, or destination server response can each cause a speed test to time out.

Work through the checks in this order: local network → system time → core and ports → traffic path → DNS → protocol settings → server. The steps apply to classic Clash configurations and clients running the Clash Meta (now mihomo) core. Supported fields depend on the core version actually in use.

Step 1: Check your local network and system time

Establish a direct-connection baseline

1. Note your current settings, then turn off the client’s system proxy and TUN. On mobile, also make sure the VPN connection is disconnected; closing the app screen may not stop the tunnel.
2. Open a website you can normally access directly. On hotel, campus, or public Wi-Fi, complete any captive portal sign-in first; a Wi-Fi icon alone does not confirm internet access.
3. Repeat the test using a mobile hotspot. Keep the same device, configuration, and node; change only the network.

If direct access also fails with the proxy off, troubleshoot the local network first. If your home broadband fails but the hotspot works, the access network’s DNS, routing, or UDP policies are more likely involved. Check the logs before drawing conclusions; this alone does not prove the server has blocked you. OS network diagnostics may rely on specific probe endpoints, so treat an “No internet” warning as one clue, not definitive evidence.

Correct the system time before troubleshooting certificate errors

TLS certificate validation depends on the system clock. In Windows 11, go to Settings → Time & language → Date & time, enable automatic time, and sync. On macOS, go to System Settings → General → Date & Time. Check the actual date, year, and minutes as well as the time zone.

If the logs show certificate has expired or is not yet valid, check your device’s clock and the server certificate’s validity period first. Don’t treat disabling certificate verification as a general fix: it weakens server authentication and won’t resolve incorrect credentials, an unreachable port, or a protocol mismatch.

Step 2: Check that the core is running and local ports are available

A working graphical interface doesn’t mean the proxy core loaded its configuration successfully. In the client logs, look for config parsing errors, repeated core exits, or address already in use. If the config didn’t load, the node list may still show cached entries even though the local proxy port is not listening.

Know the difference between proxy ports and the controller port

• port: HTTP proxy port.
• socks-port: SOCKS proxy port.
• mixed-port: Port that accepts both HTTP and SOCKS proxy requests.
• external-controller: The address the control API listens on. Don’t enter it in your browser’s proxy settings.

If the active configuration uses mixed-port: 7890, run the commands below to check which process is listening. Use PowerShell on Windows and Terminal on macOS. If there’s no output, check the core logs rather than trying more nodes.

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

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

On Windows, you can also run Get-Process -Id PROCESS_ID to identify the process. Replace “PROCESS_ID” with the actual number from the previous step. If an older client is using the port, quit that instance or change the port, then update the system proxy to match. Don’t terminate unknown system processes or run two TUN traffic-capture clients at once.

Step 3: Confirm which rule and node handle the request

The system proxy affects only apps that honor that setting. Some command-line tools, games, and apps with their own network stacks ignore it. TUN captures traffic matching its routes through a virtual network interface, and its behavior also depends on routing, permissions, and exclusions. These are separate mechanisms: an enabled system proxy does not prove that all traffic reaches the core.

Set up a comparison with an explicit proxy request

Select the node you want to test in the client, then confirm the relevant policy group points to it. Run an explicit HTTP proxy request as a comparison. The commands below connect to local port 7890, with a 10-second connection timeout and a 15-second overall timeout. Use curl.exe on Windows and curl on macOS or Linux.

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 15 -I https://example.com/

The test endpoint provides a repeatable request, but it isn’t the only measure of node availability. An HTTP status means the request reached at least that stage; 403 may mean the destination site denied access, not that the proxy connection failed. If you can’t connect to 127.0.0.1:7890, check the local listener first. If the proxy tunnel was established before the failure, investigate the handshake, DNS, and remote response.

1. Open the client’s connections view and find the destination domain from your test.
2. Check the matched rule, policy group, and final node to make sure the request didn’t go through DIRECT.
3. If the request doesn’t appear in the connections view at all, check the app’s entry point and port first. Connection records may disappear quickly, so check the logs too.
4. If needed, briefly switch to Global mode and select the test node explicitly. Restore Rule mode after the comparison.

If an explicit proxy request works but an app fails, focus on the app’s proxy settings and TUN routing instead of repeatedly updating the subscription. If the issue starts only after enabling TUN, turn TUN off and repeat the explicit proxy test. Then check administrator permissions, other VPNs, virtual network adapters, and routing conflicts one at a time.

Step 4: Trace DNS failures through both resolution paths

A proxy connection may involve at least two kinds of domain: the node server’s domain and the destination domain the user is visiting. If the node domain fails to resolve, the tunnel can’t be established. If the destination domain fails, the node may complete its handshake while some websites remain unreachable. These domains may use different DNS resolution paths.

Node domain: resolve it before trying to establish the tunnel

Check whether the domain in the error log matches the node’s server. In mihomo, proxy-server-nameserver can specify DNS servers for resolving node domains. default-nameserver can provide the bootstrap resolution needed to look up the DNS servers’ own domains. Avoid relying entirely on a proxy connection that hasn’t been established yet to resolve the node domain; that can create a circular dependency.

On Windows, Resolve-DnsName; on macOS, dig can check the system’s DNS results. That only shows the resolution path used by the respective tool; it doesn’t prove mihomo’s built-in DNS returned the same result. Check the active DNS fields and core logs as well.

Destination domain: check Fake-IP, DNS interception, and app caches

• In fake-ip mode, the client may return a synthetic address in the 198.18.0.0/16 range. This is not the website’s real server address.
• The corresponding core must capture Fake-IP addresses and map them back to domain names. System or app DNS caches left over after switching clients may send requests down the wrong path.
• TUN DNS interception can capture DNS requests covered by its configuration, but an app’s built-in DoH may bypass regular port 53 traffic.
• Check nameserver-policy, nameserver, and fallback against the active configuration. Adding more DNS servers doesn’t guarantee faster or more reliable resolution.

After changing DNS mode, reload the configuration and restart affected apps. On Windows, run ipconfig /flushdns if needed to clear the system DNS cache; this won’t clear every browser’s internal cache. If disabling IPv6 is the only change that restores access, investigate AAAA lookups, IPv6 egress, and routing further. It doesn’t prove IPv6 should always be disabled.

Step 5: Check protocol settings and core compatibility

Once the local port is working, the request is confirmed to reach the intended node, and the node domain resolves, check the protocol settings field by field. A YAML parser accepting the configuration only confirms valid syntax. Unsupported fields in the current core, expired credentials, or changes to the server’s listening setup can still prevent a connection.

Connections based on UDP, such as Hysteria2 and TUIC, may fail on networks that restrict UDP even when TCP nodes work on the same network. A TCP port check cannot verify the full handshake for these protocols. Conversely, a successful regular HTTP latency test doesn’t mean a node supports the UDP forwarding needed for games or voice calls.

Record both the client version and the actual core version; they’re not the same. Classic Clash and mihomo support different protocols, and older cores may not recognize newer fields. If you see unsupported proxy type or a field parsing error, check the configuration format and core capabilities instead of increasing the speed-test timeout.

Step 6: Check the node, test endpoint, and server status

Cross-test while changing as little as possible

1. Same device, same network, different node: If only one node fails, check its settings, account quota, and server maintenance status first.
2. Same device, same node, different network: If the hotspot works but broadband doesn’t, investigate the access network path and protocol restrictions.
3. Same network, same node, different device: If another device works, check the affected device’s overrides, core, proxy entry point, and caches.
4. Same node, different destination: If only one test endpoint fails, check the destination’s policies and test URL. Don’t conclude the node is offline based on one site.

Use the speed-test timeout as a diagnostic variable. For example, temporarily increase it from 5 to 10 seconds to see whether the connection is simply slow to establish. This won’t fix bad credentials, an expired certificate, or a refused port. If the test only succeeds occasionally with a longer timeout, investigate packet loss, congestion, and handshake logs.

A successful subscription update only confirms that the configuration was fetched; it doesn’t mean every node is online. Check your provider account status, traffic quota, and maintenance notices. After updating, verify that the active configuration, node settings, and update time actually changed. Avoid running speed tests repeatedly at high frequency; a few requests with timestamps are more useful for troubleshooting.

Wrap up with logs: preserve the failure stage and hide credentials

Temporarily set the log level to debug, reproduce the issue once, and note the time. Then restore the normal log level. Debug logs may contain visited domains and connection details, so share only the relevant time window.

• connection refused: Usually means the connection was explicitly rejected. First determine whether the error points to the local proxy port or the remote node port.
• i/o timeout, context deadline exceeded: A stage exceeded its time limit. Use the surrounding log entries to identify whether the failure occurred during resolution, dialing, or the request.
• no such host: Identify the exact domain that failed to resolve and which DNS path it used.
• authentication failed: Check the credentials and account status first. Reinstalling the client usually won’t change the server’s authentication result.
• EOF, connection reset: The connection closed unexpectedly. This line alone isn’t enough to identify the cause; check the handshake stage and server logs.

After troubleshooting, restore Rule mode, the normal log level, and any temporary changes, then keep a reproducible record. If “speed test timed out” happens again, resume from the network, port, and DNS baselines you already verified instead of starting with a reinstall. See Quick Start for proxy setup and config import, or visit the Help Center for common settings questions.