How to Choose Clash Nodes: Latency, Traffic Multipliers, Regions, and Protocols in Practice

Stop treating the lowest latency as the best choice

Clash clients typically place latency figures front and center in the node list. When Hong Kong A shows 58 ms, Singapore B shows 91 ms, and US C shows 168 ms, many users immediately pick the 58 ms node. That works for an initial shortlist, but not for the final decision. Latency only describes how quickly one test request completed. It does not reveal available bandwidth, peak-hour congestion, traffic multiplier, exit region, protocol compatibility, or whether a platform will actually work through the node.

Choosing a node is more like sorting candidates under hard constraints. The protocol must be supported by the current core, the region must match the target service, and the multiplier must fit the plan budget. Only then should latency and real transfer performance determine the primary node. For temporary web browsing, latency can carry more weight. For 4K video, remote development, or large file sync, sustained throughput, packet loss, and line stability must be considered together.

The sections below follow the order most commonly seen in the interface: latency, traffic multiplier, region, and protocol. At the end, these four factors are combined into an actionable selection workflow.

Dimension 1: Use latency for shortlisting, and test at least three times

What the client is actually measuring

Most Clash graphical clients have the core send an HTTP or HTTPS request to a test URL and record the time from the start of the connection to a valid response. The url-test strategy group follows a similar approach and repeats the test at the configured interval. The figure usually includes the time taken from your device to the proxy entry point, proxy processing, the proxy exit to the test site, and the handshake.

This is not a full speed test. A node showing 60 ms only means that this test path responded quickly; it does not mean the node can sustain 100 Mbps. Conversely, a 140 ms node with a stable route and ample bandwidth may download a large file noticeably faster than a 60 ms node congested during peak hours.

Use ranges instead of chasing a 5 ms difference

These ranges are practical guidelines, not pass/fail thresholds. The physical paths from Beijing to Tokyo and from Guangzhou to Hong Kong are different, and mobile, home broadband, and corporate networks can produce different results as well. When two nodes measure 61 ms and 67 ms, the difference usually has no decision-making value. If one stays around 90 ms while another jumps between 45 and 320 ms, the stable node should usually win.

The three-round test method

1. In the client, open “Proxies” → the target strategy group and run a full speed test on the candidate nodes.
2. Wait 5–10 seconds and run two more rounds. Record all three results instead of looking only at the last one.
3. Use the middle value as the baseline, while also checking the spread between the maximum and minimum.
4. Move nodes with a spread above 150 ms, frequent timeouts, or occasional multi-second readings to the backup group.
5. Test once more during the evening peak, from 8:00 PM to 11:00 PM, so an idle-period result does not drive the decision.

For example, three nodes produce these three-round results: A: 62, 65, 63 ms; B: 41, 286, 79 ms; C: 96, 101, 99 ms. A is the best primary node for interactive tasks. C is not the fastest, but its low variation also makes it suitable for long-lived connections. B has the most attractive minimum, but the worst stability and should not rank first solely because it reached 41 ms once.

Do not make automatic selection groups overly sensitive

mihomo and compatible Clash configurations can use a url-test strategy group to select a low-latency node periodically. The configuration below checks every 300 seconds and uses a 50 ms tolerance to reduce unnecessary switching:

proxy-groups:
  - name: Auto
    type: url-test
    proxies:
      - HK-A
      - HK-B
      - SG-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

rules:
  - DOMAIN-SUFFIX,github.com,Auto
  - MATCH,Auto

tolerance: 50 does not increase speed. It prevents two similarly performing nodes from switching back and forth because of a fluctuation of a few dozen milliseconds. Frequent switching can interrupt existing connections and affect login sessions, downloads, and video buffering. Choose a test URL that is stable, has a small response body, and is reachable in practice. Change the test URL and the numbers will change too.

Dimension 2: The traffic multiplier controls plan usage, not speed

The traffic multiplier is a billing coefficient. A node labeled 0.5x, 1x, 1.5x, or 2x generally means that 10 GB of actual traffic deducts 5 GB, 10 GB, 15 GB, or 20 GB from the plan, respectively. Check the subscription provider’s documentation for the exact billing method, but the core idea is the same: the multiplier affects traffic cost, not bandwidth or latency directly.

A low-multiplier node may be fast, or it may become congested during peak hours. A high-multiplier node may use a better international route, or its higher cost may simply reflect regional resource prices. Never interpret “2x” as “twice the speed.” To judge whether a multiplier is worthwhile, return to the actual task: if a 30 GB file takes 20 minutes on a 1x node and 16 minutes on a 2x node, the extra 30 GB deducted from the plan is usually not worth it unless time is critical.

