How Clash Node Latency Tests Work: Why the Milliseconds Shown in the Panel Don't Equal Real Speed

What the Milliseconds in the Panel Actually Measure

Clash, Clash Meta (now commonly called mihomo), and graphical clients that use their control APIs typically display node test results as a millisecond value. This number is often called “latency” or a “speed test,” but it is neither the ICMP Ping that traditional command-line tools run against a server nor a complete test of the node’s available bandwidth. It is closer to the time required to complete an HTTP request through the selected proxy node.

Once testing begins, the client or core uses the selected proxy node to access the test URL. The process may include connecting to the proxy server, completing the protocol handshake, opening the outbound connection to the target site, performing a TLS handshake, sending the HTTP request, and receiving the response headers. Different core versions, test URL protocols, and connection reuse states change the timing boundaries, so two clients testing the same node may still show different results.

The Request Path of a Typical Latency Test

1. The client sends a node latency test request to the mihomo control API.
2. The core connects from the local machine to the node server, such as its TCP or UDP listening port.
3. The core completes the handshake required by Shadowsocks, Trojan, VLESS, Hysteria2, or another proxy protocol.
4. The node server connects from its outbound network to the target server specified by the test URL.
5. If the URL uses HTTPS, it must also complete the TLS handshake and verify the certificate.
6. The target server returns an HTTP response, the core stops the timer, and the client reports the result in milliseconds.

Therefore, a panel reading of 80 ms cannot be interpreted directly as “the physical round-trip latency from this machine to the node is 80 ms.” It may also include the path from the node to the test site and application-layer handshakes. Conversely, 220 ms does not necessarily mean poor download speed; with sufficient bandwidth, limited packet loss, and stable congestion control, a single connection can still achieve high throughput.

How It Differs from System Ping

ping typically sends ICMP Echo packets and measures the round-trip time until the target host responds. Many proxy servers restrict or completely ignore ICMP while still accepting TCP or UDP traffic on the proxy port. Some servers also route or prioritize ICMP differently, so a 45 ms command-line Ping and a 110 ms Clash panel result are not contradictory.

HTTP latency testing is closer to everyday web requests, but it is still only a very small sample. Test responses are often empty or extremely short, so they barely occupy the link. The test shows how long it takes to establish a connection, but not how much data that connection can transfer per second once established.

How the Test URL Changes the Result

The test URL is not a decorative field. A node’s latency is affected by the target site’s location, DNS resolution, the HTTP or HTTPS protocol, target-server load, CDN routing, and the carrier’s network path. The same node can produce results that differ by tens or hundreds of milliseconds when accessing a test site in Tokyo versus one in Frankfurt, because the outbound paths are different.

Why 204 URLs Are Commonly Used for Connectivity Tests

Common URLs include http://www.gstatic.com/generate_204, https://www.gstatic.com/generate_204, and https://cp.cloudflare.com/generate_204. When healthy, these endpoints return HTTP 204 without a response body, keeping the transfer very small and making them suitable for frequent connectivity and latency checks.

An HTTP URL skips the TLS handshake, so its value usually reflects the time needed to establish the connection and receive the first HTTP response. An HTTPS URL adds certificate negotiation and encrypted handshaking, making it closer to everyday HTTPS browsing, though the first connection may take longer. If the client reuses an existing connection, later tests may also be faster than the first. When comparing nodes, keep the URL, timeout, client version, and network conditions consistent.

URL and Timeout Values in the Configuration

In a mihomo configuration, a url-test proxy group can specify a test URL, check interval, and tolerance. The configuration below checks candidate nodes every 300 seconds; when a new node is only slightly faster than the current one, tolerance helps prevent frequent switching.

proxy-groups:
  - name: Auto Select
    type: url-test
    proxies:
      - Tokyo-01
      - Singapore-01
      - Los Angeles-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

interval: 300 means the periodic check interval is 300 seconds; it does not mean every user request triggers a new speed test. tolerance: 80 is measured in milliseconds and leaves room for a difference before switching nodes. lazy: true allows the proxy group to reduce active checks while it is not in use. Exact support depends on the current mihomo core version and the configuration generated by the client.

The control API can also test a single node. A typical request is GET /proxies/节点名/delay with timeout and url query parameters. A graphical client’s “Test Latency” button usually performs this step internally. If the controller listens on 127.0.0.1:9090, requests should be accessible only to trusted local programs; when LAN control is enabled, set an access key and restrict the firewall source.

Why a Low-Latency Node Can Still Lag

Low latency only means that a short request returned quickly at the moment of testing. Web browsing, video playback, cloud downloads, and online meetings also depend on throughput, jitter, packet loss, concurrent connections, DNS results, and the target site’s outbound path. A bottleneck anywhere along the way can produce the familiar result: “60 ms in the panel, but slow in real use.”

