Clash Latency Tests Explained: Why URL Test Results Don’t Match Real-World Performance

URL tests measure the time for a small request—not download speed

The short version: the latency shown in a Clash client usually measures how long the core takes to reach a test URL through a specified proxy. It’s not simply an ICMP ping, a measure of node bandwidth, or a reliable predictor of video quality. To decide whether a node suits your needs, consider latency variation, sustained throughput, access to the target service, and the rules your traffic actually matches.

The client starts the test and displays the result; the core establishes the proxy connection and contacts the target. Interface options such as “Latency Test” and “Connection Test” may use different APIs. Whether the result is unified or taken from a second request also depends on the core and client settings. Before comparing results, make sure the test URL and method are the same.

• URL test: Checks whether a small HTTP request succeeds and how long it takes, usually displayed in milliseconds.
• Download test: Measures how much data transfers over time, usually shown in MB/s or Mbps, and consumes actual bandwidth.
• Real-world use: Also depends on DNS, connection reuse, concurrent page requests, server processing, and delays within the app itself.

What happens during a latency test

A simplified test path looks like this: “your device → proxy entry → proxy exit → test site.” Real setups may include relays or multiple proxy hops, and the entry and exit points may be in different regions. Each leg can affect the request, but which steps contribute to the displayed value depends on the core implementation, cache state, and whether connections are reused.

1. Resolve hostnames needed for the connection. The proxy server’s hostname needs to be resolved. Where the test target is resolved depends on the proxy protocol, DNS settings, and core behavior; it isn’t always resolved entirely on your device.
2. Connect to the proxy. Depending on the protocol, this may involve a TCP, TLS, or UDP-based handshake. A new connection is usually slower than a reused one.
3. The proxy reaches the test target. The route from the proxy exit to the test site is also affected by routing, congestion, and the site’s own processing.
4. Receive the HTTP response. With HTTPS, this also involves a TLS session with the test site. The response status, redirects, and timeout handling can all affect the result.

Why the second test may be much faster

DNS caching, connection reuse, and TLS session resumption can all make later requests faster. mihomo’s unified-delay option reduces the effect of handshake overhead across different proxy protocols when comparing latency. Don’t directly compare results measured with different settings. When troubleshooting, leave this option unchanged; a difference after toggling it doesn’t mean the connection itself improved.

Batch tests also open multiple connections at once. On a low-powered router, mobile network, or node with limited concurrency, the tests can compete for resources and affect their own results. Clicking “Test All” several times in a row won’t necessarily produce a more reliable ranking.

How the test URL affects node rankings

The test URL matters. Different hostnames may use different CDNs, and even the same hostname can resolve to different data centers depending on the proxy exit. A short route to the test site doesn’t guarantee a short route to a video platform, code hosting service, or work site.

Three things to look for in a test URL

• Small response body: Prefer a reliable endpoint with a small response, such as a connectivity check that returns HTTP 204, to minimize the effect of data transfer.
• Consistent access: Avoid pages that require sign-in, CAPTCHA verification, regional authorization, or frequent redirects.
• Consistent test conditions: When comparing nodes, use the same URL, timeout, and network. Don’t mix results from different sites.

https://www.gstatic.com/generate_204 is a commonly used example. HTTPS uses port 443 by default. It’s suitable for probing with a small request, but it doesn’t represent every internet service. If your local network or a proxy exit can’t reach it, a failed test doesn’t prove the node is completely unusable.

After changing the test URL, retest the entire group and note when you made the change. Don’t test just one node and compare its new result with cached results for the others.

Why a low-latency node can still feel slow

A small request can be fast while sustained transfers aren’t

A tiny response may arrive before congestion becomes noticeable. Downloading a large file or streaming high-bitrate video requires sustained transfer, which can expose bandwidth limits, packet loss and retransmissions, peak-hour congestion, or connection resets. Latency measures response time; throughput measures transfer capacity. They’re related, but they aren’t the same metric.

For example, 20 Mbps works out to a theoretical transfer rate of about 2.5 MB/s, before protocol overhead. This is just a unit conversion, not a measured node speed. A node at 60 ms can easily download more slowly than one at 150 ms.

Your traffic may not be using the tested node at all

