How Clash Latency Tests Work: Why url-test Results Don’t Match Download Speeds

What a latency reading means: the time to complete a small request

The latency shown in a Clash node list usually comes from an HTTP or HTTPS probe sent through the selected proxy—not an ICMP ping to the node server. A url-test group uses these probes to check whether candidate nodes are reachable and how quickly they respond, then selects a node according to the core’s logic and settings such as tolerance. Manual latency tests and background strategy-group checks may use related mechanisms, but their test URLs, timeouts, and scope can differ.

Latency measures response time; download speed measures how much data is transferred per unit of time. A probe that returns very little data can reveal a failed connection, a significantly indirect route, or a slow response, but it cannot estimate sustained throughput. So a node with 80 ms latency delivering just 2 MB/s while one at 180 ms reaches 15 MB/s is entirely possible.

What happens during a url-test request

For an HTTPS test URL, the core typically sends a request to the target through the proxy being tested, establishes the necessary connections, and waits for an HTTP response. The result is the elapsed time for a particular probing implementation—not the pure propagation delay of a single network link.

1. Prepare the outbound connection: Read the node parameters and, if needed, resolve the proxy server’s hostname. Whether the lookup is cached can affect the work involved.
2. Connect to the proxy: Connect to the node’s entry point and complete the transport, security, or proxy handshakes required by its protocol. Protocols can differ in their use of TCP, UDP, and connection multiplexing.
3. Reach the test target: Route the request through the proxy to the test site. Where the target hostname is resolved depends on the protocol and DNS configuration—it isn’t always resolved locally.
4. Receive the response and measure elapsed time: An HTTPS request also involves TLS negotiation with the target site. The core records the result according to its implementation and passes it to the client for display.

These steps are a model for understanding the route; they don’t mean every test starts from scratch or that every core includes all setup time in the displayed result. DNS caching, existing tunnels, session resumption, and connection reuse can all make later probes faster than the first. Before comparing readings from different clients, check that they use the same test URL and timing method.

Why system ping is low but Clash latency is high

Running ping from a terminal to the node’s entry point only measures ICMP round-trip time between your device and that entry point—and ICMP traffic may be throttled or dropped. A Clash URL probe also connects to a test site, so the route from the node to that site affects the result too. The tests measure different things; subtracting one result from the other won’t reveal the “extra protocol overhead.”

Latency, bandwidth, and congestion: which metrics to look at

For example, node A returns 70, 74, 71, 520, and 76 ms across five tests; node B returns 145, 149, 146, 152, and 148 ms. These figures are illustrative, not measured by this site. Most of A’s results are lower, but one is a clear spike. For remote terminal use, B might offer a more consistent experience. Looking only at the minimum hides this difference.

Sustained downloads are also affected by server throttling, shared node bandwidth, congestion between networks, transport congestion control, and your local network. A 100 Mbps connection works out to about 12.5 MB/s before overhead, but a single connection isn’t guaranteed to reach that speed. Even if a small 204 response arrives quickly, a large download can slow down seconds later as queues build up or shared egress capacity becomes contested.

Why video buffers during peak hours even when latency looks fine

A small request transfers very little data, so a probe can finish quickly even when the link has limited throughput. Video, on the other hand, needs a steady stream of segments. If available bandwidth falls below the bitrate required for the current quality, the buffer gradually runs dry. Check the player’s buffer status, actual segment download speeds, and connection logs instead of repeatedly running latency tests.

The test URL defines what the result applies to

Common test URLs return HTTP 204, a successful response with no body. For example, https://www.gstatic.com/generate_204 can be used for this type of probe. Choose a URL that remains accessible and responds consistently with little or no data. Avoid large downloads, pages that require a login, and endpoints that frequently trigger CAPTCHAs.

• Different protocols: HTTP and HTTPS have different connection flows, so don’t compare their timings as if they were the same test. HTTPS can also check whether the target’s TLS connection succeeds.
• Different target locations: A CDN may route requests to different regions for the same hostname. Changing the node’s egress location can also change which server handles the request.
• Different site policies: A test site may restrict certain egress locations or experience a temporary outage. A single failed test only shows that this probe didn’t complete as expected.
• Different use cases: Reaching a public test site doesn’t mean you’ll get the same route or access to a video platform, code repository, or game service.

Keep a stable baseline URL for routine automatic selection, then validate performance with the services you actually use. If you often access code repositories, compare the repository page and actual clone or pull performance. If you mainly stream video, check the platform’s playback statistics. Don’t use a large-file URL for automatic probing and mistake the result for a full bandwidth test.

url-test settings: intervals, tolerance, and on-demand checks

