Clash Latency Test Explained: Why URL Test Results Don’t Match Download Speeds

1. URL Tests Measure Request Time, Not Download Bandwidth

In clients such as Clash Nyanpasu, the milliseconds shown next to a proxy usually come from the core’s URL Test. It sends a request through the proxy to a specified test URL and records how long the probe takes to complete. This is not a standard ICMP ping to the proxy server, nor a throughput test based on downloading a large file. Before deciding whether a proxy is “fast,” check what kind of test the client is displaying.

A typical lightweight HTTPS probe may involve establishing a proxy connection, completing the proxy protocol handshake, connecting to the destination, performing a TLS handshake, and receiving an HTTP response. The result can also depend on where DNS resolution happens, whether connections are reused, the core version, and latency measurement settings. So a displayed value of 180 ms should not be read simply as the round-trip time between your device and the proxy server.

Check the units: ms measures time; MB/s or Mbps measures transfer speed. A short request transfers very little data, so it can’t tell you how much traffic a connection can sustain.

Three Types of “Speed Tests,” Three Different Questions

A server may block ICMP and still provide proxy service normally. Conversely, a server may respond to ping while its proxy port is unavailable. When troubleshooting Clash proxies, URL Test gives you a better picture of the proxy route than ping alone, but you’ll still need to test the actual services you use.

2. Low Latency, Slow Downloads: Handshakes, Bandwidth, and Congestion

Latency tells you how long a round trip takes; bandwidth describes how much data can be transferred per unit of time. A small probe may return little more than a response header and finish quickly even on a low-bandwidth connection. When downloading hundreds of megabytes, however, bandwidth caps, shared egress capacity, and server-side throttling become much more apparent.

A Sample Comparison

The figures below illustrate how to compare results; they are not measurements or guarantees for any particular service. Suppose the same device, test URL, and time of day produce these results:

For large downloads, Proxy B is worth trying first. For short requests, Proxy A may respond faster when the network is quiet, though its peak time suggests stability needs further checking. 1.2 MB/s is about 9.6 Mbps, while 9.0 MB/s is about 72 Mbps. Make sure you’re comparing the same units: bytes and bits are not interchangeable.

• First page load: DNS, connection handshakes, time to first byte, and multiple resource requests all matter, so latency can have a significant impact.
• Large downloads: Sustained throughput, retransmissions caused by packet loss, and server limits matter more.
• Video playback: You need enough sustained throughput; a brief speed spike doesn’t mean the stream can keep buffering fast enough.
• Real-time interaction: Look beyond average latency to jitter, packet loss, and the UDP route actually in use.

Congestion during peak hours often increases latency and reduces throughput at the same time, but it may only become apparent during sustained transfers. An 80 ms probe taken while the connection is idle can’t predict network load for the next ten minutes.

3. How Test URLs and Timeouts Affect Rankings

The Test URL Determines What You’re Measuring

A URL Test doesn’t stop at the proxy entry point; it also covers the route from the proxy’s exit to the test destination. Changing the test domain can change the CDN endpoint, DNS result, TLS behavior, and egress route. A proxy that’s close to the test site may still be far from a code hosting service, streaming platform, or workplace system.

Lightweight test URLs often return HTTP 204 to minimize the effect of response content on results. For example, https://www.gstatic.com/generate_204 can be used as a probe, but it isn’t guaranteed to work from every egress point or network. Don’t use pages that require sign-in, present CAPTCHAs, or redirect frequently as general-purpose test targets.

• To compare proxies fairly, use the same URL, protocol, and timeout.
• When troubleshooting a specific website, test an actual request to that site instead of relying on a generic probe.
• If batch tests all fail, first check whether the test site itself is reachable.
• Don’t hide real-world failures by switching to an easier-to-reach URL and declaring the proxy “healthy.”

A Timeout Is a Wait Limit, Not a Latency Reading

Suppose two tests have time limits of 3,000 ms and 10,000 ms. A proxy that takes 4,200 ms to complete the probe will fail the first test but may return a valid result in the second. A longer timeout only gives the request more time to finish; it doesn’t make the connection faster. A “timeout” in the client doesn’t mean the proxy is permanently down—it means this probe didn’t complete successfully within the specified conditions.

Failures can also stem from DNS resolution, TLS, a refused connection, or restrictions on the test destination. Check the core logs to tell these apart. Manual tests, proxy group health checks, and provider health checks may use different settings across clients; don’t assume that changing one UI option affects every probe.

4. Configuring mihomo url-test Proxy Groups

A url-test proxy group automatically selects a candidate based on probe results, letting the core prioritize low latency. Here’s a configuration snippet; assume the full config already contains two proxies named “Hong Kong Entry A” and “Japan Entry B” under proxies. Back up your config first, then merge the snippet using a configuration editor or override method supported by your client. Don’t import it as a complete subscription.

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

• interval: 300: Checks every 300 seconds, not every 300 milliseconds.
• tolerance: 50: Sets a 50 ms switch tolerance to avoid frequent changes for small latency differences; it is not a timeout setting.
• lazy: true: Avoids running periodic tests continuously when the group is unused. Don’t expect this setting to keep probe results up to date in the background.
• proxies: References proxies or group names that are already defined. Names must match the config exactly.

