Deep Dive 11 min read

How Clash Latency Test Numbers Work: Why a 60ms Node Can Still Buffer Video

Learn how Clash latency tests really work: they measure the handshake round trip to a test URL, not bandwidth. See why low latency does not guarantee speed and how to evaluate nodes more realistically.

What Do Latency Test Numbers Actually Measure?

When you click a latency test in Clash, Clash Meta (mihomo), or a graphical client, the core typically makes the selected proxy node access a test URL and records how long it takes from request initiation to a valid response. A common target is a lightweight endpoint that returns HTTP 204, such as https://www.gstatic.com/generate_204. The 60ms shown in the interface means this small request completed quickly—not that the node can transfer 60 megabytes per second.

A test may include establishing the proxy connection, resolving the destination hostname, opening a TCP connection to the target server, the TLS handshake, and the HTTP request and response. Which stages are covered depends on the core version, protocol implementation, connection reuse, and test entry point. Some clients call the mihomo external control API to test a single node; url-test groups and proxy-provider health checks run periodically in the core. They all report milliseconds, but their timing and connection state may not be identical.

It Is Not Simply the Same as Network Round-Trip Time

The system's ping command usually tests network-layer round trips with ICMP echo packets, while a Clash latency test follows the proxy protocol and HTTP request path. A node may block ICMP yet proxy HTTPS normally; conversely, ICMP may be low while an overloaded proxy server is slow at authentication and encryption. So 35ms from command-line ping and 68ms in the client are not contradictory.

Why a 60ms Node Can Still Buffer Video

Video playback requires sustained throughput. At common bitrates, 1080p video may need a steady 5–10Mbps, while 4K content may need 20–40Mbps, with higher peaks. A latency test downloads only a tiny response and finishes in milliseconds, so it cannot show whether the node becomes throttled, loses packets, or congests after transferring tens of megabytes.

Insufficient Bandwidth: A Fast First Byte, Then a Bottleneck

A node may complete its handshake in 60ms, yet its shared egress may offer only 2Mbps during peak hours. A webpage needs only a few hundred KB to open and may feel responsive; once the video buffer keeps consuming data, the download rate falls behind playback and pauses become frequent. This is the classic combination of low latency and low throughput.

Conversely, a distant node with 180ms latency may steadily deliver 50Mbps. Playback starts slightly more slowly, but the video may run continuously once the buffer fills. Latency affects interactive wait time; throughput determines whether large files and video can keep arriving. They are different metrics.

Jitter and Packet Loss: Averages Hide Spikes

Five consecutive results might be 58ms, 61ms, 63ms, 420ms, and timeout, while the client shows only the latest or a filtered result. You may still see 61ms even though the path has serious jitter. TCP retransmits lost packets and shrinks its congestion window; UDP-based transports also incur higher recovery costs as line quality declines. For video chunks, this appears as speed that repeatedly surges and drops.

Do not judge jitter by the lowest value alone. If 10 consecutive tests are mostly between 55ms and 70ms with only one reaching 90ms, that node is usually more predictable than one with a 42ms minimum, a 680ms maximum, and two timeouts. Games, voice calls, and remote desktops are especially sensitive to spikes.

The Test Site and Video Site May Use Different Egress Paths

The test URL may hit a CDN close to the node, while the video service routes you to another region. Reaching the test site may take six hops, whereas reaching the video CDN may involve an intercontinental detour. Even if both targets use port 443, their autonomous systems, peering arrangements, and congestion points can be completely different.

Regional content access can change the serving edge as well. A US-labeled egress may quickly reach Google's test endpoint, yet the video service may identify it as a data-center network and assign it to a heavily loaded CDN. A slightly higher-latency residential egress may instead receive a better content edge. Sorting only by green numbers misses this difference.

Your Local Link and Client Mode Also Matter

How Test URLs, Caches, and Connection Reuse Change Results

