Clash Latency Testing Explained: Why Speed Test Numbers Don’t Equal Real-World Performance

In Clash or mihomo proxy groups, a latency figure usually appears beside each node. It is useful for quick sorting, but it does not directly represent webpage load times, video buffering, or long-connection stability. That is because a “latency test” measures one stage of a request from your device to a particular test target, while real traffic also involves DNS resolution, proxy handshakes, TLS negotiation, server processing, and content transfer.

To interpret test results, first distinguish the test method, then check whether the target resembles the service you actually use. Clash latency displays may come from node health checks, URL Test, or a client’s custom test; implementation details can also vary by client, core version, and configuration file. When you see 80 ms and 120 ms, do not choose the former on numbers alone. Consider jitter, packet loss, exit region, rule matches, and the target server’s response time.

What Does the Speed Test Actually Measure?

A proxy node latency test usually does not download a complete webpage. Instead, it sends a relatively lightweight request to a specified address. The process may include connecting to the proxy server, completing the proxy protocol handshake, and then requesting the test URL. The displayed millisecond value depends on how the client measures time: some implementations count TCP connection setup, others count the time until an HTTP response arrives, while some use health-check results provided by the core.

TCP Latency vs. HTTP Latency

TCP latency focuses on how quickly a transport-layer connection can be established. The client sends a SYN to the target address, the server returns a SYN-ACK, and data transfer can continue once the connection is complete. This stage mainly reflects the network path and connection setup, and usually excludes full webpage processing time.

An HTTP test sends a request over the connection and waits for the target to return an HTTP response. Results are affected by server load, reverse-proxy queues, TLS settings, redirects, and the speed at which the response is generated. HTTP results are therefore often closer to the experience of visiting a site than a simple TCP handshake, but they still represent only one fixed target.

With HTTPS, the first visit may also include a TLS handshake. When connection reuse is enabled, later requests can reuse an existing connection and avoid part of the setup cost. As a result, the same node may show different timings when opening a page for the first time versus refreshing it repeatedly; whether the test tool reuses connections also changes what the number means.

The Test Target Defines the Limits of the Result

A test URL is not an absolute measure of network quality. The target’s geographic distance from the node’s exit, carrier interconnection quality, server load, and CDN routing all affect the result. A node that is fast to the test site is not necessarily fast to the service you are using. If the test target is in one region while the actual content is served by a CDN in another, a substantial difference is perfectly normal.

Proxy rules also determine whether a request actually passes through the target node. If the test address matches DIRECT, the displayed result may represent a local direct-connection path. Only a request matching a proxy group passes through the node currently selected by that group. When troubleshooting, check connection details or rule-match logs first to confirm that the test traffic is using the intended policy group.

URL Test, Connectivity Checks, and Real-World Access

URL Test is primarily used to compare how quickly multiple nodes respond to the same URL and select a lower-latency node based on the result. It works well for an initial screening when many nodes are available and can provide periodic input for automatic-selection policy groups. It is not a bandwidth test, nor is it an overall score for every website.

Connectivity check: answers only whether the target can be reached. The result is usually success or failure, with little timing information.
TCP test: focuses on connection setup speed and is useful for observing the basic path response, but it cannot show how quickly an HTTP service processes requests.
URL Test: sends a request to a fixed URL and compares response times. Results depend on the target site’s condition and the request method.
Real-world access: includes DNS, rule matching, the proxy protocol, TLS, page assets, API requests, and content transfer. The path is longer and has more variables.

For example, a node with a 70 ms URL Test result may perform poorly when loading a large webpage because the page contains resources from multiple domains, some assigned to a distant CDN. Conversely, a node showing 110 ms may deliver a smoother first render and more consistent follow-up requests if its exit region is closer to the target service and the connection remains stable. For video, remote terminals, or real-time communication, stability is usually more important than a 40 ms difference in a single test.

Why Does the Same Node Show Different Readings?

Node latency is not constant. Wi-Fi interference, a saturated local upload, evening congestion at the carrier, proxy-server concurrency, and momentary load on the target URL can all cause variation. When tests are close together, a connection may be reused; after a longer interval, it may have closed, making a new handshake take longer. Running several tests at once can also create extra queues on your device or the node.

The client’s test interval matters too. An interval that is too short creates frequent requests, while one that is too long cannot detect changes in node health promptly. When an automatic-selection group switches nodes based on test results, the switch itself can interrupt some connections. For downloads and login sessions, frequently switching may be less suitable than keeping one moderately fast but stable node.

How Jitter, Packet Loss, and Throughput Affect Performance

Average latency describes the central level of a sample set, but not whether every request is consistent. Jitter is the degree to which latency changes over time. For example, consecutive results of 82, 85, 83, 210, and 91 ms may produce an acceptable average, but the sudden 210 ms delay can still disrupt interaction. Voice calls, gaming, remote desktops, and continuous API requests are especially sensitive to jitter.

Packet loss means that a packet does not arrive within the expected time, or that its response never returns. TCP ensures reliable delivery through retransmission, but retransmissions add waiting time and may trigger congestion control, reducing the sending rate. A small amount of loss may not appear in one short URL Test, yet accumulate into stuttering during large downloads, long-lived connections, and continuous video playback.

Throughput is the amount of data that can be transferred per unit of time. It is affected by the node’s outbound bandwidth, the number of shared users, congestion control, protocol overhead, and server-side limits. A low-latency node does not necessarily offer high throughput; it may complete a small request quickly but slow down during a large download. Conversely, a node with slightly higher latency but ample bandwidth may be better for system updates, file synchronization, and high-bitrate video.

