Clash Nodes All Show timeout: A Step-by-Step Troubleshooting Guide

1. First, distinguish a failed latency test from an actual proxy failure

timeout means an operation did not finish within the allotted time. It does not prove that the server is down. A client’s latency check typically uses a node to access a specified HTTP or HTTPS URL. A stall at any step—resolving the hostname, connecting to the server, completing the protocol handshake, or reaching the test site—can result in a timeout.

Start with one node, one test URL, and one application. Pause batch testing to avoid launching dozens of simultaneous connections. Note the client and core names and versions, your current network, the test time, and the first error in the logs. Change only one variable in each subsequent test.

2. Local network: rule out connectivity, captive portals, and leftover proxy settings

Restore a known-good direct connection

1. Note your current settings. Turn off the client’s system proxy and TUN mode, then quit other VPNs, accelerators, or proxy tools.
2. In Windows 11, open Settings → Network & internet → Proxy and check for leftover manual proxy settings or setup scripts. If the device is managed by your organization, contact your administrator rather than removing its policies.
3. In macOS, open System Settings → Network → select your current connection → Details → Proxies. Check whether HTTP, HTTPS, or SOCKS proxy settings still point to a local app you’ve quit.
4. On hotel, campus, or public Wi-Fi, complete network authentication first. If your browser shows a sign-in page, take care of that before changing node settings.

Quitting the client does not always clear the system proxy. If the system still points to 127.0.0.1:7890 and no process is listening on that port, your browser will fail to connect. This is a local entry-point issue; traffic has not reached the remote node.

Test with an explicit direct request

In Windows PowerShell, use curl.exe to avoid differences caused by the command alias in older PowerShell versions. The request below bypasses explicit proxies, with a 5-second connection timeout and a 15-second total limit. These are troubleshooting settings, not measured results.

curl.exe --noproxy "*" --connect-timeout 5 --max-time 15 -I https://www.example.com/

On macOS and Linux, use the same options but replace the command name with curl. The example domain illustrates the request method; you can substitute a site known to be reachable directly on your network. If TUN, a side router, or an upstream transparent proxy is still active, --noproxy cannot bypass interception at those network layers.

If direct access still fails, check your network adapter’s IP address, default gateway, and router connectivity. Then test the same computer using a phone hotspot. If the hotspot works but the original network doesn’t, the issue is more likely related to that network’s DNS, routing, or access policies; this alone does not prove that a port is blocked.

3. System time and DNS: make sure hostnames resolve and certificates validate

Correct the system clock

TLS certificate validation depends on the current time, and some proxy authentication methods do too. In Windows 11, open Settings → Time & language → Date & time, turn on automatic time setting, and sync. In macOS, open System Settings → General → Date & Time and check that automatic date and time are enabled.

Check the date, year, and actual time—not just the displayed time zone. If the logs show certificate has expired or certificate is not yet valid, check both your system clock and the remote certificate. Don’t simply disable certificate verification.

Check the node hostname and test hostname separately

• Node hostname lookup fails: The core cannot resolve the server address, so the proxy connection cannot start.
• Test hostname lookup fails: The server may be reachable, but the specified test request cannot complete.
• Core and system resolve names differently: A successful system lookup does not mean the DNS upstream configured in the core is working.

Use the logs to identify the exact hostname that failed. On Windows, run Resolve-DnsName www.example.com; on macOS or Linux, run nslookup www.example.com, replacing the example hostname with the one shown in the logs. A system lookup is only a comparison: also check whether the core reports DNS resolve failed, an upstream connection timeout, or a resolution loop.

4. Test URL: check the request target, not just the number

Check which test URL the client is currently using. It may come from a setting in the interface, a url-test proxy group, or a proxy-providers health check in the configuration. These may use different URLs: changing the interface setting might leave background health checks using the old one.

Choose an HTTPS target that responds quickly, has a stable address, and is reachable over your current route. URLs that return 204 are commonly used for connectivity checks, but don’t assume that every failure to get a 204 means the node is down. Redirects, sign-in pages, rate limits, and how the client evaluates status codes can all affect the result.

Run two requests to the same target

The commands below access an example URL through a local HTTP proxy port. 7890 is only an example; replace it with the actual HTTP or mixed listening port used by your client. First make sure the current rules send this request through the node you’re testing. Otherwise, a successful request may simply have matched DIRECT.

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 -I https://www.example.com/

1. Send both a direct request and a proxied request to the same target, and save the error text.
2. In the client’s connection log, confirm the target hostname, matched rule, and final outbound node.
3. If only the test target fails, keep the node fixed and try another target known to work.
4. If the 5-second test fails but the request completes within 15 seconds, note it as a slow-response clue and continue checking the handshake and packet loss. Don’t just keep increasing the timeout indefinitely.

