How Clash Latency Tests Work

What a latency reading actually measures

The “test” button in a Clash client typically measures how long it takes to reach a specified URL through a proxy. It doesn’t download a large file to measure bandwidth. Readings such as 80 ms or 160 ms show how long that test request took; they can’t be converted directly into megabytes per second or taken as a measure of how quickly every website will respond.

Clients may offer TCP connection tests, HTTP latency tests, or separate download speed tests. This article focuses on url-test configurations and HTTP-based proxy latency checks. Timing boundaries and connection reuse can vary between clients and core versions, so make sure you’re comparing the same type of test.

What happens during a url-test request

Take the common HTTPS test URL https://www.gstatic.com/generate_204. The core sends an HTTP request through the proxy being tested. This URL typically returns HTTP 204 with no response body to download, making it useful for a lightweight reachability and response-time check. It isn’t a bandwidth test file, and it won’t necessarily work on every network.

1. Prepare the connection. The client needs the proxy server’s address. If the server uses a domain name, DNS lookup may be needed before connecting. Whether the test target’s domain is resolved locally or remotely depends on the proxy protocol and the core’s DNS settings.
2. Connect to the proxy. A transport connection must be established between your local network and the proxy server. TCP-based protocols may require a TCP handshake; some protocols also require a TLS handshake or authentication. Protocols using other transports don’t necessarily follow the same steps.
3. Open a route to the target. The proxy’s egress server then connects to the test site. A nearby proxy ingress doesn’t mean the egress server is close to the target. A roundabout route or congestion at the egress can still add delay.
4. Send the request and wait for a response. The test runs within the timing boundaries defined by the core, and the client displays the elapsed time. Certificate validation failures, connection resets, and timeouts may all show up as failures rather than valid millisecond readings.

So HTTP latency is neither simply the “ping” from your device to a server nor a fixed sum of every handshake time. DNS caching, TLS session resumption, underlying connection reuse, and core implementation can all affect the result. A reading that drops from 230 ms to 120 ms on the next test doesn’t prove the route suddenly gained bandwidth.

Why ping shows a lower number

The ping command usually sends ICMP echo requests and measures the round-trip time to a host. It doesn’t complete the HTTP request described above and usually doesn’t go through your system’s HTTP proxy. Servers may also restrict ICMP while allowing proxy traffic. So a failed ping doesn’t prove a proxy is unavailable, and a low ping doesn’t guarantee that HTTPS pages will load quickly.

The test URL determines what you’re comparing

A node test connects to its test URL, while your browser may be accessing a video site, code repository, or meeting server. Each destination can have different CDN locations, origin servers, and network peering. One route might reach the test site in 60 ms but take a detour to a site you need for work. Another might test at 110 ms but have a better route to the services you actually use.

• Use the same URL for a fair comparison. If node A is tested against one site and node B against another, their readings aren’t a fair basis for ranking them.
• Check for problems with the URL separately. A failed DNS lookup, certificate date error, or server rate limit could cause several nodes to time out at once. Try again with a stable HTTPS URL that returns a small response.
• Interpret status codes in context. Some cores or clients let you configure the expected response status. A redirect, verification page, or unexpected status may mean that “a response was received” and “the test passed” aren’t the same thing.
• Test the service you actually use. Once you’ve picked a candidate node, open the sites you need and check sign-in, images, video playback, and persistent connections—not just the client’s proxy list.

Why low latency can still mean slow downloads

A lightweight request mainly reveals the cost of establishing a connection and waiting for a response. Sustained downloads depend more on available bandwidth, congestion control, packet loss, and the server’s capacity. A small response may arrive quickly, but the same connection could hit an egress speed cap when transferring 500 MB.

Latency vs. throughput: an example

Suppose node A has 65 ms HTTP latency and a sustained download speed of 2 MB/s, while node B has 140 ms latency and a sustained speed of 15 MB/s. This example illustrates the difference between the metrics; it isn’t a real-world ranking. A may start responding sooner to small web requests, while B is more likely to deliver enough throughput for large files or high-bitrate video. If the site limits speeds, both may still be constrained by the source server.

“Lower latency means it’s always faster” ignores how much data is being transferred. “Faster downloads mean it’s always better for meetings” overlooks stability, upload capacity, and the route to real-time services. Choose metrics based on what you need instead of combining every result into one ranking.

