How Clash Latency Tests Work: Why the Number on Screen Doesn’t Equal Real-World Performance

The latency number in Clash clients is often treated as a ranking of node quality, but it describes only one specific probe. It reflects the chosen test URL, the current network, DNS state, and route load at that moment. It is not the same as a page’s full load time, nor does it directly represent download speed, video stability, or long-lived connection quality. Once you understand how the test works, latency is still useful—provided it is interpreted within the right limits.

What does a latency test measure?

Clash, Clash Meta (mihomo), and their graphical clients generally perform health checks against an HTTP or HTTPS URL. The client sends the test request through the selected proxy node, waits for an acceptable response from the target, and displays the elapsed time in milliseconds. The exact test URL, timeout, and implementation details depend on the client or configuration, so different clients may report different values for the same node.

This is not an ICMP Ping in the traditional sense. The system ping command usually sends ICMP Echo packets, whereas a proxy latency test establishes a TCP connection, and an HTTPS test also performs a TLS handshake. If the node uses WebSocket, gRPC, QUIC, or another transport, the access path itself may add more handshakes. The two tests use different protocols, ports, routes, and server-side processing, so their results cannot be compared directly.

Stages a single HTTPS probe may include

1. Resolve the test domain, or read an existing DNS cache entry.
2. Connect from the local device to the proxy node and complete the handshake required by its protocol.
3. Have the proxy connect to the test target’s IP address.
4. Complete the target site’s TCP and TLS negotiations.
5. Send the HTTP request and wait for the response headers or specified content.
6. The core records the elapsed time, then passes it through the control interface for the client to display.

Not every probe runs through every stage in full. DNS caching, TLS session resumption, connection pools, and client implementation details can shorten later tests. A high first result followed by a sharp drop on the second is commonly caused by cache and connection warm-up—not a sudden improvement in the node’s route.

The test target determines which path you observe

If the test URL is hosted in a data center close to the node’s exit, the result mainly reflects the path from your device to the node and from the node to that data center. The real destination may be in another country, on another carrier, or behind a different content delivery network region, making the second half of the route completely different. A node can therefore respond quickly to the test URL yet remain slow for a particular website.

Why does the same node produce different results?

Network latency is not a fixed property. It is the combined state of multiple links at a particular moment. Queuing anywhere across the home network, access carrier, interconnection points, node ingress, node egress, or test server can change the result. Comparing only the lowest value from a single click exaggerates random variation.

Local wireless network and access link

Weak Wi-Fi, same-channel interference, background uploads, and router load can all add waiting time. When upstream bandwidth is nearly saturated, the router’s buffer can fill with queued packets, causing even a lightweight test to rise from tens of milliseconds to several hundred. Switching proxy nodes usually will not help because the congestion occurs before traffic reaches the proxy.

Pause downloads, cloud-drive syncing, and video uploads, then repeat the tests. If every node improves together and rises again when background tasks resume, check the local network first. When possible, run one comparison over a wired connection to rule out some wireless interference.

DNS cache and resolution path

The first resolution of a test domain takes extra time. In fake-ip mode, the core maintains a mapping between domains and virtual addresses, then restores the destination domain from the connection. With redir-host or modes that return the real address directly, the resolution path is different. Upstream DNS response time, cache hits, and whether DNS requests go through the proxy all affect the first probe.

Keep in mind that whether the displayed time includes DNS depends on the core version, test interface, and how the client invokes it. When the implementation is unknown, treat DNS as a potential variable rather than inferring the exact duration of one stage from a single number.

Connection reuse and warm-up effects

During consecutive tests, the underlying layer may reuse an existing connection or take advantage of system caches, TLS session tickets, and already-resolved addresses. A later test skips some setup work and therefore reports a lower value. Conversely, if the client forces a new connection, the result is closer to the startup cost of a fresh visit—but it still does not represent the multiple domains and concurrent requests used by a webpage.

Route congestion and jitter

Latency can vary periodically during evening peaks, inter-carrier congestion, or increased node egress load. Suppose five results are 65, 68, 210, 72, and 190 ms. Looking only at the minimum makes the route seem fast, while looking only at the average can hide how often spikes occur. A better approach is to record the median, maximum, and number of timeouts together.

Why low latency does not mean faster access

Web performance is determined by several stages. A latency test usually contacts one lightweight URL, while a modern webpage loads the main document, scripts, stylesheets, images, APIs, and third-party resources. These resources may be spread across multiple domains and routed through different policies. One successful test request cannot represent the page’s entire connection graph.