Bandwidth Limits and Shared Congestion

A node may return a few-dozen-byte 204 response quickly while offering only 5 Mbps of usable bandwidth. In ideal terms, 5 Mbps is about 0.625 MB/s; downloading a 500 MB file would take at least about 800 seconds, before protocol overhead and speed fluctuations. If the node’s inbound or outbound capacity is shared by many users, a route that reaches 80 Mbps during the early morning may deliver only 8 Mbps in the evening. A short latency test may not immediately reveal the difference.

Bandwidth can also be limited per connection. Some routes look fast with multiple parallel connections but cannot sustain a single video stream; others have enough total capacity but throttle after a short burst. For evaluation, record the speed curve over 30 to 60 seconds instead of looking only at the initial download peak.

Packet Loss, Jitter, and TCP Retransmissions

Average latency cannot describe the variation between requests. Five consecutive results of 62, 65, 61, 64, and 180 ms still produce a moderate average, but the fifth spike can affect gaming, voice calls, and remote desktops. With 2% packet loss, TCP retransmits data and adjusts its congestion window; large-file throughput may drop sharply even while a successfully returned 204 test still shows a green number.

UDP-based traffic exposes jitter more readily. Games and real-time voice usually do not wait for lost packets to be retransmitted, so latency swings of just 20 to 40 ms can appear as teleporting, broken audio, or unstable input response. For these uses, track maximum latency, jitter range, and packet-loss rate over time instead of choosing only the lowest single result.

Different Outbound Paths from the Node to Target Sites

A fast response from the test URL does not mean every website uses the same outbound path. A node may take different routes to Cloudflare, Google, GitHub, streaming CDNs, and enterprise services. A Singapore node might reach a local CDN in 45 ms while still taking more than 230 ms to reach a business server on the US East Coast. Video services may also assign different CDN edge nodes based on the node’s exit IP, making the real path completely different from the latency-test path.

When diagnosing a specific website, access the target service through the node directly instead of repeatedly running a global latency test. The browser’s Network panel can show the time spent on DNS, connection setup, TLS, waiting for the first byte, and content download. If time to first byte is short but content downloads slowly, throughput is the more likely issue; if connection setup is already taking a long time, investigate handshakes, routing, or packet loss.

Local Processing, DNS, and TUN Mode

TUN mode handles more system traffic and uses the configuration for DNS interception, routing decisions, and network-stack processing. On a properly performing device, this overhead is usually not the main bottleneck. However, older hardware, high CPU usage, third-party security filtering, or multiple virtual network adapters can degrade the experience. In this situation, the panel test runs directly through the core and may not follow exactly the same system path as a browser or game.

DNS settings can also cause a node to show normal latency while websites remain slow. For example, a domain may resolve to a CDN address far from the node’s exit location; the connection succeeds but takes an inefficient detour. With fake-ip mode, also verify that LAN devices, corporate domains, or special applications requiring real IP addresses are included in the filter rules. After changing DNS settings, reload the configuration and clear the operating system or browser DNS cache before testing again.

A More Reliable Way to Evaluate Nodes

Node selection should cover five dimensions: connectivity, responsiveness, stability, throughput, and the target service itself. First use panel latency to eliminate unavailable or obviously inefficient routes, then run sustained tests. This reflects real-world needs better than simply sorting nodes from the smallest millisecond value to the largest.

Step 1: Measure Repeatedly Under Fixed Conditions

1. Pause active downloads, cloud-drive sync, and system updates.
2. Use the same wired connection or Wi-Fi band throughout the test; do not switch to mobile data midway.
3. Use the same HTTPS 204 URL for every candidate node.
4. Run five consecutive tests at 3- to 5-second intervals, recording the minimum, maximum, and number of failures.
5. Test during both your usual usage period and the evening peak, keeping at least two sets of results.

For example, Node A returns 78, 81, 79, 83, and 80 ms; Node B returns 55, 210, 62, timeout, and 58 ms. Node B has the lower minimum, but its variation and failure rate are much worse. Occasional fast page loads do not offset the risk of timeouts; Node A will usually be more stable for continued use.

Step 2: Run a Controlled Download Test

Choose a stable HTTPS file source that permits testing and download continuously for 30 to 60 seconds. Use the same file, download tool, and a similar time window for every node, so limits imposed by the test site are not mistaken for node limits. Record the speed during the stable phase, not the cached peak from the first one or two seconds.

Keep speed units consistent as well. When a client shows 40 Mbps, that is theoretically about 5 MB/s because one byte equals eight bits. Actual file-write speed is usually slightly lower after TCP, TLS, and proxy-protocol overhead. If the system monitor shows MB/s while the speed-test page shows Mbps, comparing the numbers directly creates an eightfold error.

