Back to Blog
Home/ Blog/ Clash Node Speed Testing and Optimization Guide

Clash Node Speed Testing and Optimization Guide: Find the Fastest Node

2026-07-26 10 min read Tutorial

Table of Contents

Many Clash users face a common problem: the subscription provides dozens of nodes, but which one is actually the fastest and most stable? Blindly switching between nodes wastes time. Precise selection through speed testing saves effort and delivers better results.

This tutorial covers the complete workflow of Clash node speed testing, from understanding the underlying principles to configuring automatic optimization and choosing the best node for every scenario.

Why Node Speed Testing Matters

Latency vs Bandwidth vs Stability

Node performance is determined by three separate dimensions. Understanding their differences is the foundation for correct speed testing:

Three Key Metrics
  • Latency: The time it takes for a data packet to travel from your device to the node and back, measured in milliseconds (ms). Lower latency means faster response times. Most critical for web browsing and gaming.
  • Bandwidth: The amount of data the node can transfer per second, typically measured in Mbps. Bandwidth determines download speeds and video streaming quality.
  • Stability: The ability of a node to maintain consistent connection and speed over time. Some nodes have great peak speeds but are unstable, causing frequent disconnections.

A node might have very low latency (30ms) but limited bandwidth (only 5Mbps). In this case, web pages load instantly but video streaming buffers constantly. Conversely, a node with 200ms latency but 100Mbps bandwidth handles video smoothly but feels sluggish for web browsing.

Core Principle

There is no "universally best" node. There is only the "best node for your current use case." Speed testing is not about finding the highest single metric, but about making an informed choice based on your actual needs.

How Clash Built-in Speed Testing Works

How the url-test Policy Group Works

Clash's built-in auto speed testing is implemented through the url-test policy group. Here is how it works:

  1. Sends an HTTP request to a predefined test URL
  2. Records the time from request to response (latency)
  3. Compares latency across all nodes in the policy group
  4. Automatically switches to the node with the lowest latency

Example url-test policy group configuration:

proxy-groups:
  - name: "Auto Select"
    type: url-test
    proxies:
      - "Japan Node 1"
      - "Japan Node 2"
      - "HK Node 1"
      - "HK Node 2"
      - "US Node 1"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

Choosing the Test URL

The default test URL is http://www.gstatic.com/generate_204, which returns an empty 204 response. Provided by Google and globally accessible, it is ideal for latency testing. You can also use alternatives:

url: "http://cp.cloudflare.com/generate_204"  # Provided by Cloudflare
url: "https://www.apple.com"                    # Apple CDN
url: "http://connectivitycheck.gstatic.com/generate_204"
Important Note

Clash's built-in speed test only measures latency (response time), not bandwidth. To test actual bandwidth, you need external tools (covered later). Additionally, results may vary depending on the test URL's server location.

Manual Speed Testing: Client-by-Client Guide

Clash Verge Rev (Recommended Desktop Client)

Testing Steps
  1. Open Clash Verge Rev main interface
  2. Switch to the "Proxies" page
  3. Find the speed test button (play icon) at the top of the policy group
  4. Click it to test all nodes in the current policy group
  5. After testing, each node displays its latency value (ms)
  6. Green indicates low latency (<100ms), yellow is medium (100-300ms), red indicates high latency or timeout

Clash for Windows

Testing Steps
  1. Open Clash for Windows
  2. Navigate to the "Proxies" tab
  3. Click the speed test button next to the policy group name
  4. Or use the "Speed Test" button in the top toolbar for batch testing
  5. Results appear as latency values next to each node name

Clash Meta for Android

Testing Steps
  1. Open Clash Meta for Android
  2. Switch to the "Proxy" tab
  3. Tap the speed test icon in the policy group title bar
  4. Wait for all nodes to complete testing
  5. Tap the desired node to manually switch
Batch Testing Tips

If you have multiple policy groups (e.g., "Auto Select", "HK Nodes", "Japan Nodes"), test each group individually rather than globally. This gives you a clear picture of latency by region.

How to Interpret Speed Test Results

Understanding Latency Values

Latency Range Experience Best For
< 50ms Excellent Competitive gaming, real-time trading
50-100ms Very Good Web browsing, casual gaming
100-200ms Acceptable Daily use, video streaming
200-500ms Slow Video, downloads (no impact)
> 500ms Very Slow Downloads only

What Timeout Means

If the speed test shows "timeout" or latency exceeding 10000ms, it typically means:

The Impact of Packet Loss

Clash's built-in speed test does not directly show packet loss rate. However, if you notice a node's latency fluctuates significantly (e.g., 50ms on the first test, 300ms on the second), it usually indicates packet loss issues.

Packet loss causes:

Auto Speed Test Configuration in Detail

Core Parameters Explained

The url-test policy group has three key parameters:

proxy-groups:
  - name: "Auto Select"
    type: url-test
    proxies:
      - "Node A"
      - "Node B"
      - "Node C"
    url: "http://www.gstatic.com/generate_204"
    interval: 300      # Test interval (seconds)
    tolerance: 50      # Tolerance (milliseconds)
    lazy: true         # Lazy test mode
