How to Read Clash Latency Test Results: Why an 80 ms Node Can Feel Slower

What Clash latency tests actually measure

The 80 ms, 150 ms, or 500 ms values shown in Clash are usually not traditional ICMP pings. In Clash Premium, Clash for Windows 0.20.39, and Clash Verge Rev 2.3.x using the mihomo core, the client generally asks the core to access a test URL through the selected proxy node, then records how long the request takes to complete. Common addresses include https://www.gstatic.com/generate_204 and https://cp.cloudflare.com/generate_204. The server returns HTTP 204 with an empty body, making it useful for connectivity checks.

The request passes through the local Clash core, the node's ingress, the proxy transport path, the node's egress, and the test site. The result may include TCP connection setup, the TLS handshake, proxy-protocol negotiation, and the wait for an HTTP response. The exact scope depends on the core version, connection reuse, test URL, and client implementation. The number is therefore closer to the time needed for one very small web request, not the physical round-trip latency between your device and the node server.

The test URL changes the result

The test target is not a neutral yardstick. If a node exits in Tokyo, a well-connected test site in Asia might return 75 ms; switching to a site with a longer route or different connection policy could put the same node at 160 ms. If the test site rate-limits or rejects the exit IP, or triggers a TLS error, Clash may show a timeout even though other websites remain usable.

Why an 80 ms node can feel slower than a 150 ms node

An 80 ms result only means that one small request completed quickly. Web browsing, video playback, code retrieval, and cloud-drive downloads open multiple connections and transfer data continuously; the experience is also affected by packet loss, jitter, bandwidth, congestion, and exit quality. A low-latency node that retransmits every few seconds will usually feel worse than a slightly slower but stable node.

Packet loss triggers retransmissions and congestion control

TCP must deliver data in order. When a segment is lost, later data may already have arrived but the connection can still wait for a retransmission. A single URL Test transfers very little data, so it may show 80 ms when no loss occurs; after opening a page with dozens of resources, more connections and data increase the chance of exposing packet loss.

You can observe 100 consecutive requests instead of relying on one result. For example, node A may have a median of 82 ms, but a 95th-percentile latency of 780 ms and a 3% failure rate; node B may have a median of 148 ms, a 95th percentile of 190 ms, and a 0% failure rate. For web browsing and meetings, node B will often be more stable. The single lowest value cannot represent quality over an entire session.

Low latency does not mean high usable bandwidth

A URL Test response usually has an empty body, so it barely measures sustained throughput. A node capped at 5 Mbps can return 204 within 70 ms, yet downloading a 500 MB file would take about 800 seconds for the data transfer alone; a 160 ms node that can steadily deliver 80 Mbps would finish much sooner. When video switches to a higher bitrate, insufficient bandwidth also appears as frequent quality drops and buffering.

Peak-hour congestion and queueing delay

Queues can form on home-broadband uplinks, carrier cross-border links, and node ingress points. If latency is 80 ms when idle but rises to 600 ms as soon as a download starts, that is a typical increase in latency under load. Page clicks will feel slower even if a speed test still reports high throughput. Evaluate nodes both idle and during transfer instead of recording only one set of overnight numbers.

• Idle latency: Measured with no significant upload or download in progress; reflects the baseline path.
• Loaded latency: Measured during sustained downloads or uploads; reflects queue management and congestion.
• Jitter: Variation between repeated results. For example, 80, 83, and 79 ms is stable, while 80, 420, and 95 ms is not.
• Failure rate: The number of timeouts divided by the total number of tests; more important during sustained use than a single minimum value.

The difference between URL Test, health checks, and automatic selection

Manually clicking “Latency Test” usually updates only the current result shown in the interface; a url-test proxy group in the configuration tests its members periodically and selects one automatically based on the results. A proxy provider's health-check checks whether nodes are available. These features may use similar requests, but their timing and purpose differ.

proxy-groups:
  - name: AUTO
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

proxy-providers:
  provider-main:
    type: http
    url: https://example.invalid/profile.yaml
    path: ./providers/provider-main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

In this example, interval: 300 means the automatic-selection group tests on the configured schedule, while tolerance: 80 helps prevent frequent switching between nodes with similar latency. If the current node remains within the tolerance range, the core does not need to move connections immediately over a difference of a few milliseconds. lazy: true means the proxy group can reduce unnecessary active tests when it is not actually being used. Supported fields vary across Clash branches, so check the documentation for the current mihomo or client core before using them.

Automatic selection does not migrate every existing connection

After a proxy group switches from node A to node B, new connections will usually use the new selection; already-established TCP or long-lived connections may not migrate immediately. A playing video, SSH session, or download may continue using the old connection until the application reconnects. If the test value has fallen but the current page still feels slow, open a new private window or fully close the relevant connection before testing again.

Assess node quality using four groups of metrics

A reliable assessment needs four types of information: latency distribution, packet loss and failure rate, sustained throughput, and the locations of the exit and target site. Keep the local network fixed during testing, pause system updates and cloud syncing, and avoid switching between Wi-Fi and Ethernet. Observe each candidate node for 5 to 10 minutes; this is more useful than clicking the button ten times and choosing the lowest number.