Split strategy groups by task

A safer approach is to separate low-multiplier nodes from high-quality nodes. Choose the low-multiplier group manually for high-volume tasks, and use the stable-route group for meetings, remote terminals, or important uploads. Rules can send each type of traffic to the appropriate group, so you do not have to search through dozens of nodes every time.

proxy-groups:
  - name: Bulk-Traffic
    type: select
    proxies:
      - HK-LowRate
      - SG-LowRate
      - DIRECT

  - name: Stable-Line
    type: select
    proxies:
      - HK-Premium
      - JP-Premium
      - SG-Premium

rules:
  - DOMAIN-SUFFIX,example-download.com,Bulk-Traffic
  - DOMAIN-SUFFIX,example-meeting.com,Stable-Line
  - MATCH,Stable-Line

Dimension 3: Region affects exit identity and routing detours

Hong Kong, Japan, Singapore, and the United States in a node name usually describe the region where the proxy exits. The target website sees that exit address, so the region can affect search results, localized content, account risk checks, store regions, and streaming catalogs. Region also influences the broad route from your local network to the proxy entry point and then to the target server.

The nearest region is not always the shortest route, but it is a useful starting point

Users in mainland China often test nearby regions such as Hong Kong, Japan, and Singapore first. Their physical proximity often means lower average latency than nodes in Europe or North America. However, carrier peering, the entry-point location, and route scheduling can create major detours. A local connection to a Hong Kong node may first travel through another region and end up with higher latency than a Tokyo node. Use the map only to build a candidate set; always make the final choice from real tests.

• Web browsing and messaging: Prioritize stable, low-latency nearby regions, typically starting with Hong Kong, Japan, and Singapore.
• Region-restricted content: Choose the region associated with the target content, then test whether that exit actually works.
• International shopping and account sign-ins: Keep your usual region consistent and avoid switching between multiple countries within a few minutes.
• Code hosting and software repositories: Compare the actual download speed from the target site instead of relying only on the latency shown in the node panel.
• Intercontinental remote desktops: Prefer a node near the remote host and check keyboard and mouse responsiveness along with packet loss.

A node name cannot prove that content will be unblocked

A “US node” only identifies the exit region. It does not guarantee that a video platform, AI service, or app store will accept that address. Data-center IPs may be identified and restricted, and different nodes in the same region can produce different results. For these use cases, open the target service directly and verify the homepage, sign-in, playback, and quality switching instead of trusting a “streaming” label in the subscription.

Also rule out DNS-location effects during testing. If mihomo Fake-IP DNS or TUN mode is enabled, domain resolution and traffic interception work differently. When the node region is correct but the content still does not match, first check whether “Settings” → “Network” → “TUN Mode” is enabled, then inspect dns, nameserver, proxy-server-nameserver, and rule-match logs in the configuration. TUN captures more system traffic; it does not improve node quality automatically.

Dimension 4: Protocol affects compatibility and network adaptability

Protocol compatibility is a hard requirement. A node appearing in a subscription does not mean the current client core can use it correctly. The classic Clash core and mihomo support different protocol ranges, and graphical clients may bundle different core versions. If every node test times out, nodes disappear after import, or connections fail immediately, first check the client’s core type and runtime logs instead of repeatedly clicking the test button.

What to check in common protocols

A protocol name alone cannot predict every speed difference. A Shadowsocks node on an excellent route can be more stable than a congested Hysteria2 node, and the reverse can also be true. The real experience depends on the protocol implementation, server load, entry and exit routes, how the local network handles TCP or UDP, and whether the configuration parameters match.

Validate UDP protocols on the networks you actually use

Hysteria2 and TUIC rely on UDP. Good performance on home broadband does not guarantee the same result on office Wi-Fi, campus networks, hotel networks, or mobile hotspots. Some networks restrict UDP, shorten session lifetimes, or shape high-frequency UDP traffic. Typical symptoms include test timeouts, disconnections after a few seconds, pages that open only intermittently, and failed sustained transfers.

The verification method is straightforward: on the same network, test one TCP-based node and one UDP-based node, play a video continuously for 10 minutes, and transfer a test file of roughly 500 MB. If the UDP node repeatedly drops to zero while the TCP node remains stable, make the TCP node the default fallback for that network. Test again on a mobile hotspot; the results may be completely different.

Combine all four dimensions into one selection workflow

Step 1: Remove incompatible candidates