A single-node test typically probes through the explicitly selected proxy. It doesn’t prove your browser uses the same rules or proxy group. An app may match DIRECT or use a different group. Even if you manually select a node, check which rule matches the target hostname and inspect the full proxy chain.

• Find the target hostname in the client’s “Connections” or “Connection Log” view and check its rule, proxy group, and outbound proxy.
• Make sure the client is in rule mode, not accidentally set to direct mode. In global mode, check which proxy is selected for GLOBAL.
• If the app doesn’t follow the system proxy, check whether TUN mode is needed and whether the app is excluded from routing.

An HTTP probe can’t test UDP or service access

Typical HTTPS probes mainly test the corresponding HTTP request path. Games, voice calls, and some QUIC traffic use UDP, which may be affected by node protocol support, server settings, and local routing. A successful test doesn’t guarantee UDP works. Enabling TUN also won’t automatically fix every DNS resolution or UDP forwarding issue.

The target service may also restrict exit IPs, account regions, or request rates. If a page returns a regional restriction, 403, or CAPTCHA, check the service response instead of repeatedly switching nodes based only on latency.

url-test groups: choosing interval and tolerance

A url-test group automatically compares probe results; it isn’t a download speed test. The example below is for mihomo cores that support these fields. 节点-A and 节点-B must match names defined under proxies; replace them with your actual proxy names. Don’t use this snippet to overwrite your entire subscription config.

proxy-groups:
  - name: Auto Latency
    type: url-test
    proxies:
      - Node-A
      - Node-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: Outbound Selection
    type: select
    proxies:
      - Auto Latency
      - Node-A
      - Node-B

rules:
  - MATCH,Outbound Selection

Here, MATCH only shows how traffic enters a proxy group. Keep your existing LAN, direct, and traffic-routing rules, then direct fallback or specific traffic to the appropriate group. If your config already has proxy-groups or rules, merge the entries instead of adding duplicate top-level keys. See the YAML manual for the complete field structure.

Start with 300 seconds and 50 ms, then adjust based on variability

For everyday browsing, try interval: 300 and tolerance: 50 as a starting point, not universal optimal values. If you have many nodes or use mobile data, consider increasing the interval to 600 seconds. If your network changes frequently and you need fresher results, try 120 seconds after checking the load. Whether the group is in use or the device is asleep can affect when probes actually run.

Tolerance is a trade-off between responsiveness and stability. Suppose the current node is at 120 ms and another is at 100 ms, just 20 ms faster. With a 50 ms tolerance, the group will generally favor keeping the available current node. If another node is at 60 ms—a 60 ms improvement—a switch is more likely. These examples explain the parameter; actual behavior also depends on availability, previous probe results, and core implementation.

If subscription updates overwrite manual edits, use the override or merge feature supported by your client. The setting may have a different name in each client. After saving, check the runtime config loaded by the core, not just the text shown in the editor.

A repeatable way to assess real-world performance

When Clash tests look fast but websites load slowly, track probe results separately from real-world tests. Change one condition at a time so you can tell whether an improvement came from the node, the rules, or your local network.

1. Keep test conditions fixed. Use the same Wi-Fi or wired network, test URL, and latency settings. Pause any tasks saturating your upload or download bandwidth.
2. Record repeated results. Choose two or three candidate nodes and test each five times, about 10 seconds apart. Note the median, maximum, and number of failures—not just the best result.
3. Manually pin a candidate node. Select one node in the select group to prevent an automatic group from changing the outbound proxy during your test.
4. Start a fresh connection. Reopen the target page or start the transfer again, then confirm the hostname, matched rule, and proxy chain in the connections view.
5. Check sustained performance. Use the same accessible file or video clip for 60–120 seconds. Record startup delay, buffering, and sustained speed separately.
6. Check local factors first. If all nodes fluctuate, compare wired and Wi-Fi connections, check background uploads and DNS, then consider changing proxy settings one at a time.

A simple log can track seven items: time, node, test URL, five latency results, failures, and target service performance. If problems occur only during peak hours, retest at a similar time; a one-off result at night isn’t directly comparable to one during the evening peak.

Choose based on the task: web browsing depends on response time and stability, file transfers on sustained throughput, and games or voice calls on the relevant UDP path and jitter. url-test can automatically rank nodes using a consistent small-request metric, but it can’t replace real-world testing. Keeping a manual selection option usually makes troubleshooting easier than constantly shortening the test interval.