How Clash Proxy Latency Tests Work:Why url-test ResultsDon’t Match Download Speeds

Latency measures request time, not download speed

Click the test button on the Proxies page in Clash for Windows, and you’ll usually see a value in milliseconds next to each node. It answers “How long does a request to the test URL take through this proxy?”—not “How many megabytes per second can I download?” The 80 ms shown in the panel and 8 MB/s shown in a download manager measure different things.

Clash latency tests are typically HTTP requests sent through a proxy, not ICMP ping commands run in a terminal. The selected proxy carries a request to the test URL, and the client records how long it takes. The exact timing can vary with the core version, protocol, connection reuse, and test implementation, so numbers from different clients may not use identical measurement methods.

For example, one route may handle a small request quickly but throttle large downloads. Another may have slower cross-region round trips yet offer plenty of sustained bandwidth. The first can show lower latency while the second downloads faster. There’s no contradiction.

What happens during a url-test request

From the local core to the test server

A typical route is “local Clash core → proxy server or proxy chain → test server → local machine.” The test establishes or reuses a proxy connection, then requests a specified URL. With an HTTPS URL, the target’s TLS handshake is also involved. Where DNS resolution takes place depends on the proxy protocol, DNS settings, and connection route.

1. Select the proxy to test: The core tests a specific node. For a proxy group, the result also depends on how that group selects its actual outbound route.
2. Connect and send the request: The local network, proxy handshake, and route from the proxy exit to the target server can all affect the elapsed time.
3. Check the result: A successful request returns a latency value. A failed request, unexpected status, or expired timeout may appear as a timeout or error in the interface.

Test URLs often use lightweight endpoints that return HTTP 204. A 204 response has no body, which limits the effect of transferring large files on the measurement. That also makes the test a poor indicator of sustained bandwidth: almost no data is transferred. Don’t treat it as a download speed test.

The panel’s test button and an automatic selection group are different

A manual test in the panel usually calls the core’s latency-testing API. By contrast, type: url-test in a configuration defines a proxy group that automatically selects a proxy based on test results. They may use different test URLs, timeout values, and schedules. Changing the group’s url does not necessarily change the panel’s test button.

url-test settings: URL, interval, and tolerance

This proxy group snippet illustrates the fields and is written for mihomo. It is not a complete subscription; the node names under proxies must already exist in the current configuration. Supported fields differ between older Clash cores and other forks, so check the documentation for your core before copying it.

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

• url: The test target. This example uses a lightweight HTTPS endpoint; availability and network reachability can affect results, and the endpoint may not work on every network.
• interval: 300: Runs a test every 300 seconds. It does not allow 300 seconds for each request or mean the proxy will switch immediately if it stalls.
• tolerance: 50: A 50 ms switching tolerance helps prevent frequent changes caused by small latency differences. It is not a bandwidth threshold.
• lazy: true: Periodic checks may depend on whether the group is in use and other conditions; behavior varies by core implementation. As a result, latency values shown in the panel may not refresh while the group is idle.

Automatic selection primarily considers latency and availability. It does not rank a proxy higher just because it downloads faster. A new selection also does not move every existing connection to the new node: long-lived connections often keep using their original route. Reloading a page or opening a new connection is more likely to show the change.

Keep timeout limits separate from test intervals

For example, a compatible core control API can test a single node with a request like this. timeout=5000 sets a maximum wait of 5,000 milliseconds; it is unrelated to the proxy group’s test interval. Port 9090 is an example control port, not a proxy port.

GET /proxies/Hong%20Kong%20Entry/delay?url=https%3A%2F%2Fwww.gstatic.com%2Fgenerate_204&timeout=5000

In a real request, URL-encode the node name and include control API authentication as required by your local configuration. The client interface is usually enough for troubleshooting; don’t expose the control port to your LAN just to run a speed test. For configuration fields, see the configuration reference. Don’t confuse the control port with the HTTP or SOCKS proxy ports.

Five reasons a low-latency proxy can still feel slow

1. The test server is nearby, but the actual service takes a different route

A lightweight test endpoint may be served by a nearby CDN through the same proxy exit, while a video service, code repository, or file host sends you to a server in another region. A fast small request doesn’t guarantee the service will use the same route. Cross-region traffic can also face different return paths, peering congestion, or server-side limits.

2. Small requests are fast, but sustained bandwidth is limited

A connection handshake needs very little data, so it can finish quickly even on a throttled route. Bandwidth caps, shared exit congestion, and server load become more apparent during a download. To compare throughput, use the same source, a similar time of day, and the same download method. Speeds from two different file hosts are not a fair way to rank proxies.