Metric	What it primarily reflects	Useful for evaluating	Cannot prove on its own
TCP latency	Response along the connection setup path	Basic connection speed	Full webpage loading speed
URL Test	Request response from a fixed URL	Initial cross-node screening	Performance across all target sites
Jitter	Latency variation over time	Real-time interaction stability	Available bandwidth
Packet loss	Reliability of data transfer	Risks to long-lived connections and sustained transfers	The exact duration of a single request
Throughput	Sustained transfer capacity	Downloads, video, and synchronization tasks	Time to first byte for a small request

Diagnosing Speed-Test Differences Through Clash Configuration and Rules

Different applications on the same device may use different paths because they match different rules. Rules such as DOMAIN, DOMAIN-SUFFIX, IP-CIDR, GEOIP, and MATCH in a configuration file are evaluated in order, ultimately sending the request to DIRECT, a proxy group, or another policy. If you look only at the proxy-group name without confirming which rule the target domain actually matched, it is easy to mistake direct-connection speed for proxy speed.

DNS also affects both testing and real-world access. Domain resolution may happen locally or through the proxy, depending on the DNS mode in the configuration. Resolution results influence CDN routing, and a mismatch between the resolver’s location and the proxy exit can produce less-than-ideal addresses. Fake-IP mode assigns virtual addresses to domains, then associates the original domain during the subsequent connection phase; it changes the DNS-resolution and rule-matching process, not the underlying network latency.

TUN mode routes more system traffic through a virtual network interface, making it useful for applications that do not follow system proxy settings. After TUN is enabled, whether traffic uses the proxy still depends on routing, DNS, and rule configuration. If you test only in a browser while the issue affects system services or other applications, the browser’s URL Test cannot represent that traffic. During troubleshooting, record the application, domain, target IP, matched rule, and actual policy group.

A Reproducible Testing Sequence

Keep the test device, network connection, and test time consistent, and pause bandwidth-heavy sync or download tasks.
Confirm that the test URL is reachable, and record the client’s test method, test interval, and target address.
Choose 3 to 5 candidate nodes and run several rounds of tests. Record not only the lowest value, but also the median, highest value, and number of failures.
Visit commonly used services separately, and observe first-render wait time, connection interruptions, failed page resources, and sustained download speed.
Check rule matches and DNS results in the logs to confirm that the items being compared are using the same proxy path.
Repeat the tests at different times. If fluctuations become obvious during evening peak hours, prioritize stability and fallback strategies instead of continuing to chase the lowest single reading.

Suggested test record:
Node A | URL Test median 86 ms | highest 142 ms | failures 0/10 | stable downloads
Node B | URL Test median 63 ms | highest 310 ms | failures 2/10 | noticeable fluctuation
Node C | URL Test median 118 ms | highest 135 ms | failures 0/10 | high throughput

How to Choose a Node for Your Use Case

Web browsing usually depends on DNS completion, TLS setup, and time to first byte. In this case, prioritize a node with moderate latency, low jitter, and consistent rule matching. If page resources come from multiple domains, also make sure those domains are not being assigned to unsuitable policy groups.

Video playback relies more on sustained throughput and the path to the content CDN. Latency may affect initial buffering, but once playback is stable, bandwidth and packet loss matter more. Observe a period of continuous downloading instead of sorting nodes only by the millisecond value shown on their cards.

Online gaming and remote desktops need low, stable round-trip times and are sensitive to jitter and packet loss. A node in a region close to the target server often helps, but carrier interconnection quality matters just as much. When latency spikes briefly, check for local network queues, Wi-Fi signal changes, or background uploads before concluding that the node has failed.

File downloads and system updates prioritize throughput, connection persistence, and server-side limits. An extra few dozen milliseconds usually has little effect on large-file transfers; frequent node switching may instead force the task to establish connections again. Use a fixed policy group and begin a long transfer only after confirming that the node remains stable.

For automatic-selection policy groups, treat URL Test as one screening condition rather than the sole decision-maker. A sensible configuration should also consider node availability, regional requirements, multiplier rules, service compatibility, and fallback order. Automatic switching is meant to reduce manual maintenance, not make all traffic chase the lowest number forever.

Common Misinterpretations and Troubleshooting Conclusions

“The lowest latency is always the fastest”

The lowest latency only means that one test received a quick response. If a node has insufficient bandwidth, frequent packet loss, or a poor path to the target site, real downloads and page loads may still be slow. Evaluate the median, variation range, failure count, and real-world service tests together.

“A successful speed test means every website will work”

A responsive test target proves only that this particular test path was available at that moment. Different domains may match different rules, DNS results, and exit paths, and may also be affected by regional restrictions or server-side policies. When one site behaves abnormally, first inspect that domain’s rule match and connection logs.

“Turning on TUN automatically fixes latency problems”

TUN addresses traffic capture for applications that cannot use the system proxy; it does not change physical distance, node bandwidth, or target-server load. After enabling it, check system routes, DNS handling, permissions, and conflicts with existing VPNs. When configured correctly, it can make the traffic path more complete; when misconfigured, it can also make troubleshooting more complex.

“One test is enough to choose a node”

A single result can be affected by momentary congestion and the target site’s condition. Run multiple rounds and verify the result in the actual use case. If a node has an attractive minimum but a much higher maximum and failure count, treat it as unstable rather than making it the first choice.

In short, the latency number in Clash is a useful starting observation, not a performance score. Confirm the test method and target first, then inspect rules, DNS, and the proxy path, and finally assess jitter, packet loss, throughput, and real-world services together. With reproducible records, node selection becomes an explainable, reviewable network-diagnostics process instead of simply “looking at one millisecond number.”