Clash Latency Numbers Explained:
Why Low Ping Doesn't Mean Smooth Streaming

What the latency number actually measures

Open the Clash client and look at the millisecond figure next to each node — it comes from a single probe the core sends out for that node. Here's how it works: the client connects through that node and sends one HTTP request to the test-url defined in the config (usually a lightweight endpoint like http://www.gstatic.com/generate_204 or similar), then records the time between sending the request and receiving a response. That elapsed time is the "latency" you see.

This process only involves three things: DNS resolution (if the target is a domain), a TCP/TLS handshake, and one tiny HTTP round trip. No real content gets downloaded — the target endpoint typically just returns an empty 204 response or a few bytes of text, so the test barely touches bandwidth at all. That means the number reflects how fast a single round trip through that node completes — not whether the node can handle streaming video or large downloads. Those are two different questions.

Why low latency can still feel laggy

Assuming a node is "fast" just because it shows 30ms or 50ms is the most common misread. Real-world lag usually comes from things the latency test never touches at all:

• Packet loss and jitter: a latency test is a single probe — one success doesn't mean sustained stability. A node might respond quickly at one instant, then drop packets intermittently during the tens of seconds you're actually browsing or streaming, causing stutters or frozen loads, right as the latency list happens to refresh with another clean reading.
• Bandwidth and exit congestion: the probe's payload is essentially zero, so it never triggers throttling or congestion; but streaming a video or downloading a file needs sustained throughput. If the node's exit bandwidth is limited or shared among many users, actual speed can fall well short of what the latency number implies.
• Target server and route quality: the test URL is usually a lightweight endpoint from a major overseas provider, which may sit on a completely different network path than the site or app you actually want to reach. A clean test path doesn't guarantee a clean path to your real destination.
• Protocol-level differences: different proxy protocols behave differently under small-packet probes versus sustained heavy traffic — some protocols excel at low-latency scenarios but are more prone to dropped connections and reconnects under weak networks or high concurrency.

How test-url, timeout, and concurrency shape what you see

Latency numbers aren't computed once and frozen — they're shaped by several configurable mechanisms. Understanding these helps you judge whether a given number is trustworthy.

test-url: whose path is actually being tested

The url field (sometimes written as test-url) in a proxy-group config determines the probe target. Most subscriptions default to a lightweight overseas detection endpoint that responds quickly almost everywhere, which is why the numbers tend to look uniformly low and "good." If what you actually access is a specific region or service, its network path could be entirely different from the default test target — a good-looking number doesn't guarantee your real destination is equally fast.

interval: how often it retests

The proxy group's interval field (in seconds) sets how often auto-testing runs, commonly around 300 seconds. That means the number you're looking at could be a snapshot from several minutes ago — network conditions change constantly, and the displayed value always lags a bit behind the real "right now" state.

tolerance: no switching within the margin

The tolerance field (in milliseconds) sets the switching threshold for auto-select proxy groups. If a newly measured node is only marginally better than the current one — within the tolerance margin — the client won't switch, to avoid constant reconnects from minor fluctuations. That's why sometimes a lower-latency node sits right there in the list and auto-select still doesn't switch to it — it's following the tolerance rule, not failing to notice.

timeout and concurrent probing

Each probe has its own timeout threshold; exceeding it gets marked as a failure or an extremely high value. A batch of nodes is often tested concurrently, and if local network conditions, CPU, or concurrency settings aren't well tuned, a burst of simultaneous requests can compete for resources, pushing the measured numbers up or making them unstable. In that case a single test run has limited value — run a few more rounds and look at the trend instead.

Three habits for reading latency numbers correctly

1. Watch the trend, not a single value: manually trigger a retest a few times (most clients support click-to-refresh or right-click test on a single node) and watch how much that node's number fluctuates over time. A node with small fluctuations usually feels more solid, even if its average is slightly higher.
2. Validate against real use: once the number looks fine, actually open a site you use often or run a small file download and see how it feels — that's more telling than staring at digits.
3. Distinguish auto-select groups from manual groups: if a proxy group is auto-select (url-test type), it's already filtering nodes by interval and tolerance for you; in a manual group the number is just a reference point — real usage experience should decide whether to switch.

Numbers look fine but experience is bad — how to dig further

If latency stays low but pages load slowly, video keeps buffering, or downloads crawl, work through this checklist:

• Switch to another node and run the same comparison — this tells you whether it's a single node issue or a problem shared across the whole subscription's line.
• Check whether TUN mode is on, and whether rule-based routing correctly directs high-traffic apps to a suitable proxy group instead of dumping everything onto one potentially overloaded node.
• Confirm whether it's peak hours — some lines get congested in the evening as many users share bandwidth simultaneously, and that kind of congestion never shows up in a small-packet latency probe.
• Rule out local network issues by testing your raw connection speed and packet loss with the proxy disabled first, to make sure it isn't just a local-network artifact.

What combination of signals to check when picking a node

Treat latency as a first-pass filter, not the final word — combine it with these signals for a more reliable pick:

• Latency stability: the range across multiple tests matters more than any single reading.
• Protocol and encryption: different protocols hold up differently under weak networks and high concurrency — comparisons are only meaningful across nodes using the same protocol.
• Exit region and route: the same node can behave quite differently across time slots and target sites — long-term observation beats a one-off judgment.
• Actual throughput testing: if you can, run a real download or speed test to check whether bandwidth actually matches the good impression the latency number gave you.

Latency testing is a quick filter that helps you rule out obviously broken or timed-out nodes fast, but day-to-day experience always comes down to the combined effect of bandwidth, packet loss, and route congestion. Look at these factors separately, and a flattering millisecond figure won't be able to fool you.