How Clash Latency Tests Work: Why Ping Results Don’t Match Browsing and Streaming

The latency figure in a Clash client is often the first metric people check when choosing a node. If two nodes show 68 ms and 126 ms, it is tempting to assume the first is nearly twice as fast. But that figure only reports how long a specific probe took under the conditions at that moment. It is not a download speed and cannot fully represent real-world browsing, video buffering, gaming, or large-file transfers.

To understand latency testing, break a network request into stages: DNS resolution, connecting to the proxy node, completing the proxy protocol handshake, connecting from the node to the test target, establishing an encrypted connection, sending the request, waiting for the response, and transferring subsequent data. Different Clash clients, core versions, and test controls may measure different portions of this sequence, so different results for the same node across two clients are normal.

What a Clash latency result measures

Many graphical clients label this feature “latency test” or “speed test,” but it usually is not a conventional ICMP ping. Clash and Mihomo more commonly send a request to a test URL through the selected proxy node and measure how long a successful response takes. The target may return a tiny HTTP response, such as status code 204, so very little data is transferred. The result therefore reflects round-trip latency and connection setup overhead more than throughput.

If the test URL uses HTTPS, a probe may include TCP connection setup, proxy protocol processing, a TLS handshake, and the wait for an HTTP response. Connection reuse, cached DNS results, and the target’s response speed can also affect the result. The client interface usually shows only one combined value in milliseconds rather than a breakdown of each stage.

An 80 ms result is best read as, “This request took about 80 milliseconds through this node.” It is not a pure measure of the physical distance between your device and the node, nor is it a fixed value for every website. Changing the test URL changes the route from the node’s exit to the target server and may reorder the results.

Why low latency does not guarantee faster browsing or streaming

Latency and bandwidth measure different things. Latency is how long a request takes to make a round trip; bandwidth is how much data can be transferred over time. A node may answer a small probe quickly but deliver low sustained throughput because of limited exit bandwidth, peak-hour congestion, or shared capacity. Another node may respond slightly more slowly at first while providing more consistent usable bandwidth.

Web pages involve many separate steps

Modern pages often load HTML, scripts, stylesheets, images, API data, and third-party resources. A first visit may also require DNS lookups, TLS handshakes, and multiple new connections. Low latency reduces the wait between small requests, but total load time also depends on the number of resources, server processing time, browser caching, HTTP connection reuse, and the destination site’s load.

A node that reaches the latency-test server quickly will not necessarily reach a website’s content-delivery servers just as quickly. The test target and actual website may be in different countries, on different carriers, or in different autonomous systems. Routing quality from the proxy exit to each destination can be completely different.

Streaming depends more on sustained throughput and stability

Video players usually download content in segments and adjust quality based on recent transfer speeds. As long as a node consistently delivers throughput above the video bitrate, slightly higher base latency may have little noticeable effect. By contrast, a low-latency node with frequent throughput drops may reduce video quality, buffer longer, or interrupt playback.

A probe transfers too little data to reach a steady transfer rate or reveal congestion that develops over tens of seconds. For streaming, sustained available bandwidth, jitter, and packet loss are usually more useful than the lowest result from a single latency test.

Interactive applications are more sensitive to jitter and packet loss

Remote terminals, voice calls, and some real-time applications are sensitive to latency, but an average still does not describe the full experience. A node returning 70, 72, and 75 ms is generally more stable than one jumping among 45, 180, 60, and 260 ms. The second node occasionally posts a lower number, yet jitter and retransmissions may cause obvious pauses.

Why latency changes on the same node

Latency is not a permanent property of a node. It is a measurement shaped by a particular time, access path, exit, and target. Differences of several dozen milliseconds across back-to-back tests are common. Larger swings warrant checking whether the local network, proxy route, or test target is unstable.

1. Fluctuations in the local access network. Wi-Fi interference, mobile-network handoffs, router queues, and upload traffic from other devices can delay probe requests. Repeat the test on a stable connection before concluding that the node is at fault.
2. Changes in ISP routing. The path from your connection to the node is not fixed. Traffic may take different transit routes at different times, while peak periods can introduce queueing delays and packet loss.
3. Changes in proxy server load. A node must handle connections, protocol handshakes, and forwarding. CPU usage, connection count, exit bandwidth, and system scheduling can all affect response time.
4. Changes at the test target. The test server may enforce rate limits, resolve to different endpoints, or return over different routes depending on the proxy exit. If the target is briefly overloaded, every node may slow down at once.
5. Different DNS cache and connection-reuse states. The first probe may include DNS resolution and a new connection, while later probes may use cached records or an existing connection. The client and core’s test implementation determines whether those results are directly comparable.
6. Resource contention during concurrent testing. Testing dozens of nodes simultaneously consumes local connections, upload bandwidth, and system resources. Bulk results are useful for an initial shortlist; repeated tests of a few candidates are better for the final decision.

How the url-test proxy group uses latency results

In Clash and Mihomo configurations, url-test is an automatic proxy-selection group. The core checks the proxies in the group against the configured URL and generally selects an available node with lower latency. It works well for automatically choosing among nodes intended for similar uses, but the test target still influences the outcome.

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

