Clash Latency Tests Explained: Why Ping Results Don’t Match Download Speeds

1. Latency in milliseconds isn’t download speed

“Speed tests” in Clash clients usually mean URL latency tests run by the core—not downloading a large file to measure bandwidth. The 120 ms shown in the interface is the time taken by a small request. It doesn’t tell you how much data you can download per second. It mainly reflects the wait for a connection and response, not sustained transfer performance.

Calling it “handshake time” is a useful simplification, but it’s not technically precise. The timing can vary with the core implementation, proxy protocol, connection reuse, and whether the test URL uses HTTP or HTTPS. It’s neither pure TCP handshake time nor the ICMP round-trip time reported by the system’s ping command.

For example, node A might have 80 ms latency but download at just 2 MB/s, while node B has 160 ms latency and reaches 15 MB/s. These figures are illustrative, not measurements from this site. A may complete short requests faster, while B is better for large downloads. There’s no contradiction: bandwidth, congestion, and per-connection limits aren’t captured by a single small request.

2. What happens during a url-test request

url-test is one type of proxy group. The core accesses a specified URL through each candidate node, records the results, then selects a node based on factors such as availability, latency, and tolerance. A client’s “Test all” feature may also call the core’s latency test interface, but it may use a different URL, timeout, or trigger method than the proxy group.

A typical HTTPS probe

1. Choose a test target: Read the test URL, such as https://www.gstatic.com/generate_204. This path typically returns HTTP 204 with no response body to download.
2. Establish the proxy connection: The device connects to the candidate node and completes the steps required by its proxy protocol. Resolving the node address and completing transport- and protocol-level handshakes can all take time.
3. Reach the test site: Connect to the target through the proxy exit. HTTPS also involves a TLS handshake with the target site. Which side resolves the target domain depends on the protocol and configuration, so it’s not always resolved by the local device.
4. Record the response: The core records the request time according to its implementation and returns a result or error. Clients may show failures as “timed out,” a red indicator, or an unavailable status.

Node probes typically test traffic sent through a specific proxy outbound. They don’t necessarily reproduce a browser request to the test URL with your usual routing rules. Real traffic may be routed directly, through another proxy group, or via a different node. So if the test is fast but a page is slow, first check the connection panel to see which outbound the page actually used—don’t immediately change the test URL.

3. Choosing test URLs, timeouts, and intervals

The configuration below is for mihomo cores that support these fields. mihomo is the name of the project that followed Clash Meta; older Clash versions and some clients may not support every field in their graphical settings. Check the core type shown in your client, then consult the documentation for that core. Don’t replace your entire subscription file with this snippet.

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

The names Hong Kong-01 and Japan-01 must exactly match entries in your existing proxies list. For proxy collections, you can also reference a collection with use if the core supports it. Pasting this snippet into a file without defined nodes won’t make it connect to the internet.

• url: Choose an endpoint with a small response, a stable route, and a path representative of your everyday traffic. HTTP and HTTPS involve different handshakes, so don’t directly compare rankings after switching protocols.
• interval: 300: Check automatically every 300 seconds (5 minutes). This is not the connection timeout, and it doesn’t mean a test runs every 300 milliseconds.
• timeout: 5000: Each test times out after at most 5,000 milliseconds. Too short a limit can mistake temporary congestion for an unavailable node; a longer timeout won’t fix a broken one.
• tolerance: 50: The switching tolerance is 50 milliseconds. It helps prevent frequent switching due to small latency changes. It’s not a bandwidth threshold and doesn’t subtract 50 from the displayed latency.
• lazy: true: Enables lazy checks, which may skip periodic tests while the group is unused. Don’t assume every node will update exactly every five minutes by the clock.

Don’t change the URL just to get a lower number

The test site’s location, CDN routing, and connectivity from the proxy exit all affect the result. Switching to an endpoint very close to the exit may lower the number without improving routes to the sites you actually use. Compare nodes with the same URL, network, and test method. To troubleshoot a particular site, also test a small resource on that site as a supplementary check.

There’s also little reason to set the interval to 10 seconds for hundreds of nodes. Frequent probes increase connection counts, traffic, and device load, and may trigger rate limits on the remote server. Start with 300 seconds for everyday use, then run a few manual tests when something goes wrong. That’s more useful than refreshing constantly.

