Keep one thing in mind before you touch anything: this test is not a ping. The client sends an HTTP request through the node to a test address and reports how long the response took. That test traffic travels the same path your browsing does, so any break along the way turns into a timeout — including a test address you were never able to reach in the first place.

That leaves a single question to answer: is the whole column failing, or only a handful of nodes? The two cases barely overlap, and choosing the wrong one is how people spend an hour replacing a subscription that was working fine.

Everything timed out: suspect your machine, not the nodes

  1. Switch the test address to something you know opens reliably from where you are, then run the test again.
  2. Look at the system clock. If it is off by more than a minute or two, sync it and retest.
  3. Turn the proxy off and open that test address directly in a browser, to confirm your local network and DNS are alive.

The first one is by far the most common, and it is worth understanding why. The test request goes through your rules like any other request, and plenty of configurations send that address out via DIRECT. If it does not open on your network unproxied, every node in the list times out in perfect unison — which looks exactly like a collapsed subscription, when in fact nothing is wrong with any node. Point the test at an address that answers reliably from where you sit and the numbers appear immediately.

A skewed system clock is the most recognisable variant of this. A few minutes of drift is enough to break the TLS handshake, and the symptom is precisely that: the entire column fails, with nothing surviving. A virtual machine that was suspended for weeks, a dead motherboard battery, two operating systems disagreeing about the timezone — all of them produce it. Checking takes five seconds, so check early.
SponsoredWhere does the subscription link come from?Our partner provider gives you 1 GB of high-speed Hong Kong data at signup — import it in one click.Get high-speed nodes

Only a few timed out: now it is about the nodes

  • The node is gone. Providers retire machines and swap lines constantly, and your client is still holding the copy it pulled last week. Refresh the subscription before you study a dead entry any further.
  • The protocol is being interfered with on your current network. UDP-based transports are the usual casualty, since carrier QoS squeezes them; the giveaway is that every other node from the same provider works and only these few do not. Find a TCP-based node in the same subscription and compare.
  • The exit is saturated. Evenings are the peak, and a node that tests fine at noon and times out at ten at night is almost always this — and almost never something you can fix.

The middle one gets misdiagnosed as a dead node constantly. Test the same node from a different network; a phone hotspot is enough. If it works on the hotspot, the node is healthy and it is your network squeezing that transport. If it fails on both, the node itself is the problem.

Some timeouts are manufactured by the test

One click and the client tests dozens or hundreds of nodes at once, with all those requests queueing on your single uplink. The ones at the back of the queue run straight into the deadline, so the failure rate you are looking at is inflated. If you genuinely care about a few specific nodes, test them one at a time. The results will not resemble the batch run.

The other factor is the deadline itself. Most clients expose an adjustable test timeout, and the default can be tight for a transoceanic route during evening peak — a node that would have answered in a little over two seconds gets written off. Raise it and a batch of false timeouts comes back to life. Whatever still fails afterwards is the part worth taking seriously.

A timeout is not a verdict

The test hits one address over one path. Whether the site you actually want sits in the same direction, or crosses the same congested segment, is a separate question. So both of these happen routinely: a node that tests as a timeout loads your sites smoothly, and a node showing a tidy 80 ms is unwatchable for video.

Do not treat that column as a conclusion. The reliable way to judge a node is to select it and spend three minutes on the handful of sites you actually use. It is not a clever technique, but it beats every number in the list.