How to Read Clash Latency Tests: url-test, Speed Test Results, and Real-World Performance

Latency measures the time for one probe, not download speed

The 80 ms or 230 ms shown in a client usually comes from the core sending a single HTTP or HTTPS probe through a selected node to a test URL. It tells you how long that request took to receive a response that met the test criteria—not how much data the connection can transfer per second. A button labeled “Speed Test” may not download a large file at all.

Keep three metrics separate: latency is the wait for a single interaction, throughput is the ability to sustain data transfer, and stability is how much repeated requests vary or fail. Low latency helps with frequent small requests, but by itself says little about video loading, large downloads, or long-lived connections.

How url-test works: probing a URL through candidate nodes

url-test is a proxy group type. The core probes a URL through the group’s candidate proxies, then selects an outbound based on availability, latency, and the switching tolerance. A client’s manual latency test and a proxy group’s scheduled probes may use different URLs, timeouts, or methods, so the number shown in the UI alone can’t tell you whether automatic selection is misbehaving.

What a probe’s route includes

1. DNS resolution and connection setup: The node server’s hostname must be resolved. Whether the destination hostname is resolved locally or remotely depends on the protocol, DNS settings, and implementation.
2. Establishing the proxy tunnel: The client connects to the node and completes the protocol handshake; the node then reaches the test destination. If the route uses a relay, traffic also traverses that relay.
3. Requesting the test resource: An HTTPS URL typically involves a TLS handshake, followed by an HTTP request and a wait for the response.
4. Recording the result: A successful probe returns an elapsed time. A failed connection, timeout, or response that doesn’t meet the test criteria may be reported as failed, unavailable, or timed out.

These are the stages a request may pass through; they don’t mean every core includes every stage in the same measurement. DNS caching, connection reuse, protocol implementation, and the timer’s start and end points all affect the result. Compare values from Clash, Clash Meta (mihomo), and different client UIs only under the same test conditions; don’t treat them as directly comparable by default.

This isn’t the same as a traditional ICMP ping. A server blocking ICMP doesn’t necessarily prevent an HTTP probe from succeeding; being able to ping a server doesn’t prove proxy authentication, the protocol handshake, or access to the destination will work.

A probe doesn’t replace your actual routing rules

A proxy group probes each candidate outbound directly; it doesn’t first send the test URL through the full rules list as if it were a regular browser request. Browser traffic is still affected by the operating mode, matching rules, and selected proxy group. If the test uses node A but the page ultimately matches DIRECT or another group, the two experiences can naturally differ.

Low latency, but still slow: four route mismatches

Quick small responses, slow sustained transfers

A common generate_204 URL returns a tiny response, making it useful for lightweight reachability checks. It barely tests sustained throughput. Even when a short request is fast, congestion at the node, per-connection rate limits, or a heavily loaded exit can make large downloads crawl.

For example, here are hypothetical figures to illustrate the difference—not measurements from this site: node A probes at 65 ms and downloads at 1.2 MB/s; node B probes at 140 ms and downloads at 8 MB/s. A responds faster to a short request, but B may finish downloading the same file sooner.

The test server is nearby; the service you need isn’t

Test URLs are often served by CDNs. Different exit regions may reach different data centers, so a good probe result reflects only the route to that specific destination. Routes, peering quality, and server load can all differ when you access a code repository, video service, or business portal in another region.

One low reading, but inconsistent results over time

If the same node returns 70, 75, 620, timeout, 82 ms in successive tests, looking only at the final 82 ms hides the variation. Packet loss can trigger retransmissions, affecting TLS handshakes, concurrent page loads, and long transfers in particular. A probe “timeout” means an application-level test failed; it shouldn’t be treated as an ICMP packet-loss rate.

Your app uses UDP or a different connection type

A successful HTTP probe doesn’t prove UDP forwarding works. Voice calls, games, and QUIC-based services also depend on UDP support in the protocol, server settings, how the client handles traffic, and firewall rules. Enabling TUN doesn’t add node bandwidth; it changes how traffic enters the client, but doesn’t guarantee that every app follows the same route as an HTTP probe.

Configure url-test: fix the URL and interval first

This is a mihomo proxy group snippet, not a complete, standalone configuration. The existing proxies section must already define nodes named “Hong Kong-A” and “Hong Kong-B”; use your actual node names when merging it. Don’t add a second top-level proxy-groups field with the same name at the end of the file.

proxy-groups:
  - name: Auto select
    type: url-test
    proxies:
      - Hong Kong-A
      - Hong Kong-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