The group only chooses an egress for a connection when a rule or another proxy group selects it. Creating a group without referencing it won’t automatically route browser traffic through it. Existing downloads and long-lived connections usually won’t migrate seamlessly when the policy changes; establish a new connection to see the effect.

Auto-select doesn’t rank bandwidth: url-test routes based on probe latency; it doesn’t download large files to measure each proxy’s sustained bandwidth. For downloads, pin a proxy in a manual selection group and compare throughput separately.

If the candidates come from proxy-providers, check the provider’s health-check settings too. Provider health checks and proxy group probes serve different purposes and may use different parameters. Subscription updates may overwrite direct edits, so use an override mechanism supported by your client for persistent changes, then verify the effective config after it loads.

5. A Repeatable Proxy Comparison: Keep Conditions Consistent

1. Keep the network conditions consistent. Test on the same device and Wi-Fi or Ethernet connection. Pause system updates, cloud sync, and other large downloads to avoid using up local bandwidth.
2. Check the traffic route. In the connections list, check which rule matched the target domain and which proxy was ultimately selected. In rule mode, the test site may connect directly while latency probes still use candidate proxies, so the results aren’t directly comparable.
3. Pin each candidate proxy. Temporarily use manual selection so an automatic group doesn’t switch proxies during testing. After each switch, start a new connection; stop and restart an existing download if needed.
4. Repeat lightweight probes. Run five tests per proxy, about five seconds apart, and record the number of successful tests, median, and maximum. Don’t keep only the lowest result.
5. Add a real-world test. Use the same download URL for about 30 seconds over a single connection and observe the sustained rate. Record multi-connection results separately instead of combining them with single-connection results.
6. Test at different times. Run one round during the day and another during peak evening hours. If performance drops mainly in the evening, suspect load or routing congestion before reinstalling the client.

Test a Specific Local HTTP Proxy with curl

This command assumes mixed-port is set to 7890, local connections are allowed, and no additional proxy authentication is required. If the port differs, use the value from the active config. In Windows PowerShell, use curl.exe to avoid argument parsing issues caused by the alias used in older environments.

curl --proxy http://127.0.0.1:7890 --output /dev/null --silent --show-error --connect-timeout 5 --max-time 10 --write-out "status=%{http_code} first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://www.gstatic.com/generate_204

The output redirection shown here works on macOS and Linux. On Windows, replace /dev/null with NUL. --connect-timeout 5 limits the connection phase to five seconds, while --max-time 10 limits the entire request to ten seconds; times are reported in seconds. This measures curl’s request through the local proxy and may not match the core’s URL Test latency in milliseconds exactly.

Read the test results alongside the connections list: after the local HTTP proxy receives a request, the core still selects an egress based on the current mode and rules. Using --proxy alone doesn’t prove that traffic went through the remote proxy you intended to compare.

6. Common Issues: From Timeouts to Video Buffering

Every Proxy Suddenly Times Out

First confirm that the current network can reach basic services. Then check whether the server addresses in your subscription resolve, whether the test destination is reachable, and whether the logs show connection refusals or TLS errors. Try a different, reliable lightweight HTTPS URL as a cross-check. A single batch failure doesn’t prove that every proxy is down, so don’t rush to delete the entire config.

The Test Shows 60 ms, but Websites Take Seconds to Load

First check whether the website actually used that proxy, then see if the browser reused an existing connection. A page may load dozens of third-party resources, and a single slow DNS lookup or blocked request can hold up the entire page. The browser’s developer tools Network panel can distinguish time to first byte from content download, helping you tell whether the delay comes from a handshake, a slow server response, or slow transfer.

Tests Look Fine, but Video Keeps Buffering

Check your video service’s own stats, such as connection speed and buffer length, rather than relying on Clash latency alone. The media CDN and test site may use different routes, and egress traffic may be restricted for specific services. If an HTTP probe succeeds but the service uses UDP or QUIC, check that route separately. A single HTTPS probe can’t verify every protocol.

Performance Changes After Enabling TUN

TUN changes how traffic is captured; it doesn’t directly increase bandwidth. Before and after switching, check for conflicts involving DNS interception, routing, or other proxy software. The core’s own proxy probes and app traffic entering the core through TUN may not take exactly the same local route, so use actual connection records to explain the difference.

7. Choosing a Proxy: Availability First, Stability Next, Then Your Use Case

Choose a proxy in three steps: first confirm that your target service is reachable, then compare the success rate and variation across repeated probes, and finally run tests suited to browsing, downloads, or video. A stable 150 ms proxy is often better for everyday use than one that occasionally hits 50 ms but times out frequently.

• Browsing and work: Look at request times across repeated tests and the success rate for the services you use.
• Downloads and updates: Compare sustained speeds using the same source and number of connections.
• Video and meetings: Check buffering, jitter, packet loss, and real-world performance over the protocols you use.

Treat URL Test as a lightweight availability and latency probe for a specific destination, and one number is less likely to mislead you. Before changing the test URL, timeout, or proxy group, save the original settings and results. Change one thing at a time so you can tell whether an improvement came from the config or a temporary change in network load.