This strategy-group snippet is for mihomo cores that support the relevant fields and must be merged into an existing configuration. It uses the built-in DIRECT member to demonstrate the field structure; used as-is, it tests only a direct connection and won’t provide proxy nodes automatically. Replace the member with node names already in your configuration, or use a proxy provider as described in your core’s documentation.

proxy-groups:
  - name: Auto latency selection
    type: url-test
    proxies:
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

• interval: 300 sets the automatic check interval to 300 seconds, or 5 minutes. It is not the request timeout and doesn’t mean a test runs every 300 milliseconds.
• tolerance: 50 sets a switching tolerance in milliseconds to prevent frequent changes over small latency differences. It does not force node latency below 50 ms.
• lazy: true allows checks to be reduced for unused strategy groups. If the background checks aren’t producing new readings continuously, that doesn’t necessarily mean they’ve stopped working.
• proxies is a list of references to existing nodes or supported strategy members. With only one member, the group has no other candidate to compare.

Suppose one member is around 120 ms and another is around 105 ms. A tolerance of 50 ms helps avoid switching back and forth over a difference that small. Actual selection also depends on member availability, test batches, and core implementation, so don’t treat tolerance as a precise promise about when switching will happen. Switching a strategy group’s selected member also doesn’t seamlessly move existing TCP connections; new connections typically use the new selection.

Troubleshooting timeouts, failures, and “0 ms” results

A timeout means the request didn’t complete as expected within the allotted time—not that its latency equals the timeout limit. If the timeout is 5000 ms, a timeout result only tells you that the probe didn’t return successfully within 5 seconds. Possible causes include a failed node connection, an unreachable test site, a DNS issue, or a stalled handshake.

Manual client speed tests, core control APIs, automatic strategy-group checks, and proxy-provider health checks may each have their own timeout settings. Don’t copy an API’s timeout parameter into every level of a YAML configuration. Check the relevant field for your core, then confirm in the logs that the test actually used the updated setting.

1. Start with the error type: A refused connection, DNS resolution failure, TLS error, and request timeout point to different stages. Recording the full error and when it occurred is more useful than simply noting that it “turned red.”
2. Run a comparison test: Try another stable test URL with the same node, then try the same URL with another node. Change one variable at a time to see whether the issue is more likely with the node or the target.
3. Check that traffic uses the intended member: Testing a node doesn’t mean your browser is using it. Check the actual matched rule, strategy group, and outbound member on the Connections page.
4. Check local traffic routing: Your browser may follow the system proxy, while your terminal may not be configured to use a proxy. TUN mode has its own traffic-capture scope. A successful speed test doesn’t mean every app is being routed through the proxy.

If you see 0 ms, a blank result, or an unusually low value, don’t immediately call it the “fastest node.” It may indicate an untested node, a cached result, rounding, or client-specific display behavior. Check the logs and test again to find out. When a result looks wrong, save the evidence before changing settings. Avoid resetting DNS, switching nodes, and changing modes all at once, or you may lose clues about the cause.

A repeatable process for comparing nodes

The key to comparing nodes is keeping test conditions consistent. Use the steps below to build a useful record without repeatedly changing your entire configuration.

1. Keep the environment consistent: Record the client and core versions, test URL, timeout, and network type. Pause large file syncs and avoid switching between Wi-Fi and a mobile hotspot during the tests.
2. Record the cold-start result: Save the first test separately. It’s more likely to be affected by DNS resolution and the initial handshake, so don’t combine it with later warm-connection results.
3. Repeat the tests: Test each node 5–10 times, about 10 seconds apart. Record the median, maximum, and number of failures. Use the same schedule for every node and avoid running a large number of probes at once, which can interfere with your local network.
4. Test your actual use case: Visit the target site, then run a download or watch a stream for about 30 seconds. Download tests use data, so keep file sizes and the number of tests under control.
5. Test again at a different time: Repeat the checks in the evening, when you typically use the connection. This helps distinguish occasional congestion from consistently poor performance; don’t keep only the best results from quiet hours.

A useful record might look like this: “Node A, HTTPS 204 probe, 92 ms median, 1 failure in 10 tests; target download averaged 3.2 MB/s.” These figures are examples of a format, not test results. Latency, failure rate, and real-world throughput together tell you much more than a single green latency reading.

Choose based on how you’ll use it, not just the lowest reading

• Web browsing and remote terminals: Prioritize consistent response times, fewer spikes, and a low failure rate.
• Video and large downloads: Once a node is reachable, focus on sustained throughput, buffering, and performance during peak hours.
• Gaming and voice calls: Focus on the actual UDP route, packet loss, and jitter. An HTTP probe can’t replace testing the game server or voice connection.

url-test helps find available routes with fast response times among candidate members; it isn’t a bandwidth leaderboard. Keep probe conditions consistent and consider real-world performance alongside connection logs. That’s how to make sense of “low latency but slow downloads” and avoid needless switching without evidence.