Bandwidth and latency are different metrics

Latency measures how long a request takes to make a round trip; bandwidth measures how much data can be transferred per unit of time. A node with 40 ms latency but limited egress bandwidth may open a lightweight page quickly yet download large files slowly. A stable node with 90 ms latency and ample bandwidth may respond slightly later but work better for HD video and large downloads.

Download speed is also affected by TCP congestion control, receive-window size, retransmissions caused by packet loss, and server-side throttling. Even a high-bandwidth route may fail to reach its expected throughput when persistent packet loss causes repeated retransmissions. The latency value shown in the interface usually does not expose this information directly.

Why jitter matters more than the single lowest result for real-time tasks

Voice calls, remote desktops, and interactive connections care more about latency consistency. If results swing between 50 and 300 ms, input response and audio playback can still become choppy even when the minimum is excellent. By comparison, a route that stays near 90 ms is often easier to use predictably.

A standard latency test is not the same as a rigorous packet-loss test. A timeout can indicate a serious problem, but a small amount of packet loss may appear only as an occasional spike. To analyze real-time workloads, add continuous monitoring and combine system network tools, application logs, and actual sessions instead of relying on one number in the client card.

Rule-based routing can change the actual egress

Clash matches requests against rules from top to bottom. Testing a strategy group uses its currently selected node, but the actual website may match another strategy group, a direct-connection rule, or a catch-all rule. For example, the main domain may use the proxy while its static-asset domain uses a direct connection, so page performance depends on multiple paths.

During troubleshooting, open the connection list or core logs to confirm which rule matched the target domain, which strategy group was selected, and which node was ultimately used. Repeatedly testing from the strategy-group page cannot verify that the rules send real traffic through the same egress.

TUN mode does not automatically reduce route latency

TUN mode takes over more system traffic and passes IP packets to the core for processing. It can cover applications that ignore system proxy settings, but it does not shorten the physical route. With TUN enabled, DNS interception, routing rules, MTU, and system firewall settings become part of the data path. An unsuitable configuration can instead make some websites slow, prevent connections from being established, or cause large-packet transfer problems.

When comparing the system proxy with TUN mode, keep the node, rules, test target, and network environment the same. If only TUN mode is affected, check DNS interception, route exclusions, IPv6 behavior, and MTU instead of immediately assuming that node quality has changed.

How url-test, fallback, and manual strategy groups use latency

The strategy-group type in a Clash configuration determines how health-check results affect selection. A manual select group only provides candidates; it does not switch automatically just because another node has lower latency. A url-test group periodically tests a specified URL and tends to choose the lowest-latency available node. A fallback group focuses more on availability, usually selecting the first candidate in configuration order that passes the check rather than simply chasing the lowest millisecond value.

proxy-groups:
  - name: AUTO
    type: url-test
    proxies:
      - NODE-A
      - NODE-B
      - NODE-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: BACKUP
    type: fallback
    proxies:
      - NODE-A
      - NODE-B
    url: https://www.gstatic.com/generate_204
    interval: 300

interval controls the interval between periodic checks. An interval that is too short increases requests to nodes and test targets and makes the strategy more sensitive to brief fluctuations; an interval that is too long may miss route changes. For everyday networks, start with a few-minute interval and adjust it based on node stability.

tolerance helps prevent url-test from switching repeatedly between nodes with similar latency. Implementations may differ across core versions, but the purpose is the same: when candidate nodes are close, keep the current selection and avoid changing egress for every minor fluctuation. Long-lived connections, login sessions, and downloads generally benefit from this stability.

When lazy is enabled, the core can reduce active checks while a strategy group is not in use. This lowers idle testing overhead, but a group that has been unused for a long time may need to wait for a new round of results when reactivated. The client’s Test Now button usually starts a check immediately and should not be confused with background periodic checks.

Build a reproducible node testing method

Reliable comparisons require controlled variables. If you change the node, DNS mode, TUN settings, and test URL at the same time, it becomes difficult to tell what caused the difference. A better approach is to keep the environment fixed and record results in stages.