A test endpoint should be small, unambiguous, and reliably reachable. A 204 response has no body, reducing the influence of download size. However, “less interference” does not mean “representative of every website.” Using URLs in different regions can make the same node differ by tens or even hundreds of milliseconds.

Use the Same Test URL for Meaningful Comparisons

Node A might measure 70ms against Google's 204 endpoint, while node B measures 25ms against a different domestic CDN. Those numbers cannot be ranked directly. The target servers differ, so the route destinations differ too. Batch tests should have every candidate access the same URL with the same timeout, preferably during the same time window.

If your main use is reaching development services outside China, keep a stable HTTPS 204 endpoint for initial screening. If your main use is a particular video platform, also test actual playback or that platform's static assets. Avoid health-check URLs that require login, return large pages, or redirect frequently; authentication, redirects, and page size will contaminate the data.

Caching Does Not Create More Bandwidth

DNS caching can skip a lookup, TLS session resumption can reduce handshake overhead, and HTTP connection reuse may avoid opening a new connection. It is common for later clicks to show lower latency than the first. This means the short-connection setup cost fell; it does not mean the node's egress capacity increased.

Client and core versions may handle connection pools, health checks, and concurrent tests differently. Testing dozens of nodes at once can also introduce variation from local thread scheduling, DNS queries, and the router's NAT table. For verification, test the target node individually every 2–5 seconds instead of repeatedly running a full batch.

A Timeout Is Not “Infinite Latency”

With a 5000ms timeout, a result of timeout only means the request did not finish within five seconds. The cause could be a failed node, a blocked test URL, DNS failure, a TLS error, or temporary packet loss. First switch to a known-reachable test URL, then determine whether the node itself is offline.

How to Read url-test and Health Checks in mihomo

The url-test policy group periodically checks the nodes it contains and tends to select an available option with relatively low current latency. It is useful for automatic selection, but it is not a real-time bandwidth scheduler. If a node returns 55ms during a health check and becomes congested during peak hours, the core will not immediately know that its throughput has declined just because video playback slows.

proxy-groups:
  - name: AUTO
    type: url-test
    use:
      - airport-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

proxy-providers:
  airport-main:
    type: http
    path: ./providers/airport-main.yaml
    url: https://example.net/subscription.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300
      timeout: 5000
      lazy: true
      expected-status: 204

Here, interval: 300 means checking every 300 seconds, while timeout: 5000 sets the timeout for one health check to 5000ms. tolerance: 50 helps prevent frequent switching when latency is close: when the current node differs from a candidate by only a few dozen milliseconds, keeping existing connections is usually steadier than switching back and forth. lazy: true reduces unnecessary checks when the policy group is not in use.

Do not reduce the interval to 5 seconds. If a provider has 80 nodes, probing all of them every five seconds creates a constant stream of small requests and may trigger server-side rate limits. For everyday desktop use, start at 300 seconds. If routes change rapidly, try 60–120 seconds and then watch the logs and resource usage.

Recheck a Single Node Through the External Control API

A common mihomo external control listen address is 127.0.0.1:9090. If an access key is configured, you can run a latency test against a specific node. The node name and test URL must be URL-encoded first.

curl -H "Authorization: Bearer local-secret" "http://127.0.0.1:9090/proxies/HK-A-01/delay?timeout=5000&url=https%3A%2F%2Fwww.gstatic.com%2Fgenerate_204"

Do not expose port 9090 directly to the public internet just to enable remote viewing. On a desktop, keep it listening on the loopback address. For LAN control, set an access key and use the system firewall to restrict source addresses. Also distinguish the proxy ports: 7890 is commonly the mixed-port, while 9090 is the control API; they serve different purposes.

A Node-Selection Method That Better Matches Real-World Use

A reliable selection process is not about finding the lowest number; it is about screening in layers. Use latency and availability to remove obvious failures, then test sustained throughput, jitter, and the target service, and finally factor in traffic multipliers and region. You do not need to max out every node—just cover the metrics that reflect your actual use.