How jitter and packet loss affect performance

A single best-case latency reading can hide fluctuations. For example, consecutive results of 78, 82, 80, 460, and 85 ms make that 460 ms spike worth investigating. It could be caused by Wi-Fi contention, queueing, retransmissions, or a temporary slowdown at the test site. Five HTTP requests alone can’t tell you the underlying network’s packet loss rate.

On reliable transports, lost data can trigger retransmissions and affect the congestion window, significantly slowing long downloads. In real-time audio and video, you may hear dropouts, see frozen frames, or experience more buffering. Applications handle recovery and buffering differently, so the same node may work well for buffered video but poorly for live meetings.

• Run 5 to 10 consecutive tests and look at the median, highest reading, and number of failures—not just the lowest result.
• If 2 out of 10 HTTP tests fail, report “2 of 10 requests failed in this round,” not “20% packet loss on the route.”
• Test both when the network is quiet and during your usual evening hours. If performance worsens only in the evening, compare the load on your local broadband connection with the proxy’s egress.
• Pause cloud sync, large downloads, and other speed tests while testing to avoid creating your own network congestion.

url-test automation doesn’t choose the highest-bandwidth proxy

In Clash and Clash Meta (now commonly called mihomo) configurations, a url-test proxy group selects a member based on its latency test result for the specified URL. Despite the name, it doesn’t automatically download a large file to compare bandwidth. To pin a route manually, use a select group. With an automatic test group, expect latency to be the main selection criterion.

Here’s a proxy group example. It assumes your current configuration already has proxies named “Hong Kong A” and “Japan B.” When using it, replace the member names with the exact names in your configuration and merge the group into your existing proxy-groups list. Don’t replace your entire configuration with this snippet.

proxy-groups:
  - name: Lowest Latency
    type: url-test
    proxies:
      - Hong Kong A
      - Japan B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

• interval: 300 sets the test interval to 300 seconds. Actual scheduling may also depend on mechanisms such as lazy testing in the core, so don’t treat this as a timer that runs precisely on schedule in every situation.
• tolerance: 50 sets the automatic selection’s switch tolerance in milliseconds, reducing unnecessary switches over differences of just a few milliseconds. Exact behavior depends on the core version in use.
• Defining a proxy group isn’t enough: your traffic rules must reference it, or an upstream manual selection group must select it, for connections to use its choice.

When an automatic group selects a new member, existing connections usually don’t migrate immediately. Older connections may continue using the previous egress, while new ones use the newly selected proxy. To troubleshoot, check the target domain, matched rule, and proxy chain on the client’s “Connections” page—not just the current node shown next to the group name.

How to verify real-world speed under the same conditions

In many clients, you can select a node and run a latency test from the “Proxies” page, then check the request route in “Connections” or “Logs.” These are common menu names, but not every client uses exactly the same labels. System proxy and TUN modes also handle different ranges of traffic, so use the same mode throughout your tests.

1. Keep the network conditions consistent. Use the same device, broadband connection, and Wi-Fi band; if possible, test over Ethernet too. Don’t compare a phone’s cellular results directly with a computer’s Wi-Fi results.
2. Make sure the traffic is actually using the proxy. Find the test site on the “Connections” page and check that its route isn’t DIRECT, then confirm which node it uses. A core’s built-in latency probe usually specifies the proxy being tested; a successful probe doesn’t mean your browser traffic is being routed correctly.
3. Record lightweight request results. Test the same URL 5 to 10 times and note typical response times, notable spikes, and failures. Don’t run repeated tests against a large number of nodes at once.
4. Then measure sustained throughput. Choose a fixed source with enough available bandwidth and download from it for about 30 seconds, noting the speed once it stabilizes. Keep the file, source, and number of concurrent connections the same, and be mindful of any data limits.
5. Finish by testing the tasks you care about. For video, check buffering and playback stability; for meetings, check upload performance and audio continuity; for code repositories, test page loads and file downloads separately. Change only one variable per test.

When choosing a node, first use latency tests to rule out candidates that are currently unreachable or clearly performing poorly. Then compare variation, sustained throughput, and performance in the apps you actually use. Response time matters for browsing; bandwidth matters more for large downloads; stability and upload capacity matter just as much for real-time communication. Track these metrics separately to understand why good-looking numbers in the client don’t always translate into a better experience.