curl -I sends a HEAD request, unlike the GET requests used by some clients. If the target doesn’t support HEAD, remove -I and discard the response body with -o NUL (Windows) or -o /dev/null (macOS and Linux). Use the same request method for a fair comparison.

5. Local ports, rules, and TUN: confirm traffic actually uses the node under test

Start by checking an explicit proxy entry point

On Windows, use the command below to check whether the example port is listening. If it returns no results, check whether the client core has started, the configuration loaded successfully, and another process is occupying the port.

Get-NetTCPConnection -State Listen -LocalPort 7890

On macOS, use lsof -nP -iTCP:7890 -sTCP:LISTEN; on Linux, use ss -lntp to check listening ports. Seeing a port is not enough: confirm that the process belongs to the core used by your current client. Don’t send HTTP proxy requests to the controller port; it is not an entry point for proxy traffic.

Use the connection log to verify the routing policy

• Rule mode: Check the rule and policy group matched by the target. Confirm the final route isn’t DIRECT, REJECT, or a different node.
• Automatic selection groups: Pin a specific node while troubleshooting to avoid inconsistent results if the selection changes during a test.
• Proxy chains: A failure at any hop can make the final request time out. Simplify the setup to a single hop before comparing results.

If an explicit HTTP proxy works but traffic fails only when TUN is enabled, focus on routing, DNS interception, permissions, and conflicts with other VPNs. TUN changes how traffic enters the core; it won’t fix an incorrect password or an unreachable remote port. Save your logs and a copy of the configuration first, then check one item at a time. Don’t run several tools that all take over the default route.

If only games, voice calls, or QUIC requests fail, check UDP separately. A successful browser connection over TCP does not prove that the node protocol, server, and local network all allow UDP. If temporarily disabling QUIC in the app fixes the issue, that is a clue of a UDP path problem, not proof.

6. Protocol settings and remote server: check reachability and the handshake step by step

First, confirm that your current core supports the node protocol

Similar Clash configuration formats do not mean every core supports the same protocols and fields. If you’re using a mihomo configuration, note the actual core name and version—not just the client version shown in the interface. If the logs report an unsupported proxy type, unknown field, or configuration parsing error, resolve compatibility issues before running network tests.

Fetch the configuration again from a trusted original subscription, then check whether your account traffic, expiry status, or node list has changed. Verify server, port, protocol type, and authentication fields individually. For TLS or WebSocket, also check servername, the path, and Host. For REALITY, verify the public key, short ID, and other parameters provided by the service.

Don’t guess these settings from how a hostname looks. Replacing a node hostname with an IP address can change the TLS SNI, certificate validation, or server-side routing. Even if the TCP connection succeeds, that does not mean the full protocol handshake will work.

Treat port checks as limited evidence

On Windows, use Test-NetConnection to check a server’s TCP port. Replace the variables below with the actual server address and port from your configuration before running the check. The example port 443 is not universal.

$server = Read-Host "Enter the node server address"
$port = [int](Read-Host "Enter the node port, for example 443")
Test-NetConnection -ComputerName $server -Port $port

• TCP succeeds: This only confirms that a TCP connection can be established; it does not confirm that authentication, TLS, WebSocket, or proxy forwarding works.
• TCP fails: Possible causes include routing, access policies, a server that isn’t listening, or an incorrect address. One test alone cannot identify who is responsible.
• UDP protocols: TCP port checks cannot determine whether UDP-based connections such as Hysteria2 or TUIC are usable.
• Ping fails: The target may not respond to ICMP. That does not mean the proxy port is unavailable.

If the same node fails on two independent networks and its settings and account status are confirmed, contact the service provider to check the listening port, firewall, certificate, and server status. If multiple nodes share an entry-point hostname or relay, they may all fail because of that shared dependency—not because every destination server went down at once.

7. Wrap up with logs: capture the first failure, not just a red status screen

Temporarily set the log level to debug, clear old entries, and reproduce the failure once. Review the full context from the start of the request to the error: target hostname, selected node, DNS result, and handshake stage. Restore the original log level when you’re done to avoid generating excessive logs.

Checklist for completing a troubleshooting round

1. Confirmed whether direct access works with the proxy off.
2. Pinned one node and tested both real-world access and the latency check.
3. Checked the system clock, node hostname resolution, and local listening port.
4. Used the connection log to confirm the rule and final outbound route.
5. Compared results on another network, or noted why a comparison wasn’t possible.
6. Identified the stage where the failure occurs and prepared redacted logs for further review.

Following this order can narrow “all nodes timing out” to a specific layer: the local entry point, DNS, test target, protocol handshake, or remote route. For configuration terminology, see the Quick Reference. To continue checking system proxy and rule settings, see the Troubleshooting Guide.