4. Why low latency doesn’t guarantee fast web browsing or video

A successful small request doesn’t mean there’s enough bandwidth at peak times

A 204 request exchanges very little data. It may complete quickly even when the proxy exit is congested, while video segments and large files need sustained bandwidth. Server-side throttling, shared exit congestion, inter-network routing, and packet loss on local Wi-Fi can all reduce actual throughput.

Real websites and test sites may take different routes beyond the proxy

The route from your device to the proxy node is only half the picture. The route from the node to the test site may be completely different from the route to a video service. A fast test endpoint doesn’t mean another CDN will be fast, and a target site’s regional policies, load, or restrictions on the exit IP may affect availability directly.

Your browser may not be using the node that was tested

• In rule mode, a domain may match DIRECT or be routed through another proxy group. Check the connection log for the target domain, matched rule, and final proxy chain.
• The system proxy usually affects only apps that follow that setting. Games, apps with their own networking stack, and some command-line programs may not use it.
• TUN routes applicable traffic through a virtual network interface, but what it captures still depends on routing, exclusions, and DNS settings. Turning on TUN won’t increase a node’s bandwidth.
• Existing browser connections may not be recreated as soon as the proxy group switches nodes. To test a switch, reopen the target app or, if needed, close only the relevant connections. Avoid interrupting active downloads.

Another common source of confusion is units: 8 Mbps is roughly 1 MB/s in theory, before protocol overhead. If your ISP’s advertised rate, the speed test’s units, and your download app’s units differ, convert them first before deciding whether the speed is abnormal.

5. Choose nodes by latency, bandwidth, and stability

When choosing a node, first rule out unavailable ones, then check stability, and finally compare throughput for your needs. Don’t rely only on list order. Also, don’t try to compare fixed nodes while automatic switching is enabled—the node being tested may have changed.

1. Keep conditions consistent: Test on the same device and network, and pause background downloads. Temporarily lock a candidate node by selecting it manually, and make sure your actual traffic uses that node too.
2. Check latency over several rounds: Run five manual tests about 10 seconds apart and record the results and failures. This is for short-term troubleshooting, not a recommendation to run automatic tests every 10 seconds.
3. Test sustained transfers: Use the same trusted download source for 30–60 seconds and record the steady speed, not just the peak in the first second. Speed tests use data, so check your allowance first if you’re on a metered connection.
4. Check performance for your actual use: For video, check buffering and recovery after seeking; for remote terminals, check input response; for calls, watch for disconnects and audio dropouts. A URL test can’t replace testing UDP traffic.

The table contains illustrative data to demonstrate how to keep a record; it isn’t a real test of any specific provider. The median latency is 83 ms for A and 153 ms for B. C failed once in five tests, a sample failure rate of 20%. This small sample can’t estimate its long-term failure rate, but it’s enough to warrant further observation—not to make C the first choice just because its best result was 70 ms.

6. Troubleshooting timeouts, inconsistent results, and automatic switching

Every node times out

First, make sure your local network is working, your subscription nodes are still valid, and your system date and time are correct. Then check the core logs: timeout means the request didn’t finish before the limit; connection refused usually means the connection was rejected. Certificate errors call for further checks of the time, target certificate, and possible network interference. Don’t assume every failure means “the node is slow.”

Try another known-accessible test endpoint with a small response. If only the original test URL fails, check the target service or the route from the proxy exit to that target. If several endpoints fail, check the node settings, local network, and firewall. Don’t disable certificate verification just to make a certificate error go away—that hides the real problem.

The client’s speed test and the auto-select group show different results

Compare the URL, timeout, and last update time used by each. Manual tests in the interface, a url-test proxy group, and health-check under proxy-providers are separate configuration entry points. Changing one doesn’t necessarily update the others. Subscription updates may also overwrite local edits, so make persistent changes in the client’s supported override or merge configuration.

The fastest node wasn’t selected immediately

First confirm that your traffic is actually using a url-test group, rather than a manual selection group or a fallback group. fallback mainly picks the first available candidate in order; it doesn’t simply chase the lowest latency. With url-test, also account for tolerance, when tests refresh, lazy checks, and existing connections. A difference of a few milliseconds usually isn’t worth switching repeatedly.