How Clash Latency Testing Works: Why the Panel's Milliseconds Don't Match Real Speed

Open the Clash panel and you'll see a column of numbers next to each node — for most people, that's the only thing they use to pick a proxy. Smaller is better, as if latency were a stand-in for speed. But if you pay attention, you'll notice something counterintuitive: one node shows 40ms, which looks impossibly fast, yet a video site buffers nonstop through it. Another node shows 300ms, which looks suspiciously slow, yet browsing feels perfectly smooth. This isn't a bug in the panel. It's that what a latency test actually measures and what you experience day to day are separated by several layers of nuance that rarely get spelled out.

What Latency Tests Actually Measure

When Clash (and any client built on the Clash Meta / mihomo core) runs a latency test, it doesn't visit the site you actually want to open. Instead, it sends a request to a fixed test URL specified in the configuration and records the time between sending that request and receiving a response — that gap is the millisecond figure shown on the panel. By default, this URL is usually something like http://www.gstatic.com/generate_204 — an endpoint Google provides specifically for connectivity checks, chosen because it responds extremely fast and returns almost no data, so it barely touches bandwidth.

The full test path roughly looks like this: your device → the local Clash core → the selected proxy node (possibly through one or more hops) → the exit server → the server hosting the test URL → and back the same way. If any single link on that path slows down, the number on screen goes up. But notice what's missing entirely from this chain: the site you actually want to visit. The test URL's server and the video platform, social network, or work tool you actually open may sit in completely different physical locations, network architectures, and CDN footprints. The latency number reflects handshake speed on one specific path — node to test server — not the speed from that node to any arbitrary destination.

Why HEAD Requests Instead of a Full Download

If you look closely, you'll notice latency tests finish almost instantly, even on lines that aren't especially fast. That's because most implementations use an HTTP HEAD request (or a GET request against a near-empty response, like a 204 No Content endpoint) — the server only needs to send back a response header, with no body data transferred at all. The upside is obvious: the test itself barely uses any traffic, and the result isn't skewed by download size or bandwidth, so it purely reflects how fast the connection gets established.

But that's exactly its limitation. A HEAD request only measures the handshake phase — TCP's three-way handshake, TLS negotiation, and the round trip from request to response header — with a data volume small enough to ignore. What you actually experience when loading a webpage, streaming video, or downloading a file depends on sustained performance under continuous, heavier data flow: is bandwidth sufficient, does packet loss occur mid-transfer, how costly are retransmissions after a loss, and do multiple concurrent connections crowd each other out. None of that shows up in one tiny HEAD request — a node can absolutely "handshake fast, then choke the moment a large transfer starts."

A Fast Handshake and a Stable Transfer Are Two Different Things

Here's an analogy: a latency test is like timing how fast a friend picks up your call — a quick pickup means the signal's clear and the line isn't jammed. But whether the call quality holds up, whether it suddenly drops, whether the volume fluctuates — that's a separate matter you can only judge by staying on the line. A low-latency node tells you the "connection" step went smoothly; whether that holds once a flood of data starts pouring through is something the latency number simply can't answer.

Why a Low-Latency Node Can Still Buffer

Following the logic above, buffering usually comes down to a handful of factors that latency tests completely miss:

• Insufficient bandwidth ceiling. The node server's uplink bandwidth may be capped, or saturated by other users at that moment. The handshake still comes back fast, but once a sustained heavy stream like video starts, throughput can't keep up, and you get repeated buffering.
• Jitter and packet loss. Latency numbers are usually a single measurement or an average of a few taken in a short window, which hides fluctuations in network quality. If the line swings between fast and slow with occasional packet loss, something that needs steady sustained throughput — like video playback — will visibly stutter, even though a single latency check may have happened to catch a good moment and shown a clean number.
• Different CDN footprints for the destination site. The test URL's server and the video or download site you actually visit may sit in entirely different data centers, even different continents. The path from your node to the test server might be short, while the real path to your destination detours much farther, crossing different carrier hops and congested international gateways.
• Exit region and content-delivery policy. Many streaming platforms assign different delivery nodes or throttling policies based on where a request appears to come from. If a node's exit region happens to fall into a zone that platform throttles or that gets congested at peak hours, the video stream will still be limited even though the handshake to the test URL was fast.
• Concurrent connection load. Loading a webpage or streaming video often opens several connections at once. If the proxy node or exit line has limited capacity for handling concurrency, those connections compete for resources, and the real experience ends up worse than what a single latency test suggests.

Judging Nodes Closer to Real Experience

Since a latency number is only part of the picture, here are a few more direct ways to evaluate nodes day to day, instead of fixating on the millisecond count.

1. Check throughput alongside the latency test. Most clients also offer a "speed test" button that actually downloads a chunk of data to measure bandwidth. That number reflects sustained transfer capability far better than latency alone — the two are worth checking together.
2. Do a short real-world trial. For the handful of services you regularly use, don't overthink the latency figure — just switch nodes and open the service for a few dozen seconds. Whether video buffers smoothly or the page loads cleanly tells you far more than any latency number could.
3. Test several times and look at a range, not one number. If a node's latency swings wildly between tests (say, 60ms once and 400ms the next), that line is inherently unstable, and that instability matters more than the absolute value.
4. Check whether the rule match and exit region actually fit your need. A low-latency node whose exit region isn't suited to the service you're accessing still won't deliver good speed. Conversely, rule-based configs that route different types of traffic to different, better-suited nodes are often more practical than chasing a single "lowest latency, all traffic" node. See the guide on choosing a proxy mode for how rule-based, global, and direct routing each play their role.

The Test URL Itself Deserves Attention Too

If you've customized the test URL in your configuration, pick an address with a stable response and a reasonably representative location — avoid one that's inherently unstable or geographically far from the region you actually access, since that will further dilute how meaningful the number is. The connectivity-check endpoints used by default in most clients and subscription configs have already been widely vetted, so there's usually no need to change them; only consider swapping in another lightweight, public endpoint if the default address itself is unreliable from your network.

Summary

The millisecond number on the panel is, at its core, the handshake time between a node and one fixed test address — it reflects how smoothly the connection gets established, not how well the node performs under sustained heavy data transfer, and certainly not your real experience opening a specific site. Once you understand that gap, ranking nodes by single-digit millisecond differences stops mattering, and you start paying attention to what actually decides "fast or laggy": whether bandwidth is sufficient, whether the line is stable, and whether the exit region fits your actual use case.