Clash Latency Tests Explained: Why Test Results Don’t Match Real-World Speeds

Latency measures a single request, not download bandwidth

In a Clash client’s proxy list, “test” usually means sending a request through a selected proxy to a specified URL and displaying the time reported by the core. Results are shown in milliseconds (ms). This is not a sustained download test or an ICMP ping to the proxy server. Even if the client labels the result “latency,” what it measures depends on the core and test settings.

This explains a common scenario: one node shows 80 ms but downloads a file at just 500 KB/s, while another shows 180 ms yet sustains 10 MB/s. The first handles a small request faster; the second has greater sustained throughput. These metrics describe different things, so one does not predict the other.

Units can also be misleading. Network bandwidth is usually measured in Mbps, while download tools often show MB/s. Using the decimal conversion, 100 Mbps has a theoretical maximum of about 12.5 MB/s, before protocol overhead. There is no conversion between 100 ms of latency and 100 Mbps of bandwidth.

How URL Test connections and handshakes work

For an HTTPS test URL, the request path can be broken down into several stages. This helps identify where problems may occur, but not every core version times or reports each stage separately. The displayed value should not be treated as the precise sum of fixed durations for these steps.

1. Resolve the node address. If the proxy server uses a hostname, its address must be resolved before connecting. The result may come from cache or require a new DNS lookup.
2. Connect to the proxy server. The client establishes a transport connection using the node’s protocol. TCP, UDP-based transports, and different encryption protocols have different setup steps.
3. Establish a route to the test target. The proxy’s exit must be able to reach the target site. Which side resolves the target hostname depends on the protocol and configuration.
4. Complete the target HTTPS exchange. This typically involves a TLS handshake with the target site and an HTTP request. Timing ends when the response condition defined by the core is met.

Timing boundaries, connection reuse, retry behavior, and HTTP methods can vary by core version. Don’t assume that “connection latency” shown by one client was measured using the same formula as another client’s result. For a meaningful comparison, use the same client, core, test URL, and network environment.

Why system ping is low but Clash latency is high

Pinging a proxy node measures only the ICMP round-trip time from your device to that server. URL Test also depends on proxy protocol handling, the route from the exit to the target site, and the target’s response. The server may also restrict ICMP, causing ping packets to be dropped while proxy requests work normally. Record these tests separately; they are not interchangeable.

The test URL determines which part of the network you measure

Common test URLs use endpoints that return a small HTTP 204 response, such as https://www.gstatic.com/generate_204. A 204 response has no body, so it transfers very little data and works well for frequent connectivity checks—but it reveals almost nothing about large-file transfer speeds.

The same exit may reach different domains through different CDNs or points of presence in different regions. A short route from a node to the test endpoint doesn’t mean it will also have a short route to a video service, code repository, or business application. It’s normal for node rankings to change when you switch test URLs.

Three things to look for in a test URL

• Small, consistent response. Prefer endpoints designed specifically for connectivity checks. Avoid homepages with images, login redirects, or frequently changing content.
• Use the same protocol. Test every node against the same HTTPS URL. HTTP and HTTPS involve different exchanges, so don’t mix them in the same ranking.
• Verify with real-world traffic. Use a consistent endpoint to shortlist nodes, then test them in the apps you actually use. Avoid repeatedly requesting URLs that contain login credentials or sensitive query parameters.

Also distinguish between three types of checks: a manual test next to a node, automatic tests by a url-test proxy group, and health checks for proxy-providers. Each may have its own URL, interval, and timeout. Changing one setting won’t necessarily change the test conditions elsewhere in the client.

mihomo url-test config and automatic node selection

A url-test proxy group automatically selects a member based on test results. The example below shows a group-level configuration; “Hong Kong-01” and “Japan-01” are sample node names. In your own config, member names must match the entries defined under proxies, or the references won’t work.

proxy-groups:
  - name: Auto Select
    type: url-test
    proxies:
      - Hong Kong-01
      - Japan-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

• interval: 300: Checks run every 300 seconds, not every 300 milliseconds.
• tolerance: 50: The switching tolerance, in milliseconds, helps prevent unnecessary node changes caused by small latency differences. It is not a timeout.
• lazy: true: Periodic tests may be skipped while the group is unused, reducing background requests. As a result, a group that hasn’t been used for a while may not show up-to-date latency.

