Networking 12-minute read

How Clash Node Latency Tests Work: Why the Milliseconds Shown Don't Equal Real-World Speed

Learn what Clash latency numbers really measure, why low latency can still mean slow pages, and how to test real-world performance more accurately.

What latency numbers actually measure

The 38 ms, 126 ms, or 480 ms shown by a Clash client is usually neither a traditional ICMP ping nor a download-speed measurement. The client generally asks the Clash or mihomo core to access an HTTP or HTTPS test URL through a selected proxy node, then records the time from sending the request to receiving a valid response. Depending on the client, the button may be labeled “Latency Test,” “Speed Test,” or “Health Check,” but the goal is similar: verify that the node connects and estimate the round-trip time for a short request.

Common test endpoints return HTTP 204. A 204 response has no body and transfers very little data, making it suitable for repeated probes. https://www.gstatic.com/generate_204 and https://cp.cloudflare.com/generate_204 are examples. Because the response body is nearly empty, the result mainly reflects connection setup and request-response time; it cannot show how many MB/s a node can sustain when transferring a 100 MB file.

Steps a single HTTPS latency test may include

  1. Clash receives the test command from the client and selects a proxy node.
  2. The core resolves the node server address and establishes a TCP or other transport connection to the node entry point.
  3. It completes the handshake required by Shadowsocks, VMess, VLESS, Trojan, or another protocol.
  4. It connects to the test site through the node and completes the TCP and TLS handshakes with the destination.
  5. It sends an HTTP request and waits for the status code and response headers.
  6. The client converts the total elapsed time to milliseconds and displays it.

The exact timing boundaries depend on the client and core version. Some implementations create a new connection for every test, while some health checks may reuse part of the connection resources; some include DNS resolution, while others may use a DNS cache. As a result, two clients testing the same node can differ by 20 to 80 ms without anything being wrong. When assessing node health, compare results from the same device, client, and test URL.

Why a low-latency node can still be slow

Low latency means a short connection probe completed quickly, but page loads, software downloads, and video playback are also affected by throughput, packet loss, the route to the destination, and server load. A test request contains only a small response header, so even a node capped at 5 Mbps may complete a 204 request within 50 ms. During a real file download, the theoretical limit of 5 Mbps is about 0.625 MB/s, making the speed difference apparent over time.

Node bandwidth or shared-entry congestion

A proxy entry is typically shared by multiple users. Concurrent traffic between 8:00 and 11:00 p.m. may be much higher than in the morning. A node may show 45 ms when idle and still remain near 58 ms when busy, while download speed drops from 18 MB/s to 2.4 MB/s. Small requests can still clear the queue quickly, but high-volume transfers continuously compete for outbound bandwidth.

Packet loss and jitter are not shown directly

Clients often display only the most recent successful test, or one selected value from several results. Suppose ten consecutive results are 52, 54, 55, 53, 410, timeout, 61, 58, 390, and 57 ms. If the interface keeps only the final 57 ms, it hides substantial jitter and packet loss. A webpage's many concurrent requests may repeatedly trigger retransmissions, causing images to appear in batches and the page to pause occasionally.

The test site may use a different route from the real destination

A short route from the node to the test URL does not mean the route to a code host, video platform, or cloud drive will be equally good. The node may reach the test site over a local peering route in 35 ms, yet take a detour to the actual destination with a 900 ms time to first byte. A test URL represents only itself; it cannot replace testing the service you actually use.

Local network conditions and device load

Why a high-latency node can still stream video smoothly

Video playback depends on sustained throughput and a buffer; every segment does not need to return within a few dozen milliseconds. A node with 180 ms latency and a stable speed of 25 MB/s can usually fill the buffer faster than a node with 45 ms latency but only 2 MB/s. Once playback begins, higher latency has little effect on continuity as long as the download rate remains above the video's bitrate.

Take 4K video as an example. At an average bitrate of 25 Mbps, that is about 3.125 MB/s. A node that consistently delivers 12 MB/s has ample headroom for playback even at 220 ms latency. By contrast, a node with 30 ms latency whose evening speed fluctuates between 1.5 and 4 MB/s may frequently drain its buffer.

Interactive tasks and high-volume transfers prioritize different metrics

Use case More important metrics Typical behavior
Web browsing, online documents Latency, time to first byte, packet loss Low latency usually completes multiple small requests faster
Video playback Sustained throughput, jitter, available bandwidth Buffering can keep playback smooth even with higher latency
Large file downloads Sustained speed, egress limits, route stability The peak speed during the first few seconds does not represent the average
Remote terminals, cloud desktops Round-trip latency, jitter, packet loss The difference in interaction feedback between 80 ms and 250 ms is noticeable
Voice and real-time communications Latency, jitter, UDP availability Even with enough bandwidth, jitter can cause dropouts

How the test URL changes the result

The test endpoint's location, protocol, and response status all affect the number. An HTTPS endpoint generally includes the TLS handshake; an HTTP endpoint skips that layer. A test site close to the node's egress will produce a lower result, while an intercontinental or busy site will produce a higher one. If the test site is restricted by the target network, the test may time out even when the node itself is working normally.

Three criteria for choosing a test URL

Do not directly rank millisecond values obtained from two different URLs. For example, node A may reach a test site in Asia in 48 ms, while node B reaches a European test site in 130 ms; the figures are not a fair comparison. For batch testing, use the same URL, timeout, and approximately the same test time for every node.

How to configure url-test and health checks

