How Clash Latency Tests Really Work: Why Low-Ping Nodes Can Still Feel Sluggish

1. How the Latency Number Is Actually Measured

Tap the speed-test button in the node list of a Clash client, and a few hundred milliseconds later every node shows a millisecond figure. Here's how it's generated: the core routes a single HTTP request through that node to a test URL. The usual test URL is https://www.gstatic.com/generate_204, which just returns an empty 204 response with a zero-byte body. The time from sending the request to receiving the response headers is what shows up as "latency" on screen.

Break that single request down and it's made up of three segments: your device connecting to the node server (a TCP handshake, plus an extra TLS handshake for TLS-based protocols), the node server connecting to and forwarding the request to the test URL, and the test server generating a response that travels back along the same path. So it's essentially a round-trip time for one tiny request — not download speed, and definitely not video bitrate.

The automatic testing behind a url-test group works the same way as a manual tap — it just runs on a timer. Here's a typical auto-select config:

proxy-groups:
  - name: Auto Select
    type: url-test
    proxies:
      - NodeA
      - NodeB
      - NodeC
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

Here, interval is the test cycle — 300 seconds by default — and tolerance is the margin required before switching: a node only takes over if it beats the current one by more than this many milliseconds (50ms by default), which stops the group from flip-flopping between two nodes with near-identical latency. Keep these two settings in mind — they'll matter later when picking nodes.

2. Why Low Latency Doesn't Mean Fast

A single 204 request moves only a few hundred bytes — it measures how quickly a link "responds," not how wide the pipe actually is. None of the factors below, which actually shape real-world performance, show up in that number at all.

Bandwidth and Single-Connection Throughput

Real download speed depends on remaining bandwidth and TCP congestion control. Roughly speaking, a single TCP connection's max throughput is about "in-flight window size ÷ round-trip latency" — so low latency does help, but only if there's enough bandwidth and no packet loss. A 30ms link with only 5 Mbps free will always lose out to a 200ms link with 300 Mbps free. A pretty millisecond figure doesn't mean fast data transfer.

Packet Loss: The Hidden Killer

Once TCP drops a packet, it has to retransmit, and the congestion window shrinks too. Just 1% packet loss can cut throughput in half, then in half again — and that tiny 204 test request can easily sail through without hitting a single dropped packet, so the result looks perfectly fine. On international links during peak hours, packet loss often gets bad before latency does, and it hurts a lot more.

Jitter: The Other Side of Stability

Latency swinging up and down is called jitter, and a single-sample speed test can't show it at all. Sudden video stutters, ping spikes mid-game, choppy voice calls — most of that comes from jitter and bursty packet loss, not average latency. A node averaging 60ms but occasionally spiking to 400ms feels far worse than one holding steady at 150ms.

Peak-Hour Congestion and ISP Throttling

Plenty of links are wide open during the day and jammed between 8pm and 11pm. If you always run speed tests in the afternoon, the "fastest node" you pick may not hold up during peak hours. Some ISPs also throttle specific ports or protocols (QoS) — a tiny test request won't reveal it, but sustained heavy traffic exposes it immediately.

Load on the Node Server Itself

Nodes are shared resources. The more users on one server, the worse the CPU queuing for encryption/decryption gets, and the more the network bandwidth gets divided up. Overhead from TLS, obfuscation, and similar protocols gets amplified when the server is busy — latency does eventually get worse too, but it usually lags behind the real-world slowdown, so by the time the millisecond number climbs, you've already been dealing with lag for a while.

3. What a Speed Test Result Can Still Tell You

The latency number isn't useless — you just need to read it correctly.

Timeout and "slow" are two different things. A timeout means no response arrived within the timeout window (about 5 seconds by default) — usually because the node is down, its entry point is blocked, or the handshake failed. Treat that node as unusable, not just "a slow one."

Test several times in a row and look at the spread, not a single reading. 50, 55, 52ms is stable. 80, 300, 150ms is heavy jitter. Even if the low end looks great, real-world performance on the jittery node is usually bad.

Use a dashboard to check the history. Dashboards like metacubexd or Yacd show latency history for each node — a flat, steady curve is more trustworthy than a low single number.

Remember the test URL has its own routing preference. Fast access to gstatic doesn't mean the same speed to your favorite streaming site or game server — they may take a completely different international route. A passing speed test only confirms "the path to this one test address works."

4. A More Reliable Way to Pick Nodes

1. Retest with real traffic. Once you've narrowed it down to two or three candidates, run each for ten minutes: watch a high-bitrate video (the connection speed shown in the player's stats is a good indicator), run a multi-threaded speed test, and check whether a single-thread large file download stays smooth. A node only qualifies if it passes all three.
2. Retest during peak hours. Repeat the same tests between 8pm and 11pm. Any node that's fast when idle but collapses under load should be demoted to backup, not left at the top of an auto-select group.
3. Watch the jitter, not a single reading. Run five to ten consecutive tests and note the gap between the highest and lowest values — the smaller the gap, the steadier the node. When stability matters most, pick a steady mid-latency node over an erratic low-latency one.
4. Let policy groups do the monitoring for you. Hand everyday browsing to url-test with a sensible tolerance value; for anything that needs rock-solid stability (remote desktop, video calls), use fallback so it only switches when the primary node actually fails:

proxy-groups:
  - name: Stability First
    type: fallback
    proxies:
      - PrimaryNode
      - BackupNode
    url: https://www.gstatic.com/generate_204
    interval: 120

5. Split traffic by use case instead of chasing one "do-everything" node. Route downloads through high-bandwidth nodes, and gaming/calls through low-latency, low-jitter nodes, keeping them in separate policy groups so neither gets in the other's way.

5. Common Questions

A node shows 30ms latency — why does 4K video still buffer?

Because 4K video needs sustained throughput above 25 Mbps, not low latency. When latency looks fine but bandwidth is limited or packet loss is high, buffering still happens. Test throughput using the method in section 4 instead of staring at the millisecond number.

Same node is fast on my phone but slow on my computer — is the test just inaccurate?

Not necessarily a node problem. Both devices reach the node over the same link, so the bottleneck is likely on the computer's side: weak Wi-Fi, a local firewall blocking traffic, or TUN mode overhead. TUN mode adds an extra virtual network adapter forwarding layer, which can cut throughput on less powerful devices — and that has nothing to do with the latency test.

The speed test is all green, so why won't pages load?

A speed test only confirms whether the path to the test URL is reachable — it doesn't check for rule-matching errors or DNS resolution issues. For that kind of problem, work through the FAQ page step by step, focusing on the system proxy switch, rule mode, and DNS settings.