After updating the subscription, open “Proxies” → “Strategy Groups” and check that all nodes appear. Test the candidates and open the core logs to look for unsupported, timeout, TLS handshake failures, DNS resolution failures, and similar messages. Remove nodes that fail to establish a connection across three consecutive rounds, so they do not interfere with automatic selection groups.

Step 2: Lock the region to the task

For general browsing, keep two or three nearby regions such as Hong Kong, Japan, and Singapore. For region-restricted content, keep only the target region. Do not leave 20 or 30 nodes for latency figures to sort out, because different regions serve different purposes. Create groups such as Daily, Streaming-US, and Development to separate region and use case explicitly.

Step 3: Calculate the multiplier budget

Suppose the plan has 120 GB remaining and 20 days left in the month, giving an average daily budget of about 6 GB. If you use a 2x node long term, transferring 3 GB per day consumes about 6 GB from the plan; a 25 GB system image download could deduct about 50 GB. In this situation, use low-multiplier nodes for downloads and reserve stable high-multiplier routes for meetings, remote connections, and urgent tasks.

Step 4: Test real workloads after latency screening

1. Run three consecutive speed tests and keep the 3–5 nodes with the lowest variation.
2. Open your usual websites and check whether the initial connection and subsequent navigation feel smooth.
3. Play a 1080p video for at least 10 minutes. This typically requires a sustained 8–12 Mbps, depending on the platform’s encoding.
4. For 4K, check whether the node can sustain about 25 Mbps or more, and watch for repeated quality drops.
5. Download a 500 MB–1 GB file and record whether the speed remains stable, rather than noting only the peak.
6. Retest during your actual usage hours and move nodes that slow down throughout peak periods to the backup group.

Ideally, keep one primary node and one backup node on a different route or protocol. The primary handles everyday traffic; switch manually when it times out, loses packets, or cannot access the target service. An automatic fallback group can also provide availability fallback, but changing nodes does not preserve every existing connection. Downloads or sessions in progress may still reconnect.

Combination recommendations for four common scenarios

Web browsing and messaging

Prioritize stability, latency, multiplier, and region, in that order. Start with nearby nodes measuring 50–120 ms and less than 40 ms of variation across three rounds, with a multiplier around 1x. There is no need to chase the newest protocol as long as the current network and core connect reliably. Frequent region switching may instead trigger additional website verification.

Streaming and long-form video

Prioritize regional availability, sustained throughput, multiplier, and latency. Confirm that content for the target region plays first, then watch for quality drops or buffering over 10–20 minutes. The difference between 80 ms and 130 ms usually matters less than stable 30 Mbps versus fluctuating 5–60 Mbps. Calculate the multiplier before heavy viewing so a few 4K videos do not quickly consume the plan.

Remote development, SSH, and remote desktops

Prioritize variation, packet loss, latency, and protocol. Terminal input does not require high sustained bandwidth, but it is highly sensitive to latency jumping from 80 ms to 800 ms. Choose a node with stable three-round results and no resets on long-lived connections. On a corporate network, keep a TCP-based backup node ready for a quick switch when UDP is restricted.

Large downloads and cloud-drive sync

Prioritize multiplier, sustained throughput, stability, and latency. Start with a 0.5x or 1x node and run a transfer test above 500 MB. A node with 150 ms latency that steadily maintains 20 MB/s is usually better for large files than a 50 ms node whose speed repeatedly swings between 1 and 30 MB/s.

Common mistakes to avoid

• Testing only once: A single result can be skewed by DNS caching, connection reuse, and momentary congestion.
• Treating the multiplier as speed: It is a billing coefficient, not a bandwidth multiplier.
• Assuming a region name guarantees access: Whether the target platform accepts the exit address must be verified in practice.
• Assuming a newer protocol is always faster: Protocol is only one part of the link; the route and load are often more important.
• Assuming a new speed test after enabling TUN is enough: TUN changes the scope of system traffic interception; it does not fix a congested node.
• Switching strategy groups too often: Automatic switching can interrupt long-lived connections, so use conservative tolerance and test intervals.
• Ignoring usage hours: A node that tests quickly at 3 AM may perform completely differently during the evening peak.

There is no permanently correct answer when choosing nodes. Network entry points, server load, and routes to target sites all change. A more effective approach is to keep a consistent checklist: verify protocol compatibility first, match the region to the task, control cost with the multiplier, use latency for shortlisting, and confirm the final choice with real workloads. Even when subscription node names and counts change, this lets you identify a primary and fallback node again within minutes.