The url-test proxy group in Clash and mihomo configurations periodically tests candidate nodes and selects the one with the currently lower latency. It is useful for automatic selection, but it is not a continuous download-speed test. interval controls the check interval, usually in seconds; tolerance reduces frequent switching when latency values are close.

proxy-groups:
  - name: Auto Select
    type: url-test
    use:
      - Airport Subscription
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

This configuration checks the nodes every 300 seconds. The “Auto Select” group will not switch immediately just because a new node is 10 ms faster; with tolerance: 80, it keeps the current node when the difference is small, reducing connection interruptions. For web browsing, a tolerance of 50 to 100 ms is generally more practical than chasing millisecond-level differences. During live meetings, a 10-second interval is also inadvisable because frequent checks and switches create unnecessary connection changes.

A proxy provider can also have its health check configured separately. The following snippet verifies every 600 seconds whether the nodes in the subscription are reachable:

proxy-providers:
  Airport Subscription:
    type: http
    path: ./providers/airport.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
      lazy: true

lazy: true reduces active checks when the relevant proxy provider is not in use; exact behavior depends on the core version. If the client manages the configuration through its interface, directly editing the runtime-generated YAML may be overwritten when the subscription updates. Prefer adding rules through the client's override or merge-configuration feature. In Clash Verge Rev 2.x, the usual path is “Settings” → “Subscription Settings” → select a configuration → “Edit Global Extension Configuration.” Then reload the subscription and inspect the active configuration.

A testing method closer to real-world experience

When choosing a node, split testing into “response speed,” “sustained throughput,” and “stability” instead of clicking a lightning-bolt button once. Keep the device, network, time period, and proxy mode consistent for every comparison. Mixing Wi-Fi with wired testing or system proxy mode with TUN mode makes the results incomparable.

Step 1: Repeat latency tests and use the median

  1. In Clash Verge Rev 2.x, go to “Proxies” → the target proxy group.
  2. Click the speed-test button in the upper-right corner of the proxy group and wait for all nodes to finish.
  3. Test each candidate node 5 to 10 times, with about 10 seconds between tests.
  4. Record the median, maximum value, and number of timeouts—not just the minimum.

One set of results is 68, 71, 69, 74, and 70 ms, giving a median of 70 ms with little variation. Another is 42, 45, 310, timeout, and 53 ms: its minimum is better, but its stability is worse. The first set is usually better for web browsing and remote interaction.

Step 2: Measure sustained downloads, not instant peaks

Choose a stable 100 MB to 500 MB test file from a source close to your actual use case, and download continuously for at least 30 seconds. Ignore the initial 2 to 3-second peak; record the speed at 10, 20, and 30 seconds. For example, node A has 46 ms latency with readings of 8.2, 7.9, and 7.8 MB/s; node B has 128 ms latency with readings of 30.5, 31.4, and 30.8 MB/s. Node B is clearly the better choice for downloads.

Speed tests use real traffic. On mobile or metered connections, reduce the file size and stop other downloads. The “Network” panel in browser developer tools shows request timing. In Chromium-based browsers, press F12, open “Network,” select the target request, and inspect the “Waiting for server response” and “Content download” phases under “Timing.”

Step 3: Test the services you actually use

Troubleshoot latency anomalies by network layer

All nodes become slower at the same time

Check the local network first. Stop cloud-drive synchronization and system updates, then test over Ethernet or 5 GHz Wi-Fi. If direct web browsing is also noticeably slower, the issue is more likely with the local broadband or mobile network or the router. Restarting Clash can rebuild proxy connections, but it cannot fix congestion on the carrier network.

Only one region becomes slower

If several nodes in the same region rise from about 80 ms to 300 ms at once, cross-border route changes or congestion at a regional entry point may be responsible. Temporarily try another region and test during both the daytime and evening peak. If performance recovers overnight and repeatedly degrades in the evening, congestion is a more likely explanation than a client configuration error.

The speed test times out, but webpages open

Try another test URL and verify that DNS mode is working correctly. With Fake-IP, the test domain first receives a reserved address, then Clash restores the domain during connection setup. If a rule incorrectly sends the test domain to a direct or reject policy, the test may fail. Check the destination domain, matched rule, and outbound node in the logs to confirm that the request actually used the proxy being tested.

Latency is normal, but some websites are slow

Check the logs to confirm that the website matched the expected proxy group. Clash rules are matched from top to bottom, and matching stops at the first hit. If an earlier DOMAIN-SUFFIX, GEOSITE, or IP-CIDR rule sends the destination to another node, the low latency shown in the proxy group is unrelated to the actual connection. Also check whether the browser has an independent proxy, HTTP/3, or secure DNS enabled, as these can send traffic along a different path.

Rank nodes using four numbers together

A single millisecond value is useful for quickly removing unavailable nodes, but not for choosing one node for every use case. A more reliable record includes median latency, maximum jitter, timeout rate, and sustained download speed. For example, node A measures 72 ms latency, 12 ms jitter, a 0% timeout rate, and 14 MB/s average speed; node B measures 41 ms, 280 ms, 20%, and 6 MB/s. Although node B has the lower minimum latency, node A is usually the better default.

Automatic proxy groups should also keep some tolerance. When two nodes measure 64 ms and 71 ms, a 7 ms difference usually does not justify the cost of switching existing connections. Switching is worthwhile only when the latency gap remains stable over time, or when throughput and real-world performance at the target site are also better. Use test results to narrow the field, then validate with real tasks; this is more reliable than ranking nodes by a single test.

Download Clash Client View Windows, macOS, and mobile versions