Step 3: Test Real Services for Your Use Case

• Web and development: Test frequently used search engines, code repositories, package registries, and documentation sites, focusing on first-render time and small-file requests.
• Video: Play continuously for 10 minutes and check quality changes, rebuffering, and stability during peak hours.
• Remote work: Test meetings, remote desktops, and company services, focusing on jitter and brief interruptions.
• Gaming: Prioritize the relevant server region and verify UDP availability, packet loss, and in-game latency instead of testing only a generic 204 URL.
• Large files: Observe single-connection and multi-connection speeds for at least 60 seconds, and check whether the rate periodically drops to zero.

Step 4: Build a Simple Scorecard

Record average latency, maximum latency, failure count, sustained download speed, and target-service performance separately. For web use, latency and stability can carry more weight; for large downloads, throughput matters more; for gaming and calls, packet loss, jitter, and maximum latency are usually more important than average download speed.

Troubleshooting Order for Abnormal Latency

When every node suddenly times out, check the local machine and subscription status first. When only one region or one node is affected, then investigate the server and route. Repeatedly changing DNS, the TUN stack, and rule sets at the beginning only makes the scope of the problem harder to identify.

All Nodes Show a Timeout

1. Confirm that the current configuration loaded successfully and that selectable nodes exist in the proxy list.
2. Check whether the test URL resolves over the current network, and try another reliable HTTPS 204 URL.
3. Confirm that the system clock is accurate. A clock offset can cause TLS certificate verification to fail.
4. Review the client log, focusing on timeout, connection refused, TLS handshake, and DNS errors.
5. Temporarily disable and re-enable the system proxy or TUN mode, confirming that the old process and virtual adapter state have been released.
6. Update the subscription and check whether node addresses, ports, or authentication details have changed.

Many graphical clients provide a “Settings” → “Logs” or “Core” → “Logs” entry; exact menu names vary by client version. Setting the mihomo log level to info is usually enough to confirm the connection stage. Use debug only briefly when you need handshake details, then restore the previous level to prevent the log from growing rapidly.

Only One Node Times Out

First switch to another node in the same region within the proxy group. If the other nodes work, the issue is usually specific to that node’s server, port, protocol parameters, or access route. If the same server offers multiple ports, test them separately, but do not change the protocol, SNI, transport layer, and test URL at the same time; otherwise you cannot tell which change restored the connection.

Trojan and TLS-based nodes require the correct server name and a matching certificate; WebSocket nodes also depend on the Host and path; UDP-based options such as Hysteria2 and TUIC may be affected by local-network or firewall restrictions on UDP. Use the subscription-provided configuration for these parameters rather than deleting them simply to lower the latency number.

Latency Looks Normal but the Browser Is Still Slow

1. Confirm that browser traffic is actually reaching the intended proxy group. Check the target domain, rule, and outbound node in the client’s connection list.
2. In rule mode, check whether the target domain was incorrectly assigned to DIRECT or another proxy group.
3. Clear the browser DNS cache, disable extensions that may use their own proxy settings, and test again.
4. Compare system-proxy mode with TUN mode. If only one mode is affected, check for port conflicts, virtual adapters, and the routing table.
5. Test the target website rather than a generic latency URL, and compare the time spent in connection setup with the time spent downloading content.

Common local ports include the HTTP proxy at 7890, SOCKS5 proxy at 7891, mixed port at 7890, and external controller at 9090, but subscriptions and clients may use different values. Manual browser proxy settings, system proxy settings, and third-party network tools must point to the actual current ports. If two programs listen on the same port, the core may fail to start, and the log will usually report that the address is already in use.

Turning Latency Numbers into Actionable Decisions

Clash panel latency is a short-request metric. It compresses the path from the local machine to the node, proxy-protocol processing, the node’s outbound route to the test site, and any TLS and HTTP exchanges into one number. This is useful for connectivity checks and like-for-like comparisons, but it cannot capture bandwidth, peak-hour congestion, packet loss, jitter, target-site routing, or the local network stack.

When choosing a node, keeping test conditions consistent matters more than chasing the lowest one-off result. A node that stays near 90 ms for five consecutive tests is usually better for long-term use than one that jumps between 50 and 300 ms and occasionally times out. Add a 30- to 60-second throughput test for downloads, and packet-loss and jitter checks for games and meetings, to reach a conclusion that matches the actual use case.

If the client supports automatic URL-Test selection, place nodes from nearby regions in the same group and set a fixed test URL, a sensible 300-second check interval, and a reasonable tolerance. For services that must keep sessions stable, choose a manual node or a health-checked failover strategy to avoid frequent switches caused by minor latency changes.