Clash Latency Tests Explained: Why Low Ping Doesn’t Mean Faster Downloads

Node latency: check availability first, then compare speed

Low latency doesn’t mean faster downloads, and a timeout doesn’t necessarily mean a node is completely down. The “speed test” in a Clash client is usually a small HTTP request, not a sustained download test. It’s useful for ruling out nodes that can’t complete a request and for informing automatic proxy groups. To judge video, download, or meeting performance, also consider sustained throughput, stability, and the destination you actually use.

For example, one node might show 80 ms and another 180 ms, but the first isn’t necessarily better for downloading large files. It may respond quickly but have limited bandwidth, while the second takes a little longer to connect but can transfer more data consistently. These figures are illustrative, not results measured by this site.

Units are easy to mix up, too. 100 Mbps converts to a theoretical 12.5 MB/s, but actual download speeds are also affected by protocol overhead, server limits, and network conditions. A 100 ms reading in the node list is not a download speed rating.

How url-test works: timing a proxy HTTP probe

url-test is a proxy group type. The core accesses a specified test URL through each candidate proxy, records how long it takes, and uses the results to select a node. A client’s manual latency-test button often starts a similar test through the core’s control API, but the button and the proxy group may use different URLs and timeouts, so their readings may not match.

What happens during a test

1. Read the test URL and determine which proxy or proxy group to test.
2. Connect to the proxy server and complete the connection steps required by its protocol.
3. Access the destination through the proxy; for HTTPS, this also involves a TLS handshake with the destination.
4. Send an HTTP probe request and receive a response within the time limit set by the core.

Connection reuse, the timing start point, and request implementation can vary across core versions. A test is not exactly the same as an ICMP ping, nor is it a precise measurement of a single network round trip. More accurately, it measures how long a small HTTP probe takes to complete through the proxy at that moment, including connection setup, handshakes, and waiting for a response.

Why it can’t measure bandwidth

A commonly used generate_204 URL returns a very small response; 204 means there’s no response body. Since the request doesn’t transfer enough data over time, it can’t show how much throughput the connection sustains under a load lasting tens of seconds. A quick response only means that this test path completed quickly at that moment—it doesn’t mean large downloads won’t be throttled.

A test also doesn’t necessarily follow the same routing rules as your regular traffic. It probes a specified proxy, which doesn’t prove that a browser request used that same node. To confirm the actual route, check the client’s connection log, matching rules, and final proxy chain.

Test URLs: changing the URL can change the ranking

Test results depend on both the route from your device to the proxy and the route from the proxy’s exit to the test site. The test site’s location, whether it uses a CDN, and how its domain resolves can all affect the result. A node may reach the test site quickly but be slow to reach a server you use for work.

Don’t compare HTTP and HTTPS tests as if they were the same

HTTP tests usually skip the destination TLS handshake, so the reading may be lower—but it only reflects an HTTP probe. HTTPS is closer to everyday encrypted web browsing and may also reveal certificate or system clock problems. When comparing nodes, keep the URL, protocol, and timeout consistent instead of ranking an HTTP result against an HTTPS one.

• Choose a small, reliable URL that doesn’t require signing in.
• If every node times out, try a second test URL to cross-check the results.
• Don’t point automatic tests for many nodes at a service endpoint with strict access limits.
• Record the original URL before changing it, so you don’t mistake a new test URL for a sudden improvement or slowdown in your network.

Automatic proxy groups: interval and tolerance do different things

The following proxy group snippet is for the mihomo core and requires support for include-all; it is not a complete subscription. It pulls candidates from the proxy nodes and proxy providers in your full configuration, so you must have actual proxies configured first. Traditional Clash and older cores may not support this field. Check the documentation for your core and explicitly reference existing entries with proxies or use as appropriate.

proxy-groups:
  - name: Auto Select
    type: url-test
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: Proxy Exit
    type: select
    proxies:
      - Auto Select
      - DIRECT

Auto Select and Proxy Exit are both defined in the snippet, but they won’t automatically handle all traffic. Rules in the full configuration still need to reference the appropriate proxy group. Keep the subscription’s existing rule structure, check which group the target request uses, and then decide whether to replace it. Don’t switch the entire ruleset to global proxy mode just to run a test.

Tolerance doesn’t mean “only nodes under 50 ms are usable,” nor does it add a fixed 50 ms to every result. It affects when automatic selection switches nodes. For example, if the current node is around 130 ms and another is around 110 ms, a 20 ms improvement may not be enough to trigger a switch. The exact behavior also depends on the core implementation and node availability.

Timeouts: 5000 ms is the maximum wait, not a speed threshold

A timeout means the probe didn’t finish within the allotted time. A 5000 ms timeout means waiting up to about 5 seconds; increasing it to 10000 ms may allow some slower requests to return a result, but won’t increase a node’s bandwidth. Don’t add timeout to just any proxy group, either: check the documentation for your core to confirm whether the field is supported and where it belongs.

