Clash Latency Test: Why Low Ping Doesn’t Always Mean Faster Downloads

Understand latency, throughput, and stability

Use latency to rule out clearly unusable nodes, then judge speed with the apps and sites you actually use. The 80 ms shown in a Clash list usually measures the time for one probe—not download bandwidth, and it doesn’t guarantee smooth video playback. If Node A reports 80 ms and Node B reports 160 ms, that doesn’t mean A downloads twice as fast.

Think of “speed” as three separate metrics. For web browsing, look at connection setup and time to first byte. For downloads, look at sustained throughput. Video calls and gaming also depend on packet loss, jitter, and the UDP path in use. A single HTTP probe covers only a small part of the picture.

For example, a sustained download rate of 10 MiB/s is about 83.9 Mbit/s; MiB here means 1024² bytes. ISPs usually advertise connection speeds in Mbit/s, while download tools may show MB/s or MiB/s. Check the units before comparing figures—otherwise, an eightfold difference can look like a network problem.

How Clash latency tests route requests

First, check which kind of test your client runs. Many Clash clients use the core’s URL latency test: they send a request to a test URL through a selected node and measure how long it takes to complete. This isn’t simply an ICMP ping to the node server, nor is it a sustained large-file download.

What happens during a URL test

1. The core prepares the node connection and, if needed, resolves the node server’s hostname.
2. It connects to the proxy server and completes the relevant proxy protocol handshake.
3. It accesses the test site through the proxy; with HTTPS, this also involves a TLS handshake.
4. The test response is received, then the core or client displays the result.

The timing boundaries, connection reuse, and result display depend on the core and client version. Don’t assume every millisecond figure shown by every client represents a full page load. Caching, existing connections, and whether the test target requires an additional DNS lookup can also affect the result.

To check, open the client’s connection log and reload the page you want to test. Verify the destination domain, matched rule, policy chain, and outbound node before comparing latency. TUN changes how traffic is intercepted; it doesn’t add node bandwidth or turn an HTTP test into a UDP performance test.

Use the same test URL and timeout

Before comparing nodes, keep the test URL, network, and test time consistent. A common test URL, https://www.gstatic.com/generate_204, returns a tiny HTTP 204 response and works well for checking short-request connectivity. Its small response is exactly why it can’t measure large-file download performance.

A test URL isn’t a neutral “internet speed benchmark.” The target’s location, CDN routing, peering, and access restrictions all affect the result. One route might reach this URL in 90 ms but take 300 ms to reach the site you actually use; there’s no contradiction.

Compare nodes under the same conditions

• Stay on the same Wi-Fi or wired network, and pause system updates and cloud syncing.
• Choose two candidate nodes and use the same HTTPS test URL for both.
• Run 10 tests per node, spaced about 5 seconds apart. Record the number of successes and median latency.
• Set the manual test timeout to 5000 ms for both; if the client doesn’t let you change it, note the actual default.
• Then check the sites you actually use. Don’t mix results from a different test URL into the original comparison.

A timeout is the maximum wait, not a speed target. A timeout result means only that the request didn’t finish within the limit or that the test hit an error during connection, DNS resolution, TLS, or another step. Changing the limit from 3000 ms to 10000 ms and getting a result shows only that the request may succeed if you wait longer—not that the connection got faster.

If every node times out but websites still load, check the specific error in the logs, then verify the test URL and which core the client is actually using. If tests pass but one site won’t open, check that site’s rules, DNS, outbound restrictions, and authentication before increasing the timeout.

Troubleshoot low latency but slow downloads

Check bandwidth limits and shared congestion

A small response transfers very little data, so a node capped at 5 Mbit/s can still show good latency. But 5 Mbit/s has a theoretical maximum of about 0.625 MB/s, and protocol overhead reduces the actual rate further. In that case, switching to a node with latency a few milliseconds lower is unlikely to fix slow large-file downloads.

The same pattern can occur during peak hours. A shared outbound connection may handle one small request quickly but fail to sustain enough bandwidth. Download the same file at 09:00 and 21:00. If sustained speed drops sharply only in the evening while a direct connection performs normally, suspect congestion along the proxy route or at its exit first.

Check for packet loss and retransmissions

A small amount of packet loss may not show up in an individual latency result, yet it can cause repeated retransmissions on long-lived connections and shrink the sending window. Ten successful short requests don’t prove a connection will remain stable during a long transfer. Also check whether download speeds repeatedly drop to zero, connections reconnect, or TCP retransmissions increase in your system’s network tools.

