How to Read Clash Latency Tests: Why Low Numbers Don’t Always Mean Better Performance

What Clash Latency Actually Measures

The 45 ms, 168 ms, or timeout shown in a client’s node list usually comes from a small HTTP or HTTPS request. Clash or mihomo sends the test request through the selected proxy node to a test address preset by the client or defined in the configuration, then records the time from request start to a valid response. This is useful for judging whether a node can establish a connection and complete the handshake quickly, but it is not a full download speed test.

A typical HTTPS latency test involves four stages: the local application, the Clash inbound port, the proxy node, and the destination website. If the domain has not been resolved, a DNS lookup occurs first. A new connection may also include a TCP connection to the proxy server, a proxy-protocol handshake, and TCP and TLS handshakes with the test website. Connection reuse and DNS caching can both affect the final number.

1. The client sends the test request through the selected node rather than another node currently chosen automatically.
2. Clash establishes a connection using the node’s protocol, such as Shadowsocks, Trojan, VLESS, or another protocol supported by the core.
3. The proxy node then connects to the server associated with the test URL.
4. The destination server returns an HTTP response, which the client uses to calculate the elapsed time.

It’s Not Simply a Network Ping

The system command ping uses ICMP echo packets, while Clash URL Test usually sends a real HTTP or HTTPS request. Some servers restrict ICMP while still allowing proxy protocols and web traffic; conversely, Ping may be low while the proxy handshake is slow. Therefore, a server’s Ping value should not be treated as the latency Clash should display.

A node showing 70 ms in one client and 130 ms in another does not necessarily indicate a core problem. First compare the test URL, timeout, HTTPS usage, connection reuse, and local network conditions. Results from a phone on 5G and a computer on wired broadband are not directly comparable.

URL Test Request Paths and Auto-Selection

url-test is one of Clash’s proxy group types. It periodically tests the nodes in the group and selects the available node with the lowest current result. Common configurations use an address that quickly returns a 204 status, minimizing interference from response-body transfer. Here is a readable example:

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: 300 means tests run every 300 seconds, or every 5 minutes. Shorter is not always better: a 10-second interval creates extra connections and logs and can trigger frequent switches during brief fluctuations. For everyday use, start with 300 to 600 seconds and shorten it only when mobile network conditions change rapidly.

tolerance: 50 controls switching sensitivity. If the current node is 120 ms and another measures 92 ms, the 28 ms difference usually is not enough to justify an immediate switch. If the new node drops to 60 ms, the 60 ms gap makes switching more worthwhile. Tolerance helps prevent connection interruptions caused by bouncing between 80, 95, and 110 ms nodes.

The Test URL Changes the Result

The farther the test target is from the proxy exit, the higher the result will usually be. A Tokyo exit may reach a nearby Tokyo test server in 35 ms but take more than 220 ms to reach a European target. If a particular service is central to daily use, choose a stable HTTPS address with a small response and a representative route, and make sure it permits reliable long-term access.

• Test endpoint stability: If the target site is rate-limited or unavailable, every node may show a timeout.
• HTTP vs. HTTPS: HTTPS includes the cost of establishing TLS, making it closer to everyday web browsing.
• DNS resolution path: Different nameservers, fake-ip, or redir-host settings can produce different first-test times.
• Exit location: The same proxy node can take different routes and encounter different congestion when accessing targets in different regions.
• Cache state: The first test may include DNS and handshake costs, while the immediately following test may be faster.

Why a Node with Tens of Milliseconds Can Still Buffer Video

Video playback depends on sustained throughput, while a latency test transfers very little data. A node may complete a small request in 45 ms yet sustain only 2 Mbps. With a 4K video streaming at roughly 15 Mbps, the buffer drains faster than data arrives, causing frequent pauses. Conversely, a node with 180 ms latency but a stable 80 Mbps connection may open pages more slowly while performing better for large downloads and video.

Latency, Bandwidth, Packet Loss, and Jitter Are Four Different Metrics

