A screen full of red latency numbers doesn't mean every node is actually dead. This guide walks through local network reachability, system clock drift, protocol port blocking, subscription server status, and client core version in order from nearest to farthest, with a self-check method and fix for each step.
You run a latency test and every node shows timeout or red. The gut reaction is usually "all my nodes are dead." But it's actually pretty unlikely that every node server would go down at the same time, especially when a subscription includes nodes from multiple providers and regions. The more common causes fall into three categories: first, something's wrong with your own local network path and traffic isn't leaving your device at all, which has nothing to do with the nodes; second, some kind of local or router-level blocking is specifically targeting the protocol ports Clash uses; third, the subscription itself, or the relay service behind it, is having issues, leaving node info stale or servers temporarily unavailable. Work through these three in order — check yourself first, then the network path, then the subscription — and you can usually pinpoint the actual break within ten minutes, instead of randomly switching nodes or restarting the client over and over.
Before diving in, set a baseline: if your browser can't reach common websites directly (without any proxy), the problem is almost certainly your local network and has nothing to do with Clash. If direct access works fine and failures only happen with the proxy on, then it's time to work through the core and subscription checks below.
Turn off Clash's system proxy and TUN mode so the device goes back to a direct connection, then try visiting a site that doesn't need a proxy. If even direct access fails, the problem is in your local network path — router, broadband line, or DNS provider — and the right move is contacting your ISP or restarting your router, not tweaking client settings further.
If direct access works fine, check whether the device is running multiple network tools at once — for example, another VPN client, a corporate network access agent, or leftover system-level proxy settings. These often conflict with Clash's virtual network adapter or system proxy configuration, cutting off traffic or redirecting it to the wrong exit before it even reaches a node. Try disabling these tools one at a time and re-testing to see if a conflict is the culprit.
This step is easy to overlook, but it's one of the most common causes of every node timing out at once. When Clash-based clients establish a TLS connection with a remote node (especially Trojan, VMess over TLS, and some Hysteria2 setups), both client and server validate the certificate's validity period. If your system clock is significantly off — common with virtual machines, dual-boot setups that never synced, or a manually changed system clock — certificate validation fails outright, and every node using TLS will show timeouts or connection refused, while nodes on other protocols might still connect.
Checking this is simple: open your system's date and time settings, confirm "Set time automatically" is on, and check that the time zone is correct. If the clock is off by more than a few minutes, sync it manually. After fixing this, go back to the client and re-test — you'll usually see some or all nodes recover immediately.
Virtual machines, cloud servers, and devices right after a fresh OS install are especially prone to clock sync issues. It's worth keeping this check second on your list rather than an afterthought.
If direct access works fine and the system clock checks out, the next suspect is your network blocking specific ports or proxy traffic patterns. Some home broadband, public Wi-Fi, corporate networks, and campus networks throttle or block non-standard ports or traffic with obvious proxy signatures, which can make Clash's protocol ports permanently unreachable on that network — while switching to a phone hotspot or another network connects fine. That contrast is the clearest way to tell if port blocking is the issue.
If your subscription offers nodes with multiple protocols or ports, try switching between them in the client — for example, from a fixed-port VMess node to a Trojan/TLS node running on port 443 — and compare results. If switching protocol or port restores the connection, you can be fairly confident your current network is blocking the original port, and it's not a node or client issue. If you're stuck on the same restricted network long-term, nodes using common HTTPS ports (443) tend to be more reliable, since that traffic looks like ordinary web browsing and is less likely to get singled out.
| Test Action | Result | Initial Read |
|---|---|---|
| Retry on a phone hotspot | Connection restored | Current network is blocking a port or protocol |
| Retry on a phone hotspot | Still times out | Not a local network issue — keep checking further down |
| Switch node protocol or port | Some protocols work | The original protocol/port is specifically targeted |
Only after ruling out local network, system clock, and port blocking should you suspect the subscription or nodes themselves. Two things to distinguish here: the "subscription link" is just a config file hosted on the provider's server that tells the client which nodes exist and what their connection parameters are; the "node server" is the actual machine handling traffic. A subscription can update fine and return a complete node list, but the servers behind those nodes could still be down for maintenance, scaling, or a temporary outage — in which case the client imports the config just fine but every connection attempt times out.
To check: refresh your subscription and confirm the node count and last-updated time look normal. If the subscription hasn't updated in a long time, or the node count has dropped unexpectedly, contact your subscription provider to check for a server-side issue. If the subscription updates fine and the node list looks complete but connections still all time out, try testing just one or two nodes from different regions and protocols individually, rather than testing dozens of nodes at once — bulk concurrent testing eats up your own bandwidth and connection slots, and on a less capable device that alone can make every result show as a timeout, creating the illusion that "everything is broken."
If your subscription comes from a free or short-lived source, node servers going offline or domains migrating happens far more often than with a stable paid service. If everything times out and the subscription won't update for a long stretch, switching subscription sources usually saves more time than continuing to dig through local settings.
Clash-based clients aren't all built the same way. Common cores include the original Clash core (no longer maintained), Clash Premium, and the now-dominant Clash Meta (mihomo core). Protocol support, timeout detection logic, and TUN mode handling all differ between cores. If your client hasn't been updated in a while and is still running an older core, nodes using newer protocol features (like updated Hysteria2 parameters or new Shadow-TLS combinations) may show up as unrecognized or simply time out across the board, instead of returning a clear error.
To check, look at the core version listed on the client's About page and compare it against that project's latest release. If your version is clearly outdated, updating the client and re-importing your subscription before re-testing is the lowest-effort, most direct fix in this whole process — worth trying first if the previous four steps didn't solve it.
Chain these five steps together and you get a troubleshooting path ordered from near to far, low cost to high: first confirm your own direct connection works, then check system clock accuracy, then check whether the current network is blocking specific ports or protocols, then check subscription and node server status, and only then consider updating the client core. The logic is simple — causes closer to your device are cheaper and faster to check and fix, so rule those out first; causes farther away, like the server side, involve more variables and cost more time to investigate, so they come last.
In practice, most "all nodes timing out" cases get resolved at step 2 (system clock) or step 3 (port blocking) — the share of cases that actually require contacting a subscription provider or updating the client is fairly small. Working through the full sequence in order also means that even if the issue does turn out to be on the subscription or node side, you'll be able to describe exactly what you've already ruled out — like "direct connection works, clock is synced, switching protocols fixes it" — which helps get the issue resolved faster.