Intermediate routers may rate-limit ICMP replies, making a route probe appear to show packet loss. Don’t diagnose a fault based on loss at a single hop: consider the final destination, failures in real app connections, and sustained transfer performance. In particular, the failure rate of HTTP probes is not the actual packet loss rate of the network path.

Check the destination site, device, and local network

• Try another source that allows large-file downloads to rule out per-site throttling and CDN cache differences.
• Retest over a wired connection or closer to the router to rule out Wi-Fi interference.
• Check Task Manager or Activity Monitor for CPU usage that stays near 100%.
• Pause uploads on other devices. When upload bandwidth is saturated, acknowledgments and interactive requests can get stuck in queues too.

Slow video startup can also involve playlist requests, segment servers, account region, and decoding. One latency figure in the client can’t measure the full playback path or confirm that all these steps are working.

Use a consistent process to measure real-world speed

Select a node manually before opening the app or site you want to test. Don’t let an automatic selection group switch nodes during the test, and don’t run speed tests on all nodes at once. If you change a node or rule, close the existing page and start a new connection; established connections may not immediately use the new route.

Use curl to inspect request timings separately

The commands below access an example site through the local HTTP or mixed proxy port at 127.0.0.1:7890. Check the actual port in your client and change it if yours isn’t 7890. On Windows, use curl.exe to avoid differences with commands that share the same name in some PowerShell environments.

curl --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 --output response.html --silent --show-error --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

Here, time_connect mainly measures the time to connect to the local proxy; it is not the latency to the remote node. time_appconnect and time_starttransfer are cumulative timings measured from the start of the request, not independent durations to add together. This command is useful for comparing request stages for the same URL, not for measuring bandwidth.

Measure sustained downloads, not just the initial peak

1. Choose a fixed file you’re allowed to access and large enough to sustain a transfer for about 30 seconds.
2. Use the same single-connection or multi-connection setup for both nodes; don’t mix methods.
3. Ignore the initial few seconds of fluctuation. Record the speed during the steady phase and the number of pauses.
4. Repeat three rounds per node, with breaks between them, so a brief cache boost doesn’t skew the long-term picture.

The example below illustrates how to compare results. It isn’t a test conducted by this site and doesn’t represent the quality of any specific node. Both nodes pass 10 probes, and the download method and file are the same.

Under these conditions, Node B is the better choice for large downloads. For short interactive requests, also compare time to first byte and failures on the sites you actually use. No single latency threshold can predict the experience for every kind of traffic.

What url-test can—and can’t—do

With a mihomo url-test policy group, automatic selection is still based on probe results for a specified URL, not a bandwidth ranking. Merge the snippet below into your existing configuration. Node A and Node B must match the names of real nodes already defined in your config.

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

• interval: 300 checks every 300 seconds; it is not the test timeout.
• tolerance: 50 sets the switching threshold to reduce node changes caused by fluctuations of a few dozen milliseconds; it doesn’t limit download speed.
• lazy: true lets an unused group skip periodic checks, but doesn’t guarantee that the latest result is always available while the group is idle.

This configuration applies to mihomo environments that support these fields. The client may change the final configuration through overrides, subscription merging, or UI settings; check the loaded config and logs. Keep a working copy before editing, so the next subscription update doesn’t overwrite your local changes.

If a download needs a stable outbound route, use a manual selection group to pin a node. Reducing how often nodes switch makes behavior more predictable, but can’t guarantee every long-lived connection will stay open. The node’s availability, how the client handles connections, and the destination site’s status still matter.

Run a final check based on the symptoms

Low latency, but pages still feel sluggish

First verify the policy chain used by the browser connection, then inspect the Network panel in developer tools. Separate DNS lookup, connection setup, waiting for a response, and content download. If only one resource domain is slow, check whether a different rule sends it through another outbound node. Don’t use a test for the home page’s domain as a substitute for checking every resource domain.

High latency, but downloads are fast

First check whether the test traffic takes a detour, then look at sustained throughput. A long-distance route can have a high round-trip time and still deliver fast downloads if it has enough available bandwidth and little packet loss. For large-file transfers, don’t rule out a node just because its latency is higher.

Latency varies widely, with occasional timeouts

At the same time of day, compare wired and Wi-Fi connections, pause uploads, and run 10 probes. If your local network is stable but all candidate nodes fluctuate at once, check the access network. If only one node varies, investigate its proxy route. Confirm the issue on the sites you actually use so an outage at the test service isn’t mistaken for a problem with every node.

Keep track of three things: which outbound route your traffic uses, whether short requests are stable, and the sustained transfer speed.Measure these first, then decide whether to change nodes, adjust rules, or check your local network. Latency helps narrow down the problem; choose a node based on how it performs with your actual traffic.