For example, one node might measure 48, 52, 51, 49, and 55 ms across five consecutive tests—about 51 ms on average with little variation. Another might return 35, 280, 62, 410, and 44 ms. Its minimum is only 35 ms, but its jitter is extreme. If the node list shows only the latest 35 ms result, it hides the fact that later requests frequently slow down.

Packet loss is especially visible in TCP transfers. When TCP detects missing data, it retransmits it and may reduce the congestion window. Even with a baseline round-trip latency of 60 ms, sustained loss of 2% to 5% can make the download graph look like a sawtooth. UDP voice or game traffic generally does not wait for complete retransmission, resulting instead in missing audio, delayed position updates, or sudden visual jumps.

Server Load and Time-of-Day Routing Matter Too

When a proxy server’s CPU, memory, connection count, or upstream bandwidth is near its limit, small probe requests may still return quickly while high-volume transfers are throttled. Cross-network congestion is also common from 8:00 PM to 11:00 PM: a node that measures 70 ms during the day may fluctuate between 90 and 400 ms at night. A single morning test cannot represent evening performance.

How a service routes traffic for different exit addresses can also change speeds. The same node may reach a test URL quickly but be assigned a distant CDN when accessing a video service; some exits may also be rate-limited by the destination. In that case, the problem lies between the proxy exit and the destination service, not necessarily between the user’s device and the proxy server.

Use Reproducible Steps to Judge Real-World Performance

A more reliable approach is not to chase the single lowest number, but to compare multiple rounds on the same device, network, and time window. Before testing, pause cloud sync, system updates, and large downloads so background traffic does not consume the connection. On a phone, stick to either Wi-Fi or cellular data; do not let it switch automatically between them.

Step 1: Run Five Consecutive Latency Tests

1. Open the client’s proxy or node page and locate the same proxy group you want to compare.
2. Keep the test URL unchanged and run five tests in a row, about 10 seconds apart.
3. Record the minimum, maximum, and approximate average; do not look only at the final result.
4. If the five results are 82, 87, 79, 91, and 84 ms, the node is reasonably stable. If they are 60, 320, 75, timeout, and 180 ms, investigate jitter and packet loss first.

Menu names vary across graphical clients. The test entry is usually under “Proxy” → “Proxy Groups” → “Latency Test”; some clients also provide the test URL and timeout under “Settings” → “Preferences”. Record the original values before changing them to avoid making every node fail with an unreachable address.

Step 2: Test Sustained Throughput

Choose two or three nodes with stable latency and perform an actual download or video playback test for at least 30 seconds on each. Watch the sustained rate, not the initial peak. If a download jumps to 18 MB/s and settles at 1.2 MB/s after five seconds, its sustainable throughput is closer to 1.2 MB/s. Use the same target file and time window for every comparison, and avoid parallel tasks competing for bandwidth.

If video is the main use case, play fixed-resolution content and check whether the buffer continues growing over 60 seconds. The bitrate required by 1080p video varies with encoding and content, so “it opens” is not enough evidence; 4K requires more sustained throughput and line stability. Manually switching nodes during a test interrupts existing connections, so complete each round independently.

Step 3: Choose by Workload

• Web browsing: Prioritize stable latency and fast handshakes; bandwidth only needs to meet everyday requirements.
• Video and downloads: Compare sustained throughput and peak-hour stability instead of fixating on the lowest latency.
• Voice and gaming: Focus on packet loss, jitter, and UDP availability; average latency is only one factor.
• Remote terminals: Interactive sessions are sensitive to round-trip latency, so choose a route with little variation across repeated tests.
• Mobile networks: Elevators, subways, and cell-tower handoffs can significantly change results; test where you actually use the connection.

How TUN Mode, DNS, and the Local Network Affect Results

TUN mode captures more system traffic, but it does not increase proxy-server bandwidth. After TUN is enabled, application traffic may move from the system-proxy path to a virtual network-interface path, while DNS interception, routing tables, MTU, and firewall rules also come into play. Judge latency changes before and after enabling it alongside logs and the actual connection path; do not attribute them simply to core performance.