Step 1: Run Consecutive Tests, Not a Single-Run Contest

  1. Use the same HTTPS test URL and set the timeout to 5000ms.
  2. Test candidate nodes 5–10 times in a row, with at least two seconds between tests.
  3. Record the median, highest value, and number of timeouts—not just the minimum.
  4. Remove nodes with repeated timeouts, swings of several hundred milliseconds, or frequent disconnects.

For example, node A may stay between 75ms and 88ms, while node B has a 48ms minimum but otherwise ranges from 60ms to 530ms. Both may work for web browsing, but A is the better choice for meetings and games. A stable median with few outliers is usually more meaningful than an occasional record low.

Step 2: Run a 20–30-Second Sustained Download

Choose a trusted speed-test site or large-file source and download through the current policy group for 20–30 seconds. Watch whether the speed stays stable, not just its instantaneous peak. A node that starts at 18MB/s and drops to 700KB/s after five seconds has good burst capacity but poor sustained performance; another that holds 6MB/s is often less troublesome for HD video.

Testing consumes subscription traffic. With a 2.0x multiplier, downloading 500MB through a node may count as 1GB. When traffic is limited, shorten the test or use a smaller file; there is no need to run a full speed test on dozens of nodes.

Step 3: Test the Actual Service

Step 4: Confirm Clash Rules Select the Same Node

Latency tests target a node or policy group, while actual website traffic is first matched against rules. If DOMAIN-SUFFIX,example-video.com,MEDIA matches the MEDIA group but you manually tested the PROXY group, even an impressive number cannot explain video performance.

rules:
  - DOMAIN-SUFFIX,example-video.com,MEDIA
  - DOMAIN-SUFFIX,example-cdn.net,MEDIA
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

During troubleshooting, open the client's connections page, start playback, and filter by domain to see the matched rule, policy group, and final node. In a typical desktop client, the path is usually “Connections” → “Search domain” → “Expand connection details”; configuration changes are under “Profiles” → “Edit current profile.” Menu names vary slightly between clients, but verify the same three items: target domain, matched rule, and actual outbound.

What Order Should You Follow When Latency Looks Wrong?

Break the problem into four layers: device, local network, node, and destination site. Do not reinstall the client as soon as you see a red number. The sequence below narrows the scope quickly.

  1. Check the local network: Test once over Ethernet and once over 5GHz Wi-Fi to rule out wireless congestion.
  2. Switch the test URL: If the original endpoint times out every time, cross-check with another stable 204 endpoint.
  3. Compare DIRECT: If direct access to the test site is also slow, the issue may be with your local ISP or the destination site.
  4. Check core logs: Search for errors such as timeout, DNS, TLS, and connection reset.
  5. Verify system time: Clock drift can make TLS certificate validation fail, which may look like an unavailable node.
  6. Temporarily stop concurrent downloads: Cloud drives, system updates, and sync tools may saturate upload or download capacity.
  7. Check TUN settings: Only when TUN mode behaves abnormally, test system-proxy mode and compare the results.

If every node rises from 80ms to 800ms at once, check the local network and the subscription service entry point first. If only one region is affected, the problem is usually with that region's route or egress. If latency is normal but a specific website is slow, investigate rules, DNS, the destination CDN, and regional content access.

Conclusion: Put Latency in Its Proper Place

Clash latency tests are best at answering two questions: whether a node can currently reach a test URL through the proxy, and roughly how quickly a short request completes. They are useful for availability checks and first-pass ranking, but they cannot predict bandwidth, video quality, game packet loss, or peak-hour stability on their own.

When you see 60ms, read it as “the short request responded quickly,” not “this node is definitely fast.” Also check variation across repeated tests, 20–30 seconds of sustained throughput, actual service performance, and the rule that was matched. Latency, bandwidth, jitter, packet loss, region, traffic multiplier, and protocol all shape the experience; no single number tells the whole story.

Keep Checking Your Clash Nodes

Install a client suited to your current platform, then follow the guide to import your subscription and verify rule matching and DNS settings.

Go to Downloads Read the Guide
Download Clash