Understand timeout parameters through the control API

Cores with a Clash-style control API typically provide a proxy latency endpoint. The command below is for local diagnostics only. It assumes the API is enabled at 127.0.0.1:9090 and does not require authentication in this example. The test target is the built-in DIRECT, which provides a direct-connection baseline—not a subscription node:

curl --get "http://127.0.0.1:9090/proxies/DIRECT/delay" \
  --data-urlencode "url=https://www.gstatic.com/generate_204" \
  --data-urlencode "timeout=5000"

A successful request may return something like {"delay":186}, indicating a measured latency of 186 ms. This is only an example of the response format. To test a specific node, replace DIRECT in the path with the actual proxy name and URL-encode it. Don’t concatenate names containing non-ASCII characters, spaces, or slashes directly into the path.

If the API has secret enabled, the request must include the corresponding Bearer authorization header. A 401 response means you don’t have permission; it isn’t a node timeout. Don’t expose the control API to the public internet just to make testing easier. Port 9090 isn’t required, either—use the port in the client’s active configuration.

If every test times out, troubleshoot in this order

1. Check that the core is running and the subscription’s nodes have loaded; don’t rely on an old node list.
2. Try a second test URL. If only one URL fails, first check whether that destination is reachable.
3. Check the logs for DNS errors, connection refusals, TLS issues, and timeouts to identify where the failure occurs.
4. Make sure the system date and time are correct to rule out HTTPS certificate time errors.
5. Test two different nodes with the same timeout, then compare against a direct-connection baseline if needed.

Real-world speed: keep the node and destination fixed, and repeat the test

To compare two nodes, switch from automatic selection to a fixed candidate or use an existing manual selection group. Changing exit nodes repeatedly during a test makes the results hard to interpret. Browser connection reuse, server-side caching, and background downloads can also skew the comparison.

A repeatable testing process

1. Keep conditions consistent: Use the same device and Wi-Fi or wired network, and pause other bandwidth-intensive tasks.
2. Verify the route: Check the target domain, matching rule, and final node in the connection log to make sure the download didn’t go DIRECT.
3. Repeat small requests: Test each node five times and record every result, not just the lowest one.
4. Measure sustained transfers: Use the same large file you’re authorized to access and monitor it for 30–60 seconds to distinguish the initial burst from the sustained speed.
5. Retest at different times: For example, run a round at 10:00 and again at 21:00, and note any evening drop in throughput or increase in timeouts.

Suppose five latency results are 82, 85, 87, 91, and 680 ms. The median is 87 ms, but the large spike in the final result is worth investigating. These figures are a calculation example, not measured results. The failure rate from a small sample of HTTP tests also shouldn’t be called the “network packet loss rate”; failures may be caused by DNS, TLS, the destination site, or connection timeouts.

Low latency but slow downloads? Check these first

• Congested proxy exit: Small requests may still complete quickly while large transfers compete for bandwidth during peak hours.
• Destination server throttling: Different file hosts and CDNs may apply different limits to the same proxy exit.
• Local Wi-Fi: A weak or unstable signal and retransmissions can slow sustained transfers. Try a wired connection as a comparison.
• Protocol and device load: Encryption, CPU usage, and client resource limits can all affect throughput.
• Different routes: The speed-test button and your actual traffic may use different nodes, or the app may not follow the system proxy at all.

That last case is especially common. A browser working through the proxy doesn’t mean every app uses the same route. Apps that ignore the system proxy may need an in-app proxy or TUN routing. TUN changes how traffic enters the core; it doesn’t add proxy-exit bandwidth. For a basic setup, see the system proxy guide. For a quick overview of the concepts, visit the concepts guide.

Choosing a node: match it to your use case instead of sorting only by milliseconds

For web browsing, prioritize consistent responses and access to your destination. For large downloads, focus on sustained throughput. For video, watch buffering and playback interruptions. Voice and other real-time apps also depend on jitter, dropped connections, and the relevant UDP route. An HTTP latency test can’t confirm that UDP forwarding works or replace diagnostics in the app itself.

• Everyday browsing: Keep a stable node or use an automatic proxy group with a sensible tolerance.
• Large downloads: Compare actual download speeds and keep the exit node stable during the transfer.
• One site acting up: Check which rule matched, then compare how the site performs in actual use.
• Evening slowdowns: Retest under the same conditions instead of relying on latency readings saved from the morning.

The most useful notes are simple: test time, test URL, timeout, final node, repeated latency results, and sustained download speed. With these details, you can tell whether the issue is the test destination, the proxy route, or your local configuration. If you need a different client, start with the client comparison, then choose one for your platform. There’s no need to keep reinstalling just to chase a lower latency reading.