3. One latency reading is low, but results vary widely

A single 65 ms result doesn’t prove a route is stable. Repeated requests might show 70, 75, and 820 ms, with some failures in between, making webpages appear to freeze unexpectedly. TCP retransmissions add waiting time, and sustained transfers are sensitive to packet loss and jitter. A series of results is more useful than chasing the lowest number.

4. The app isn’t using the proxy you tested

In Clash for Windows, first check whether General → System Proxy is enabled. Then go to Proxies → Rule and confirm the rule mode and target proxy group. Apps that follow the Windows system proxy usually use this route, but apps with their own networking stack may ignore it.

Open Connections, find the connection by target domain, and check the matched rule and proxy chain. You may have tested “Japan Entry” while the actual connection matched DIRECT—so the results won’t line up. Automatic groups, manual groups, and rule routing can also be nested; don’t rely on a single card’s label.

5. UDP, DNS, or app behavior differs from the test

A successful HTTPS test doesn’t prove that UDP forwarding works. Games, voice apps, and QUIC-based apps may use a different protocol path. Browser caches, connection reuse, DNS caching, and website response times can also affect how fast things feel. TUN can capture more connections that ignore the system proxy, but it can’t increase outbound bandwidth or guarantee that all traffic uses the proxy. Routing, rules, and exclusions still determine what happens.

A node shows timeout: narrow down the cause

timeout means this test did not succeed under the specified conditions and within the allotted time. It doesn’t prove the node is permanently down. First determine whether the issue affects one node, one test URL, or the whole network.

1. All nodes fail at once: Check that your local network works and the core is running. Try reaching the test URL through a known-good route, then check the logs for DNS or connection errors.
2. Only one node fails: Check whether the subscription is up to date, the node’s authentication details are still valid, and the current core supports its protocol. Update the subscription, then select the node again.
3. A different test URL works: The original target, certificate, DNS resolution, or route is more likely to be the problem. For a fair comparison, test all nodes against the same new URL.
4. The timeout is too short: If the client lets you change it, temporarily increase the limit from 3,000 to 5,000 milliseconds and try again. A longer timeout helps identify slow responses; it won’t fix congestion or make the route faster.
5. The test succeeds, but webpages fail: Check the target website, matched rules, and app’s network route instead of repeatedly clicking the same test button.

How to compare proxies in real-world use

Pick two or three candidate nodes. Pause Windows updates and large file syncs, and keep your network connection method consistent. If you’re on Wi-Fi, stay in the same spot during testing. Record the client, core, test URL, and time of day so you can make a meaningful comparison.

1. Keep the proxy route fixed: Temporarily choose one node in a manual selection group and confirm that the target app’s connection actually uses it. This avoids interference from automatic switching.
2. Repeat the lightweight test: Test the same URL 5–10 times, a few seconds apart. Record the median, highest value, and number of failures—not just the lowest result.
3. Try the services you actually use: Visit two or three everyday sites and see whether they load consistently the first time and on refresh. The browser’s Network panel can help you inspect request timing, though its results also include caching and server processing time.
4. Test sustained transfers separately: Choose a stable source that allows downloads and observe the transfer for 30–60 seconds. Keep data usage in mind, use the same number of concurrent connections, and note whether results are in MB/s or Mbps.
5. Retest when you normally use the network: Congestion can differ between weekday daytime and evening. Keeping results from both periods is more reliable than ranking nodes based on one test.

The example below is hypothetical and illustrates how to compare results; it is not a benchmark from this site. Both routes completed 10 lightweight requests, but the best choice depends on the task:

Chat, remote interaction, and web browsing usually benefit from responsive, stable connections. Downloads depend more on sustained throughput, while video is also affected by bitrate, adaptive buffering, and CDN selection. Check the units, too: 8 Mbps is roughly 1 MB/s before protocol overhead.

What to expect from older Clash for Windows versions

Clash for Windows is no longer maintained. If you keep an older setup, use General, Proxies, Connections, Logs to check status, matched rules, and errors—but don’t assume the old core supports every protocol or mihomo field in a newer subscription. Being able to import a subscription doesn’t mean every node will work.

For a new installation, check the client comparison for the current maintenance status, platform support, and core compatibility of projects such as Clash Verge Rev and FlClash. After switching clients, recheck the system proxy, listening ports, and test URL. Don’t compare against historical readings left by the old client.

Recommended order: First confirm the connection uses the intended node, then compare test methods, check consistency across repeated requests, and finally verify bandwidth and performance with real tasks. url-test helps identify usable exits; it’s one measurement, not an overall rating of the route.