Use the options supported by your current core version. Classic Clash and mihomo don’t support every field in the same way. Clients may also modify the final config through overrides or subscription converters, so check the config actually in use—not just the original subscription. For setup and configuration help, see the cross-platform guide.

Why a low-latency node may still download slowly

Bandwidth caps and shared congestion

A tiny HTTP response transfers so little data that it can return quickly even on a connection capped at 5 Mbps. Downloading a 1 GB file requires sustained bandwidth, which exposes exit-node caps, congestion on shared links, and server-side limits. If latency stays about the same but downloads slow down during peak hours, compare sustained throughput instead of repeatedly running latency tests.

Packet loss and retransmissions affect long connections

Occasional packet loss may not affect a brief test, but it can trigger retransmissions and congestion control during a long transfer. You may see speeds fluctuate sharply, start out normally, then drop. Check success rates across multiple requests and monitor the download itself—a single best-case latency result doesn’t show how stable a connection is.

Your traffic may not be using the tested node

Manually testing a node doesn’t mean your browser is using it. Rules may send the target domain to a different proxy group—or even DIRECT. The system proxy affects only apps that honor that setting; TUN mode coverage also depends on routing, exclusions, and client configuration. Check the client’s connection list to confirm the target domain, matched rule, proxy group, and node actually in use.

The download source or your device may be the bottleneck

A remote site may limit speeds by connection, account, or region. Wi-Fi interference, background syncing, and disk writes on your device can also affect results. Repeating the test with two different sources is usually more useful for troubleshooting than repeatedly switching nodes during the same download.

What a timeout means and how to troubleshoot it

A timeout means the test didn’t finish within the allotted time; it doesn’t confirm that your subscription is invalid. DNS lookup failures, an unreachable server, incorrect protocol settings, a restricted target site, or a slow network can all cause a test to fail. Some clients label several error types as timeouts, so check the logs for the specific cause.

1. Keep network conditions consistent. Pause bandwidth-heavy downloads, retest on the same Wi-Fi or wired connection, and note when the failure occurs.
2. Check whether one node or all nodes fail. If only one node fails, start by checking its details. If all nodes fail at once, check your local network, DNS, and the public test endpoint first.
3. Try a different test URL. Use another reliable endpoint with a small response. If only the original URL fails, that doesn’t prove the node is generally unavailable.
4. Check the error in the logs. DNS errors, connection refusals, TLS errors, and timeouts call for different fixes. For TLS issues, also check your system’s date and time.
5. Check where the timeout is configured. Manual tests, proxy groups, and provider health checks may each use different time limits. Increasing the value in one place won’t necessarily change the others.

For example, if the test timeout is 5 seconds, a request that takes 6 seconds will be marked as failed. Increasing it to 10 seconds may make the test show as successful, but it won’t improve the connection itself. A timeout only sets how long to wait; it doesn’t make the connection faster. If responses consistently take several seconds, investigate the network path instead of focusing on getting a success indicator.

Compare nodes under the same conditions

Here’s a repeatable process for evaluating nodes. The numbers are examples of how to record results, not measurements taken by this site. Keep the device, test URL, download source, and time window consistent, and change only the node between tests.

1. Start with short requests. Run URL Test five times per node, about 10 seconds apart. Record every result and the number of failures instead of keeping only the best one.
2. Then test sustained transfers. Choose a fixed download source that allows speed testing and monitor it for 30–60 seconds. Record speeds at the start and after they stabilize. Keep data usage in mind.
3. Confirm the actual exit node. Check the connection list to see which node the task is using. After changing proxy groups, start a new task; an existing connection may not switch immediately.
4. Test the apps you actually use. For video, check startup, seeking, and buffering; for websites, check initial load and continued browsing; for remote sessions, check input responsiveness and disconnections.
5. Test at different times. Compare at least one daytime and one evening window. Don’t treat results from a single minute as a measure of long-term quality.

In this example, Node A handles short requests faster, while Node B is better for large-file transfers. If two of the five tests time out, record that as “3/5 successful” rather than treating the average of the remaining three as the full result. For interactive apps, low and consistent latency matters most; for large downloads and high-bitrate video, sustained throughput and success rate matter too.

Choose a node based on the task at hand: use URL Test to rule out nodes that are clearly unreachable, then check the route and performance in the apps you actually use. Latency is one screening metric—not a speed score or proof that every site will work.