How Clash Latency Testing Works: Why the Panel's Millisecond Number Doesn't Match Real Speed

What that latency number in the panel actually measures

Open the Clash dashboard and every node has a millisecond number next to it — green for fast, red for timed out. Plenty of people treat this number as a direct answer to "how fast is this node," pick whichever has the lowest value, and then find browsing still stutters or downloads never speed up. The problem is in how that number is interpreted: it doesn't measure network speed. It measures the round-trip time of a single network request, and both the target and the method of that request are predetermined by the client — they may have nothing to do with the site you're about to actually visit.

This mechanism is called URL Test in both Clash and Clash Meta (mihomo). The idea is simple: the client sends an HTTP request through a given node to a fixed address, records the time from sending to receiving a response, and that duration is what gets displayed. The whole process is a single request — no large file transfer, no throughput measurement — so what it reflects is "connectivity and response speed," not "how fast this node can actually download."

In a config file, this section usually looks like this:

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

url is the test target, interval is how often (in seconds) it retests automatically, and tolerance is the threshold — the client only switches nodes once a new latency reading is lower than the current one by more than this amount, which prevents constant flip-flopping over a few milliseconds of jitter. These few fields basically govern how the number in the panel behaves.

How the handshake type affects the number

Latency test time isn't purely "network transit" — it also includes the overhead of establishing the connection at the protocol level. Different proxy protocols require a different number of steps before a usable connection exists, and all of that gets baked into the latency figure.

• TCP three-way handshake: any TCP-based protocol has to complete this first, typically costing close to one round-trip time (RTT).
• TLS handshake: protocols that run over TLS (Trojan, some VMess/VLESS setups) also need a key exchange after TCP, usually adding another 1–2 RTTs — more noticeable on the first connection.
• Protocol-level authentication/negotiation: things like Shadowsocks cipher negotiation or VMess timestamp validation each add a small, fixed amount of overhead.

This means the same server on the same physical link can show different latency numbers depending on which protocol is used to set up the node — the difference comes from protocol overhead, not the line itself getting worse. Conversely, two nodes with similar latency numbers but different handshake complexity may still feel noticeably different when actually loading a page, since browsing typically opens multiple connections and the handshake overhead gets counted repeatedly.

The subtleties of the test endpoint and result caching

The number in the panel isn't refreshed in real time — it's tested periodically at the interval set by interval, and the result is cached and shown as-is between tests. This leads to a common misunderstanding: the "current latency" you're looking at may have been measured minutes ago, and the actual state of the line right now may already have shifted, especially on links that fluctuate during peak evening hours.

The choice of test endpoint also affects how representative the result is:

• Common test endpoints (lightweight ones like generate_204) are often served through their own CDN, so latency to that specific endpoint from a given region can differ substantially from latency to the site you actually want to reach.
• Some exit nodes have routing specifically optimized for certain addresses. If the test endpoint happens to land on that optimized path, the number looks unusually good — but it reverts to normal the moment you visit a different target site.
• If the test endpoint is throttled or briefly unreachable from the node's network environment, it will show as a timeout even if that line otherwise works fine for every other site.

In other words, the latency number is a sample "for one specific target at one specific moment," not an average of how that node performs across the day and across every site. Relying on this single number alone isn't enough to judge real-world behavior.

Low latency doesn't mean high bandwidth

This is the point most people overlook: latency measures "how fast it responds," bandwidth measures "how much data it can push through." The two are governed by entirely different network characteristics — a low-latency node can easily have low bandwidth, and a high-latency node can have plenty of bandwidth to spare.

A simple analogy: latency is like how fast someone picks up the phone; bandwidth is how many simultaneous calls that phone line can carry. Picking up quickly doesn't mean the call quality is good — if the line's capacity is small, things still stutter and drop words once more people are on it. Translated to proxy nodes, common patterns include:

• Some nodes are specifically tuned to respond fast to dashboard test requests, but the exit server's outbound bandwidth is limited — the moment you start a large download or stream video, speed can't keep up.
• Nodes that are physically farther away naturally show higher latency (bounded by the physical speed-of-light limit), but if their outbound bandwidth is generous and the line is stable, sustained download speed can actually be better.
• The amount of jitter in the latency number (rather than its absolute value) is often a better indicator of line stability — a node hovering steadily around 80ms usually feels better than one bouncing between 30ms and 300ms.

A more realistic way to pick nodes

Since the latency number alone doesn't tell the whole story, here are a few approaches that give a more reliable read when actually choosing a node:

1. Set tolerance to a reasonable value

   Too small a tolerance causes constant switching over a few milliseconds of jitter, which hurts the experience rather than helping it; around 50ms is a good balance between responsiveness and stability.

2. Switch to a test endpoint closer to what you actually use

   If most of your traffic goes to a particular category of sites, point url at a static resource on one of those sites instead of a generic test endpoint, so the number reflects your actual usage pattern.

3. Watch the trend over time, not a single snapshot

   Pay attention to how the number changes across several refresh cycles — a node that stays consistently steady is generally better than one that's usually lower but spikes occasionally.

4. Confirm with an actual download or playback test

   Pick the top two or three nodes by latency and run a real download or video playback test on each; let the felt speed make the final call, with latency only used as an initial filter.

5. Separate "auto select" from "manually pinned"

   For light usage, an url-test group can handle selection automatically. For anything speed-sensitive, like large file transfers, manually pinning a node with already-verified bandwidth is usually the safer choice.

Put together, the real value of latency testing is quickly ruling out nodes that are clearly unreachable or too slow to respond, narrowing the field down to a handful of candidates. The bandwidth and stability that actually determine day-to-day experience still need a second pass grounded in real usage. Once you understand this mechanism, the millisecond number in the panel stops being the only thing you rely on when choosing a node.