Clash Nodes All Timing Out: A Step-by-Step Fix from Subscription Expiry to Port Conflicts

First, tell "all nodes timing out" apart from "some nodes timing out"

Before diving in, sort out which case you're actually dealing with — it saves half the troubleshooting time.

• Some nodes time out, others work fine: this is almost certainly a node or exit-line issue. Just switch to a working node — no need to suspect your local setup.
• Every node times out at once, including ones that were rock-solid before: this is the case this guide covers. The problem is almost always your local environment or the subscription itself — dozens of nodes don't fail simultaneously by coincidence.

If the speed test screen just shows "timeout" or a flat 0ms that never changes, don't rush to delete nodes or switch providers. Work through the steps below in order.

Step 1: Make sure the subscription hasn't expired

A subscription link points to a config snapshot generated by your provider. Most services don't delete the link once it expires — the link stays reachable, but every node in it goes dead, or the response comes back empty. This "looks fine but is actually dormant" state is easy to mistake for a client-side bug.

1. Open your provider's user dashboard and check the actual plan expiry date — don't just check whether the subscription link still loads.
2. Manually trigger "Update Subscription" in the client and watch whether the node count or names actually change. If the list is identical before and after, the server isn't pushing new data.
3. Check whether your plan has a data cap or throttling clause. Some providers keep the link alive but stop serving traffic once your quota runs out, without throwing an explicit error.

Step 2: Check your local system clock

This step gets skipped constantly, yet it's the highest-value check on the list. Most proxy protocols — especially AEAD-based ones like Shadowsocks and VMess, plus anything relying on TLS certificate validity checks — verify timestamps during the handshake. If your system clock drifts too far from real time, the server flags the request as invalid and drops it outright. The symptom looks exactly like "every node timing out," even though your network connection is fine.

• On Windows, check whether "Set time automatically" is enabled in the clock settings, and confirm your time zone is correct.
• On macOS/Linux, run date in a terminal and compare it against the network time shown on your phone.
• Virtual machines, older routers, and devices waking from long sleep are especially prone to clock drift. Re-sync with an NTP server, then test again.

The drift doesn't need to be down to the second, but anything off by more than a few minutes is enough to break encrypted handshakes. This check costs almost nothing, so run it right after the subscription check.

Step 3: Check for port conflicts

Clash / Clash Meta (mihomo core) needs to bind the mixed port, HTTP port, SOCKS5 port, and the controller/API port on startup. If another process is already holding one of these ports, the client can look like it's running normally while every single request quietly times out — instead of failing to launch outright.

1. Check whether another proxy tool, a leftover process from an older client version, or a previous instance that didn't shut down cleanly is still running.
2. On Windows, run netstat -ano | findstr 7890 (swap in your actual configured port) to see if another process is holding it.
3. On macOS/Linux, run lsof -i:7890 to check what's using the port.
4. If you find a conflict, kill the offending process or switch to a free port in your config, then restart the client and test again.

Step 4: Check whether the protocol matches your core version

Some nodes use newer protocol features (Hysteria2, certain VMess AEAD variants, specific Trojan extension parameters). If your client is running an older core that doesn't recognize these fields, it may not throw a clear error — it might just mark the node as unavailable or time it out silently. A telltale sign: the same subscription works fine on a newer core but fails entirely on an older one.

• Check whether you're running Clash Premium (discontinued) or a Clash Meta / mihomo core — newer protocols are essentially only supported on Meta-family cores.
• Check the core version number on the client's About or Settings page, and compare it against the latest official release to see if it's noticeably behind.
• If your provider says a newer protocol is supported but your local core is outdated, update the client to the latest version first, then retest.

Conversely, if your config file contains a field or proxy type your current core doesn't recognize, some clients simply skip that node instead of raising an error — which also creates the illusion of "all nodes gone or timing out," when really they were filtered out during parsing.

Step 5: Getting the speed test right

Once the first four steps check out, look at the latency test itself. The test endpoint (something like http://www.gstatic.com/generate_204) can itself be flaky on certain networks. If that endpoint is blocked or unreachable, every node shows as timed out even though they're actually working fine.

1. Check which test URL your client is using in its settings, and try switching to a different, commonly used one.
2. Manually select a node, switch to Global mode, and try loading a webpage directly — don't rely on the latency number alone.
3. If the latency reading looks broken but the page loads fine, the test endpoint itself is the problem — the node is working, and there's no need to keep digging into its config.

Quick recap of the diagnostic order

Follow this fixed sequence whenever every node times out — it should pinpoint the issue within a few minutes:

1. Subscription expired or out of data — check your provider's dashboard, not just whether the link opens.
2. System clock drifted — verify auto-sync is on and the time zone is correct.
3. Port conflict — confirm with netstat/lsof and clean up leftover processes.
4. Protocol/core version mismatch — update the client core and check protocol support.
5. Test endpoint itself broken — switch endpoints and confirm by actually loading a webpage.