1. Keep the local connection consistent. Test on the same device and the same Wi-Fi or wired network, with high-volume uploads, downloads, and system updates paused.
2. Confirm that the subscription is up to date. Check node names, protocol parameters, and strategy-group references so you do not test entries that have expired or been removed from the subscription.
3. Keep the test target consistent. Run one round with the client’s default URL, then compare it with a stable URL relevant to the region of your actual workload.
4. Repeat; don’t rapid-fire clicks. Test each node several times, leave a reasonable gap between tests, and record the median, range, and number of timeouts.
5. Check the actual rules. Visit the target website and inspect the connection list to confirm that the domain, rule, strategy group, and final node match expectations.
6. Include real workloads. Observe initial page loads, video buffering, large-file downloads, or remote connections separately instead of using one test to represent every scenario.
7. Retest at different times. Record one round during your usual usage period and another during the evening peak to identify periodic congestion.

There is no need for laboratory-grade precision when recording results. A simple table is enough: node name, test time, three to five latency readings, timeout count, first-load experience on the target website, and sustained download speed. After several days, you can usually distinguish stable nodes, nodes that perform well only during quiet periods, and nodes better suited to specific destination routes.

Why prioritize the median?

An average can be pulled upward by one exceptionally high result, while the minimum is overly optimistic. Sort five results and take the middle value to reduce the effect of an occasional spike. For example, the median of 62, 64, 66, 70, and 420 ms is 66 ms, which better reflects most requests; the 420 ms result should still be retained as a jitter warning rather than discarded.

If the medians of several nodes differ by only a few tens of milliseconds, compare stability, timeout counts, and real-target performance first. For ordinary webpages, that gap is often smaller than the variation caused by DNS, page-script execution, and server response time.

Troubleshooting abnormal latency and widespread timeouts

When the interface shows timeouts, failures, or unusually high latency, first determine whether the issue affects one node, all nodes, or only a particular test URL. Identifying the scope is more important than changing configuration immediately.

Only one node is affected

• Check whether the subscription was recently updated and whether the node protocol, port, transport path, and server name are complete.
• Review the core logs for handshake failures, connection refusals, timeouts, or certificate-related messages.
• Confirm that the node has not been excluded by duplicate strategy-group names, same-name overrides, or provider filtering rules.
• Switch to another node from the same subscription to determine whether the problem is a single entry failure or a wider issue in the server region.

All nodes are affected

• First confirm that the device is connected to the internet and that the system clock is accurate.
• Pause tasks using upstream bandwidth to rule out local bufferbloat.
• Check whether the test URL is reachable directly and whether it is redirecting, rate-limiting, or blocked by region.
• Confirm that the upstream DNS service is available, paying particular attention to DNS interception and firewall permissions in TUN mode.
• Restart the core before testing again; refreshing the interface alone may leave the core in an unrecovered state.

Latency tests pass, but the target website fails

Start with the target connection. Check which rule and egress it matched, and whether the target domain resolves to an abnormal address. If necessary, compare system proxy and TUN mode. If only images or APIs are slow, inspect the separate domains used by those resources. A healthy test URL proves only that probe path works; it does not prove that every target path is healthy.

Choose nodes by use case

There is no universal lowest-latency threshold for node selection. For reading articles and working with documents, stability and correct rule matching usually matter more than a difference of a few dozen milliseconds. Real-time voice, cloud gaming, and remote desktops prioritize low jitter and low packet loss, while video and large downloads need sustained throughput and fewer retransmissions.

Web browsing

Focus on the first connection, DNS stability, and the route to the target site. Among candidates with similar latency, choose the one with fewer timeouts.

Real-time interaction

Focus on sustained latency, jitter, and packet loss. A consistently second-best latency is usually better than a route that occasionally achieves the lowest result.

Video and downloads

Focus on sustained bandwidth, evening congestion, and connection interruptions. A lightweight health check is useful only as an availability reference.

Multi-policy routing

Verify the strategy group and rules for each workload separately. Do not use the result of one automatic selection group to represent every egress.

For everyday configurations, keep one manual strategy group and one automatic test group. The automatic group provides a basic choice among available nodes, while the manual group can pin important sessions or handle differences between destination paths. If the automatic group switches too often, increase the tolerance or lengthen the check interval. If recovery after a node failure is too slow, shorten the interval to find a better balance.

Treat the latency number as a diagnostic signal, not a verdict on quality. First confirm what is being tested and which path it follows, then review repeated results, and finally validate them with real workloads. This lets you use the health-check capabilities of Clash and mihomo without constantly switching nodes based on one low reading and disrupting long-lived connections, login sessions, or overall consistency.