Group 1: Record median and high-percentile latency

Averages can be pulled up or down by a few extreme results. Record 20 to 100 tests and focus on the median, maximum, and 95th percentile. Without statistical tools, at least check whether the results cluster. The two data sets below have similar averages but completely different stability:

Group 2: Check the proxy request failure rate

The system's ping command may be blocked by the node's ingress firewall, or it may measure only the server ingress while actual proxy traffic continues through the egress. ICMP packet loss should therefore be treated as supplementary. A method closer to real Clash usage is to send repeated requests to the same test address through the local proxy port.

curl -x http://127.0.0.1:7890 \
  -o /dev/null -s \
  -w "connect=%{time_connect} total=%{time_total} code=%{http_code}\n" \
  https://www.gstatic.com/generate_204

This example assumes Clash uses 7890 as its HTTP or Mixed port. If the client is configured to use 7897 or another port, use the actual port shown under “Settings” → “Parameter Settings.” During repeated tests, watch the variation in total, the HTTP status code, and any timeouts. If the same node times out twice in 50 tests, its failure rate is 4%, making it a poor default choice for connections that need sustained stability.

Group 3: Test sustained throughput at different times

Choose a fixed file from a trustworthy source with sufficient capacity, download it continuously for 30 to 60 seconds, and record the stable phase rather than the initial burst. Test during a weekday morning and again during the 20:00–23:00 peak period. If one node drops from 70 Mbps during the day to 8 Mbps in the evening while another holds at 35 Mbps, the latter is better suited as a long-term default.

Speed tests consume subscription traffic and add load to the node, so there is no need to download multi-gigabyte files repeatedly. To verify web browsing and 1080p video, a 100–300 MB sample is usually enough to reveal obvious throttling; 4K high-bitrate video, system images, and large repository pulls require a longer observation of stable transfer.

Group 4: Verify ingress, egress, and target locations

“Hong Kong” or “Japan” in a node name does not necessarily describe the ingress server, actual egress, and complete route at the same time. A relay node may first connect to an ingress in mainland China and then use a private line to an overseas egress; a public direct-connect node may connect from your device straight to an overseas server. The two may show similar URL Test values while still differing in peak-hour stability and bandwidth limits.

The target site's location also affects the choice. When accessing a service in Tokyo, a Japanese egress usually provides a shorter path; for a self-hosted server in Europe, a European egress may avoid a second intercontinental hop between the egress and the target. Sorting only by “closest to me” while ignoring the second half of the route can produce a node with low test latency but slow real-world performance.

Troubleshooting order when latency looks normal but apps remain slow in TUN mode

A Clash latency test is initiated by the core and proves only that the core can reach the test address through the node. Whether application traffic actually uses the same proxy group also depends on the system proxy, TUN interception, DNS, rule matching, and the application's own proxy behavior. If the test shows 80 ms while the browser still connects directly or matches a different proxy group, the two observations are not contradictory.

1. Confirm the current mode. Check whether the client is in Rule, Global, or Direct mode. In Rule mode, inspect the connection list to confirm that the target domain matched the expected rule and proxy group.
2. Check the system proxy. In interfaces such as Clash Verge Rev 2.3.x, check “Settings” → “System Settings” or the “System Proxy” switch on the home page. If only the core is running and the system proxy is disabled, applications that follow system proxy settings will not automatically enter Clash.
3. Check TUN status. Enable TUN when you need to intercept applications that do not follow the system proxy. If it stops immediately after starting, check service installation, administrator permissions, and virtual network-adapter conflicts instead of repeatedly testing node latency.
4. Check DNS. Failed domain resolution, broken Fake-IP mapping, or hijacked LAN DNS can make a page wait indefinitely. Directly visiting a known IP does not fully rule out DNS problems because HTTPS still requires the correct domain name and certificate.
5. Inspect connection details. The connection list should show the destination host, rule, proxy chain, and uploaded and downloaded byte counts. If the test node differs from the node used by the actual connection, correct the rule or proxy-group selection first.
6. Establish a new connection. Close browser tabs, pause downloads, and open them again. Long-lived HTTP/2, HTTP/3, and WebSocket connections may continue using the path selected before the switch.

What to prioritize for different use cases

For everyday browsing, the difference between 80 ms and 110 ms usually matters less than the difference between a 0% and 3% failure rate. For high-definition video, a node at 150 ms that steadily delivers 60 Mbps will usually beat a 70 ms node that can sustain only 6 Mbps. For remote desktops, a 90 ms average with frequent jumps to 500 ms is harder to use than a stable 140 ms.

A better node-selection method is to eliminate timeouts and high-failure-rate nodes first, then compare stability and throughput for your use case, and only then use latency for fine-grained ranking. url-test works well for automatically choosing among nodes of similar quality, but it is not a substitute for a complete path-quality assessment. When you see 80 ms, treat it as one test sample—not the node's overall performance score.