• type: url-test: Selects a candidate outbound based on URL probe results; it is not a bandwidth test group.
• url: The probe target for this group. The example uses a common lightweight HTTPS test endpoint, but you’ll need to verify that it’s reachable on your network.
• interval: 300: Run scheduled probes every 300 seconds (5 minutes), not every 300 milliseconds.
• tolerance: 80: Sets an 80 ms switching tolerance to avoid switching over small latency differences.
• lazy: true: With mihomo’s lazy probing, an unused group may not run scheduled tests continuously. Don’t assume its results are always being refreshed in the background.

Subscription providers may also run health checks configured under proxy-providers with health-check. Provider check intervals, a proxy group’s interval, and a client UI’s manual test are separate settings. Changing one doesn’t necessarily change all displayed results or test behavior.

How to set tolerance: avoid switching for small differences

tolerance is neither the “maximum allowed latency” nor a “pass if below this value” threshold. It sets how much faster a candidate must be than the currently selected node before switching. In other words, keep the current usable node when another is only slightly faster; switch when the gap exceeds the configured tolerance.

For example, using common mihomo selection behavior: the current node is at 150 ms, and a candidate is at 110 ms, a gap of just 40 ms. With tolerance: 80, that small advantage usually won’t trigger a switch. If the candidate drops to 60 ms, the 90 ms gap exceeds the tolerance. The actual choice still depends on whether the current node is available, valid probe results, and the core implementation.

The order of adjustments matters more than one number

1. First, keep the test URL and network conditions consistent, and make sure the node isn’t frequently failing probes.
2. Start by observing a tolerance between 50 and 100 ms. This is only a starting point, not a universal setting for every route.
3. If similarly fast candidates keep switching back and forth, increase the tolerance slightly. If a clearly faster node is never selected, check the latency gap and the latest valid results.
4. If the current node is unavailable, investigate health checks and failure detection. Tolerance isn’t a rule for keeping a broken node selected.

A switch usually affects new connections; existing TCP connections don’t migrate seamlessly to another node. It’s perfectly possible for an old download to stay slow while a new page loads faster after a switch. Avoid setting interval to 1 second just to keep testing: probes create connections and traffic, and checking too often can add load without fixing real route fluctuations.

Choosing a test URL: lightweight, stable, and relevant

Choose a URL that stays reachable, returns as little data as possible, requires no login, doesn’t rely on short-lived signatures, and avoids multiple redirects. Using a full video page, a large file, or a CAPTCHA-protected page for health checks can make normal page behavior look like a network failure.

https://www.gstatic.com/generate_204 is a reasonable starting test URL, but it isn’t the right choice for every network. If it behaves unusually through an exit, check the logs, destination reachability, and response status, then verify with another stable endpoint that returns a small response. A failure at one URL doesn’t prove that every service is unavailable.

Don’t mix HTTP and HTTPS test results in the same ranking. HTTPS typically adds TLS overhead; a lower reading after switching to HTTP doesn’t mean the node’s route improved. To test a specific service, you can also check its initial response, but don’t use a logged-in business page as a permanent health check for the whole group.

Compare real-world performance: retest over the same route

When investigating “low latency but slow pages,” first make sure the probe and the real request use the same outbound, then look at DNS, throughput, and the destination service. Client menus change between versions, so follow the feature descriptions below rather than relying on a particular UI layout.

1. Check the operating mode: If you need rule-based routing, check for mode: rule and make sure the configuration you just edited is active—not a different profile.
2. Check which route the connection uses: Open the client’s connection list, visit the destination, and check the matching rule, proxy group, and actual outbound for that connection. Check the logs if needed.
3. Temporarily pin a node: Use a manually selectable proxy group to pin node A and prevent automatic switching during the comparison. Restore the original strategy when you’re done.
4. Collect repeated samples: On the same network, test the same URL 10 times and record the median, maximum, and number of failures. Track failures separately; don’t include them in the average as 0 ms.
5. Test the actual service too: Download the same file from the same site for 30 seconds and record the speed once it stabilizes. For video, check buffering, recovery after seeking, and uninterrupted playback.
6. Check traffic capture separately: If the issue only occurs in TUN mode, check DNS, routing, and UDP support. If traffic doesn’t appear in the connection list when using the system proxy, first confirm that the app follows the system proxy settings.

Check the local proxy endpoint too. For example, if the configuration uses mixed-port: 7890, your test tool should connect to the client’s actual listener at 127.0.0.1:7890. Don’t assume 7897 or 1080, which may be left over from another client, are universal ports. The active configuration and listening status determine which port is available.

Once you’ve compared the results, troubleshoot based on the failure pattern: if probes are stable but large downloads are slow, look at throughput and congestion; if only certain sites are slow, check the destination route and rules; if failures occur periodically, check for network fluctuations and node health. Use latency to shortlist candidates, then let real-world tests make the final call.

FAQ: timeouts, manual tests, and automatic selection