...
Back

The Latency Number Next to Your Node Is Lying to You

Everyone picks the node with the lowest ms. That number is a round trip, not bandwidth — and measured data shows the fastest-looking node can be the slowest one you own. Here is what actually determines throughput.

The Latency Number Next to Your Node Is Lying to You

The Latency Number Next to Your Node Is Lying to You ⏱️

Every proxy client shows a number beside each server. Lower looks better, so you tap the lowest one and move on.

That number is a round-trip time — how long a tiny test request took to go out and come back. It is genuinely useful for one question: is this endpoint alive, and roughly how far away is it?

It tells you almost nothing about how fast your download will be.


📊 What the Measurements Actually Showed

Here are real measurements taken through one subscription, on one device, in one sitting — latency as reported by the client, throughput measured by actually pulling data:

NodeReported latencyMeasured throughput
Node A488 ms (lowest!)0.9 Mbps
Node B587 ms55.9 Mbps
Node C651 ms0.0 Mbps
Node D604 ms35.7 Mbps

Read that first row again. The node with the best latency delivered under 1 Mbps. A node with worse latency delivered sixty times more. And Node C, which looked perfectly reasonable at 651 ms, could complete a handshake but moved essentially no data at all.

If you picked by the number on screen, you would have chosen the worst performer in the list.


🤔 Why They Are Unrelated

Latency measures one round trip of a very small request. Throughput measures how much data a link can sustain. These are different physical properties.

An endpoint can answer a tiny probe almost instantly and still be:

  • sharing a saturated uplink with many other users,
  • rate-limited per connection,
  • running a transport that handles small requests well and bulk transfer badly.

The reverse happens too: a geographically distant endpoint with unremarkable latency can sit on an excellent, uncongested path and move data beautifully.

A quick reply is not a wide pipe.


🎲 The Second Problem: Some Nodes Get Traffic They Shouldn't

Most clients offer automatic groups. How that group picks matters more than most settings in the app.

Some strategies distribute connections by turn, by hash, or by session. They spread load evenly — and they do not rank members by health. If your subscription contains endpoints that are unreachable from your network, those endpoints still receive their share of your real traffic.

That failure has a distinctive signature: it works, then it doesn't, with no pattern. Some pages load, others hang. It feels like an unstable connection rather than a dead node, so people go looking in the wrong place.

Measured on the same subscription, three consecutive requests through a strategy that ignores health gave 69.9 Mbps, then 0.0, then 0.6. A health-ranking strategy, same subscription, same sitting: 42.7 / 29.4 / 26.0 / 59.4 / 39.2 Mbps — five for five, no failures.

Same servers. Same network. The difference was entirely in which member the group handed each connection to.


🕰️ The Third Problem: Stale Health Data

Latency figures get refreshed on a schedule, and in many clients that schedule stops while the tunnel is idle.

So you connect in the morning, and the selection logic reaches for measurements taken hours ago — back when a now-dead endpoint happened to be the fastest one. The client reports connected. Nothing loads. Nothing is actually broken; the decision was just made on expired data.

This is why AI Booster refreshes node health the moment a tunnel comes up, rather than waiting for the next scheduled sweep.


✅ What To Do Instead

  1. Do not choose by the ms number alone. Use it to rule out the dead and the very distant — not to pick a winner.
  2. Test the transfer you actually care about. Page loads are dominated by round trips and will not reveal a bandwidth ceiling. Pull a real file.
  3. Prefer a selection strategy that ranks by health, so unreachable members are excluded instead of being handed a share of your traffic.
  4. Re-run the test after idle time. A figure from hours ago describes a different internet than the one you are on now.
  5. Verify the tunnel is even carrying your traffic. Check your public IP before and after connecting — if it does not change, something is bypassing the tunnel entirely, and no amount of node-switching will help.

🧭 Where AI Booster Lands

AI Booster shows per-node latency measured by its core, defaults to a health-ranking selection strategy so unreachable endpoints stay out of the rotation, and re-measures as soon as you connect instead of trusting a stale sweep.

It still shows you the ms number — it is useful. You just now know what it does and does not mean.


Learn more: node selection and what the latency number means · troubleshooting guide

The measurements above came from one device, one subscription and one network. Your numbers will differ — the point is the relationship between them, not the absolute values.