Clash Speed Test vs. Real-World Performance: How url-test Measures Latency

Clash Latency: One Request, Not Download Speed

The “80 ms” shown next to a proxy usually comes from a single HTTP or HTTPS probe sent through it. Milliseconds (ms) measure how long that probe takes; MB/s measures how much data can be transferred per second. They’re related, but you can’t convert one into the other. An 80 ms reading doesn’t mean you’ll download at 8 MB/s.

In a Clash configuration, url-test is a proxy group type that automatically selects a proxy. It probes candidate proxies against a specified URL and chooses based on the results. A client’s “Test” button may also call the core’s latency API, but its URL and timeout settings may differ from those used by an automatic selection group.

References to Clash Meta below also apply to its later name, mihomo. Client interfaces vary, as can core versions and test parameters. For a fair comparison, use the same test URL, network, and time of day.

What Happens During a url-test Probe

It’s Not the Same as the System ping Command

The system ping command typically sends ICMP echo packets. Clash URL probes instead access a web address through a proxy. A proxy server may not respond to ICMP and still forward web requests; conversely, a low ping to a server doesn’t mean the proxy’s exit route to a website is fast.

A fresh HTTPS probe may involve a connection from your device to the proxy, a proxy-protocol handshake, a connection from the proxy exit to the test site, and a TLS handshake. TLS is the protocol HTTPS uses to establish encrypted connections. DNS lookups, connection reuse, and protocol implementation can also affect the result, so don’t read the displayed value as simply “the round-trip time from my computer to the proxy server.”

1. Connecting to the proxy: Home broadband, Wi-Fi interference, ISP routing, and congestion at the proxy entrance can all affect this leg.
2. Establishing the proxy connection: The protocol, transport layer, and whether an existing connection can be reused all affect connection setup time.
3. Reaching the test URL: The route from the proxy exit to the test site, the site’s response time, and DNS resolution can all affect the result.
4. Recording the result: The core measures how long a request takes. The exact timing boundaries vary by implementation, so don’t break the reading down into a fixed number of handshake round trips.

Why 204 Response URLs Are Commonly Used

The HTTP status code 204 means a request succeeded but returned no response body. This keeps probe traffic small, making it suitable for frequent proxy checks. The trade-off is clear: it transfers almost no data, so it can’t measure sustained throughput under a large download or tell you whether a video will play smoothly for ten minutes.

The first probe and later ones may also be affected by DNS caching, connection reuse, and server cache state. Don’t rely on a single best reading. Run several tests and look at the variation and failures for a result closer to real-world conditions.

Low Latency, but Still Lagging? Five Common Reasons

1. Quick Small Requests, Not Enough Sustained Bandwidth

A connection might complete a small request in around 60 ms but deliver only 2 Mbps of usable throughput. Roughly speaking, downloading 3 MB would take about 12 seconds at that rate, before overhead. Another connection might have 160 ms latency but sustain 50 Mbps, making large images and videos feel much smoother.

Mbps means megabits per second; MB/s means megabytes per second. The two differ by a factor of about eight. For example, 40 Mbps is roughly 5 MB/s in theory. Check the units when comparing readings from a client, browser, or speed test site.

2. The Test URL Is Fast, but the Route to Your Site Is Different

A test site may be served by a CDN, or content delivery network, which directs requests to an edge server. A proxy may reach that server quickly without being just as fast to a video site, code repository, or game service in another region.

So “Proxy A tested at 70 ms and Proxy B at 130 ms” only describes how they reached that particular test URL at that moment. If you mainly download code, test the repository you use. If you mainly stream video, check buffering speed, resolution, and dropped frames on your target platform.

3. Occasional Packet Loss and Evening Congestion

A one-off probe may happen to miss congestion and produce an impressive-looking number. On a long-lived connection, packet loss can trigger retransmissions, reduce speeds, or even force a reconnection. If five consecutive results are 65, 68, 72, 980 ms, and a timeout, the issue isn’t “slightly higher average latency”—it’s poor reliability.

A route’s load at 8:00 p.m. can be completely different from its load at 10:00 a.m. Compare connections during the hours you actually use them; don’t use a single early-morning result to predict evening performance.

4. Your Traffic Isn’t Using the Proxy You Tested

In rule mode, rules and policy groups determine where traffic exits. You may test an “Auto Select” group while the target domain matches another group—or even DIRECT, meaning it connects directly. The system proxy affects only apps that follow system proxy settings. TUN mode captures traffic through a virtual network interface, but its actual coverage still depends on routing and exclusion settings.