interval sets the time between scheduled checks. A value of 300 in this example runs a check every 300 seconds. An interval that is too short generates more probe requests and node connections; one that is too long may miss route changes. Home networks and everyday browsing rarely need checks every few seconds.

tolerance sets the switching threshold. If the latency difference between the current node and a candidate does not exceed this value, the group can avoid switching because of minor fluctuations. Frequent exit changes can disrupt existing connections and may cause login services to detect source-address changes. A sensible tolerance is often more stable than continually chasing the lowest few milliseconds.

The exact behavior of lazy depends on the core version. It is commonly used to reduce active checks when the proxy group has no traffic. If a subscription provides the configuration, do not change the option based on its name alone. Subscription updates may overwrite local changes, and the client may manage proxy groups through overrides.

The test URL should be reliable, return a very small response body, and have some routing relevance to your main use case. If the destinations you use are far from the test server in network terms, the node with the lowest test latency may not perform best in practice. HTTP and HTTPS can also produce different results because HTTPS tests include encrypted connection setup.

How rules mode and TUN mode relate to latency tests

Clash latency probes are usually sent directly by the core through the selected proxy. They do not reproduce the complete path taken when browser traffic passes through the system proxy or TUN interception. A node marked available only confirms that the core reached the test target. If a browser still cannot open pages, check the system proxy, rule matches, DNS, and whether the application bypasses the proxy.

In rules mode, real traffic is matched from top to bottom, and the first matching rule determines its route. A node test may target one proxy directly, while an actual page request may match another proxy group, a direct rule, or a reject rule. During troubleshooting, inspect connection records or logs to confirm which policy handled the destination domain rather than inferring it from the latency shown on the proxy-group screen.

TUN mode captures more traffic from applications that do not honor system proxy settings, but it does not improve the proxy node’s underlying route quality. With TUN enabled, DNS handling, routing tables, the network stack, and firewall permissions all affect connections. If node latency looks normal but an application cannot connect, check whether TUN is running, DNS returns reachable addresses, rules match correctly, and the application uses any special network protocols.

How to use latency data when choosing a node

Use latency as an initial filter, then verify stability and performance with real tasks. There is little reason to switch repeatedly between 72 ms and 79 ms; a brief network fluctuation can easily erase that difference. What matters more is whether the node stays available, returns consistent results, and avoids noticeable stalls when accessing your actual destinations.

1. Start with a bulk screening. Remove nodes that consistently time out or show unusually high latency. A timeout does not always mean a node is completely unusable, but it does mean the node could not complete this test under the current conditions, so verify it separately later.
2. Retest the leading candidates. Choose three to five candidates and repeat the test at intervals. Look at the range of results rather than recording only the lowest one.
3. Verify performance against real destinations. Browse sites you use regularly, play a video at your usual resolution, or run a typical download or connection task. Testing for several minutes is more likely to expose congestion and throughput fluctuations.
4. Group nodes by purpose. Browsing, streaming, and low-latency interaction prioritize different network metrics. Proxy groups and rules can route different destinations through different nodes, so one node does not need to cover every use case.
5. Keep a stable node as a backup. When the lowest-latency node becomes unstable, a proven alternative is more useful than starting a new search. With a fallback proxy group, prioritize availability checks and failover rather than simply selecting the lowest latency.

A layered troubleshooting sequence for abnormal latency

If every node suddenly reports high latency or times out, check the shared path before changing individual node configurations. All nodes share the local device, LAN, DNS environment, test target, and client core. A problem at any of these layers can cause the entire list to stop returning results.

Layer 1: Local network

Confirm that the device can reach common sites directly, then check Wi-Fi signal quality, mobile-network status, and router load. Pause large uploads, cloud synchronization, and bandwidth-intensive LAN tasks before testing again. If switching to another access network resolves the issue, the original LAN or ISP path is the more likely cause.

Layer 2: Client and core

Check that the configuration loaded successfully, nodes show no protocol or parameter errors, and the controller port and core process are running normally. If every node fails after a subscription update, switch back to a previously working configuration copy. Compare the files for changes in subscription structure, proxy-group references, or override settings.

Layer 3: Test URL

If nodes can open websites but every latency test times out, suspect the probe URL. Switch to a reliable test URL that returns a small response, then compare again. Do not change several variables at once; adjust one condition per test to determine whether the target or the node route caused the problem.

Layer 4: Nodes and routes

If only a few nodes have high latency, check whether they share a region, entry point, or route. When a route is stable during the day but consistently slows in the evening, use longer-term results to assess time-dependent congestion. A single return to a low value does not prove that the issue is gone.

Put milliseconds in their proper context

Clash latency tests provide lightweight, fast, and comparable network probe results. They help eliminate unreachable nodes, identify clearly high-latency routes, and support automatic selection by url-test. Browsing performance also depends on DNS, rule matches, routing to destination sites, and how resources load. Streaming and downloads depend more on sustained throughput, congestion, and packet loss.

A more reliable approach is to use latency for the first round of filtering, repeated tests to assess jitter, and real traffic to verify bandwidth and stability. When several results are close, there is no need to chase the absolute minimum. A stable connection, reliable access to actual destinations, and infrequent policy switching usually matter more than a temporary lead of a few milliseconds.