Parameter Details
  • interval: The time between automatic speed tests, in seconds. Setting 300 means testing every 5 minutes. Setting 0 tests only at startup with no automatic retesting. Recommended: 300-600.
  • tolerance: Tolerance value in milliseconds. The system only switches to a new node if its latency is lower than the current node by at least this value. Prevents frequent switching. Recommended: 50-100.
  • lazy: Lazy test mode. When true, testing only occurs when the policy group is actively used. When false, testing happens on schedule even if unused. Recommended: true to save resources.

Recommended Configurations

Configuration 1: Daily Use

proxy-groups:
  - name: "Auto Select"
    type: url-test
    proxies:
      - "HK Node 1"
      - "HK Node 2"
      - "Japan Node 1"
      - "Japan Node 2"
      - "TW Node 1"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

Configuration 2: Gaming (Low Latency Priority)

proxy-groups:
  - name: "Gaming"
    type: url-test
    proxies:
      - "HK Gaming Node"
      - "Japan Gaming Node"
      - "TW Gaming Node"
    url: "http://www.gstatic.com/generate_204"
    interval: 60
    tolerance: 20

Configuration 3: Downloads (Bandwidth Priority)

Download scenarios care more about bandwidth than latency, but url-test only tests latency. In this case, use a select policy group with manually chosen high-bandwidth nodes:

proxy-groups:
  - name: "Downloads"
    type: select
    proxies:
      - "US High-BW Node 1"
      - "US High-BW Node 2"
      - "HK High-BW Node"
      - "Auto Select"

Node Selection Strategies by Use Case

Web Browsing

Web browsing is latency-sensitive but bandwidth-demanding is low. Choose the node with the lowest latency.

Video Streaming (Netflix/YouTube)

Video streaming requires high bandwidth and moderate latency. Nodes need sufficient bandwidth for HD/4K video.

Online Gaming

Gaming is the most latency-sensitive use case with the lowest bandwidth requirements. Competitive gaming requires latency under 100ms.

Large File Downloads

Downloads require the highest bandwidth and are insensitive to latency.

Comprehensive Recommendation

The best approach is to configure multiple policy groups, each corresponding to a use case. In rules, assign different applications or domains to different policy groups. For example: MATCH goes to "Auto Select", Netflix domains go to "Streaming", and gaming-related IPs go to "Gaming".

Advanced: External Tools for Precise Testing

iperf3: Testing Actual Bandwidth

iperf3 is a professional network bandwidth testing tool. If the node server runs an iperf3 server, you can use it to test real bandwidth:

# Install iperf3
# macOS
brew install iperf3
# Linux
sudo apt install iperf3
# Windows: Download from the official website

# Test bandwidth (requires server-side iperf3 support)
iperf3 -c <node-ip> -p <port> -t 10

speedtest-cli: Comprehensive Speed Test

Running speedtest-cli through the Clash proxy gives you the actual speed after passing through the node:

# Install
pip install speedtest-cli

# Test through proxy
export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
speedtest-cli

Using mtr to Detect Link Quality

mtr combines ping and traceroute functionality to detect packet loss along the network path:

# Install
# macOS
brew install mtr
# Linux
sudo apt install mtr

# Check the link to the node (requires knowing the node IP)
sudo mtr <node-ip>

mtr displays latency and packet loss for each hop, helping you identify exactly where in the link problems occur.

Factors Affecting Node Speed

1. Geographic Location

Physical distance is the largest factor affecting latency. Light travels at approximately 200,000km/s in fiber optic cable, so 1000km one-way requires at least 5ms latency. Adding routing equipment and protocol overhead, actual latency will be higher.

2. Line Type

Common Line Type Comparison
  • CN2 GIA: China Telecom's premium line, low latency, minimal packet loss, stable during peak hours, but expensive
  • CN2 GT: China Telecom's secondary premium line, cost-effective, may congest during peak hours
  • CMIN2: China Mobile's premium line, good latency performance
  • CU VIP: China Unicom's premium line
  • Standard lines (163, etc.): Low cost, severe congestion during peak hours
  • IPLC/IEPL: Dedicated line, does not traverse the public internet, extremely low latency and highly stable, most expensive

3. Node Load

The more users simultaneously using a node, the less bandwidth each user gets. Peak hours (8pm-12am) typically have higher load than early morning hours.

4. Protocol and Encryption

Different protocols have different overhead. Vless has the smallest protocol overhead, followed by Trojan, then Vmess. Encryption strength also affects performance, but on modern devices the impact is usually minimal (<5%).

5. Server-side Optimization

Server-side TCP parameter optimization, BBR congestion control algorithm enablement, and hardware performance all affect a node's actual performance.

Troubleshooting Common Issues

Issue 1: Fast Speed Test but Slow Real Experience

Possible causes:

Solution: Use speedtest-cli through the proxy for real bandwidth data. Check if DNS configuration is reasonable.

Issue 2: Inconsistent Speed Test Results

Possible causes:

Solution: Test multiple times and take the average. Set a reasonable tolerance value to avoid frequent switching due to minor fluctuations.

Issue 3: Some Nodes Show Timeout

Possible causes:

Solution: First check if other nodes work. If only specific nodes timeout, contact your provider to confirm node status. Update your subscription for the latest node list.

Speed Testing Pitfalls

Never judge a node based on a single speed test result. Node quality must be evaluated across latency, bandwidth, and stability, with multiple tests at different times of day for reliable conclusions. Consider maintaining a simple speed test log recording data at different times throughout the day.

Related Articles