Open the client’s “Connections” page, find the target domain, and check the matched rule, policy chain, and final proxy. This is more useful than repeatedly running speed tests when a proxy change seems to make no difference. If there’s no request listed, check whether the app uses the proxy and review the connection list’s filters.

5. The Slowdown Is in DNS, the App, or Your Device

A webpage may request more than one domain, including images, scripts, and login APIs. Slow DNS resolution for one domain, a misbehaving extension, or high CPU usage can all make a page feel sluggish. A short URL probe won’t catch these issues. If video has buffered enough but keeps dropping frames, check hardware decoding and device load rather than just switching proxies.

url-test Settings: What the URL, Interval, and Tolerance Control

Here’s a mihomo proxy group example. It assumes the configuration already defines proxies named “Hong Kong 01” and “Japan 01.” When merging this into an existing YAML file, keep the existing proxy definitions and other policy groups, and make sure your rules actually reference this group. YAML uses indentation to represent structure; don’t use tabs instead of spaces.

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

tolerance: 50 doesn’t add or subtract 50 ms from a test result, nor does it guarantee latency below 50 ms. It affects automatic selection’s switching decisions. The exact behavior also depends on the current proxy state, whether probes succeed, and the core implementation, so you can’t predict every switch from two static readings alone.

Subscription updates may overwrite proxy groups you edited directly. For changes you need to keep, use the client’s override or config merge feature where available, then check the final active configuration. Menu names vary by client version; don’t rely only on what the editor shows as saved.

Build a Comparable Set of Results in 10 Minutes

You don’t need to test every proxy at once. Pick two or three candidates in suitable regions, then compare them using the same process. The figures below illustrate how to evaluate results; they aren’t test results from this site.

1. Keep conditions consistent: Use the same device and network, and pause large file syncs. Note whether you’re using the system proxy or TUN, and which policy group is actually in use.
2. Confirm the exit proxy: Open the target request on the “Connections” page and check its final proxy. When selecting a proxy manually, make sure to change it in the policy group the target rule actually matches.
3. Repeat the probes: Use the same test URL and run five probes per proxy, about 5–10 seconds apart. Record the median, highest reading, and number of timeouts—not just the lowest reading.
4. Check throughput too: Download a larger file from the same source for 30–60 seconds and watch the speed once it stabilizes. Make sure the file isn’t being served from the browser cache, and keep an eye on subscription data usage.
5. Test your actual use case: Open a site you use or play a video at the same quality for three minutes. Then test again during your usual hours.

Interactive uses such as voice calls and remote access are more sensitive to latency and jitter; video and large downloads depend more on sustained throughput. Games also need a separate check of the UDP route. A successful HTTP probe doesn’t prove UDP works, and it can’t replace an in-game latency test.

Troubleshooting Odd Results and Automatic Selection

Shows timeout, a negative value, or nothing

These usually mean the probe failed, returned no valid result, or hasn’t refreshed yet; the exact display depends on the client. They don’t necessarily mean the proxy is completely unusable. The test URL may be unreachable, the timeout may be too short, or the proxy protocol settings may not match. First, try opening a real destination manually, then check the client logs for connection errors. Before sharing logs, redact subscription URLs, tokens, and proxy credentials.

It Shows 0 ms—Does That Mean It’s Extremely Fast?

Not necessarily. A zero may result from rounding, an initial UI value, or an anomalous reading; check how your client implements the test. Run it again and check the actual request’s exit proxy and duration. If a cross-region proxy keeps showing exactly 0 ms, verify that the test is really running.

Automatic Selection Keeps Picking the Lowest-Latency Proxy, but It Performs Poorly

url-test primarily selects based on probe latency. It doesn’t understand video buffering, bandwidth limits, regional service restrictions, or traffic multipliers. Narrow the candidates to proxies that have passed your real-world tests, then let automatic selection choose among them. For services that require a specific exit region, use a separate policy group rather than mixing every region into one automatic group.

Will Global Mode Make It Faster?

Global mode changes how traffic is routed; it doesn’t directly increase bandwidth. Switching to it temporarily can help determine whether routing rules are affecting the result, but restore rule mode afterward and verify the exit proxy on the “Connections” page. System proxy and TUN aren’t simply “fast” and “slow” settings either—choose based on whether your apps need traffic interception.