Rule Out Local Wi-Fi Jitter First

If the local router is unstable, every node will be affected. Compare a wired connection with Wi-Fi, or move the device closer to the router before testing. The 2.4 GHz band is easily affected by interference in crowded environments; 5 GHz is usually better for high throughput at short range but loses more signal through walls. If every node rises from 80 ms to 500 ms at once, check the local link before replacing the subscription.

Slow DNS Can Extend the First Connection

When a domain is used as the server or test address, DNS lookup speed affects the first connection. If resolution is abnormal or the upstream DNS server times out, the client may wait several seconds before beginning the actual proxy handshake. Clash’s fake-ip mode assigns a reserved address to the domain and maps it internally, but upstream resolution and the proxy-exit connection must still complete normally.

During troubleshooting, check mihomo logs for repeated DNS timeout, connection refused, or i/o timeout messages. If only one test domain fails, replace it with another stable endpoint that returns a small response. If every domain fails, check nameserver, network permissions, and the system clock. TLS certificate validation depends on the correct time, so a large clock error can make HTTPS tests fail outright.

MTU Problems May Appear Only Under Heavy Traffic

A small latency request succeeding does not guarantee that larger packets will work correctly. With TUN, layered VPNs, or unusual broadband setups, an unsuitable MTU can cause fragmentation or black-hole issues: small web requests work, but large transfers stall. If only heavy traffic becomes abnormal after enabling TUN, compare it with system-proxy mode with TUN disabled. Also check the client’s MTU setting, whether another VPN is running, and whether routing is being captured twice.

Common Misreadings and Configuration Advice

Misconception 1: The Lowest-Latency Node Is Always the Fastest

The lowest latency only means one short request completed faster. When choosing a node for video or downloads, also run a sustained throughput test lasting at least 30 to 60 seconds. If nodes differ by 20 ms in latency but by 40 Mbps in stable speed, the latter difference is usually more important for high-volume tasks.

Misconception 2: One Timeout Means the Node Is Dead

A single timeout may come from a failed test site, a DNS lookup error, a local network handoff, or a momentary congestion spike. Run three to five consecutive tests and compare another test URL to distinguish a node failure from a test-target failure. If only one node keeps failing, check its address, port, protocol parameters, and subscription update time.

Misconception 3: Shorter Test Intervals Are More Accurate

Intervals that are too short increase request volume and make automatic groups overly sensitive to transient changes. On a typical home network, start with a 300-second interval and 30 to 100 ms tolerance, then adjust for the number of nodes and your use case. When stable connections matter for real-time work, avoid frequent automatic switching because existing TCP sessions generally will not migrate seamlessly to a new node.

Misconception 4: Enabling TUN Fixes Every Buffering Problem

TUN mainly expands the range of traffic being captured. It is useful for apps that ignore the system proxy, but it is not a line-acceleration switch. Server congestion, exit throttling, and remote CDN routing issues will not disappear automatically with TUN. First determine whether traffic is failing to enter Clash or is already proxied but suffering poor transfer quality, then decide whether to change modes.

A Conclusion Closer to Real-World Experience

When reading Clash latency figures, think of them as “the time the current node takes to complete one small request to a specified URL.” They quickly filter out unreachable nodes and obviously slow handshakes and provide input for url-test automatic selection, but they cannot alone tell you whether video will play smoothly, how fast downloads will run, or whether gaming will be stable.

For actual selection, first examine variation across five latency tests, then measure sustained throughput for 30 to 60 seconds, and finally verify the destination service during your usual usage hours. Web browsing and remote terminals value consistently low latency; video and downloads value sustained bandwidth; gaming and calls also require checking packet loss, jitter, and the UDP path. Testing these factors separately explains why a connection can show tens of milliseconds and still buffer.

If every node slows down at the same time, check local Wi-Fi, the test URL, DNS, the system clock, and peak-hour congestion in that order. If only one node is abnormal, inspect its server load, exit route, and protocol configuration. This sequence is more likely to locate the problem than repeatedly refreshing latency results or switching modes blindly.