How to Choose Clash Nodes: Compare Latency, Traffic Multipliers, Locations, and Protocols

Check location and compatibility first, then compare latency and cost

The numbers and names in a Clash node list only tell you part of the story. Low latency does not guarantee fast downloads, a node labeled “Japan” does not guarantee that a website will see you as connecting from Japan, and a protocol name alone says nothing about connection quality. Start by identifying what you need the node for, then compare candidates under the same conditions.

For everyday browsing, focus on connection reliability and response time. For video, check whether the service works and whether throughput stays consistent. For video calls, also check UDP support, jitter, and call quality in practice. Sorting nodes by a single speed test can lead you to a connection that responds quickly once but stutters during peak evening hours.

1. Define your needs: Which exit location do you need? Does your use case depend on UDP? Does the service restrict access based on account region?
2. Check compatibility: Make sure the subscription imports successfully and your current core recognizes the node protocol and its parameters.
3. Test consistently: Compare latency and real-world performance on the same network, to the same test URL, and during the same time window.
4. Check billing: Review the provider’s traffic multiplier, usage measurement method, and remaining data allowance.
5. Keep a backup: Maintain at least one working node with a different exit location or route.

How to check latency: test the same URL three times

HTTP latency is not bandwidth or simply an ICMP ping

Clash and mihomo commonly test latency by sending a request through a specified proxy to a test URL and recording how long it takes. Results depend on the test target, DNS, connection setup, TLS handshake, and core implementation; factors such as connection reuse can also affect them. This measurement is not the same as the physical round-trip time to the proxy server.

So if client A reports 80 ms and client B reports 150 ms, that does not immediately mean A has the better node. First check that both use the same URL, timeout settings, and network. If you change the test URL, run the test again rather than relying on old results.

• Test on the same Wi-Fi or wired network, and pause downloads and cloud sync.
• Test each candidate node three times, about 10 seconds apart, and note the median and number of timeouts.
• Retest during your usual usage hours and again from 8:00 to 11:00 p.m. to avoid judging a node only under light load.
• If a test times out, retry and then visit the actual target website. A failed test URL does not mean every service is unreachable.

Track variation alongside real download performance

The figures below are examples to illustrate how to evaluate nodes. They are not tests conducted by this site and do not represent any provider. Use the same test file, where testing is permitted, and limit the number of runs because speed tests consume subscription data.

MB/s means megabytes per second; Mbps means megabits per second, so the figures differ by a factor of about 8. 12 MB/s is roughly 96 Mbps. When comparing speed-test results, make sure the units match and your broadband connection and Wi-Fi signal are not the bottleneck.

How traffic multipliers work: check the provider’s billing method

Labels such as “0.5×,” “1×,” and “2×” in node names usually indicate the provider’s traffic billing multiplier for that route. They do not mean a speed multiplier or a rate limit enforced automatically by the Clash core. These labels are just names; check the provider’s plan details and usage dashboard for the actual terms.

If a provider bills for combined upload and download traffic, the basic calculation is: Traffic deducted = (uploaded data + downloaded data) × node multiplier. For example, downloading 10 GB and uploading 0.2 GB on a 2× node uses about 20.4 GB of your allowance; on a 0.5× node, it uses about 5.1 GB. Actual totals may also depend on reporting delays, unit conversions, and how the provider measures usage.

• Large downloads and system updates: Look for a route with enough sustained throughput and a lower multiplier.
• Browsing and messaging: These usually use little data, so prioritize responsiveness and reliability.
• High-multiplier routes: The extra data cost is worthwhile only if the route measurably improves the service you need.

Note your current usage in the provider’s dashboard, run a controlled download of about 200 MB, then check the deduction after usage statistics refresh. Do not expect an exact match between client session traffic and your plan balance: they may measure different things, and the dashboard may update later.

Choosing an exit location: check how the target service sees it

A node name may refer to its entry location, exit location, or a provider-defined route. With a route labeled “Hong Kong relay, Japan exit,” the server your client connects to first may not be in Japan, but the target website will usually see the final exit IP. If you need access from a particular location, verify the exit rather than relying on the node name.

Verify the location and service access in three steps

1. Manually select a candidate node in the proxy group to prevent an automatic group from switching routes during your checks.
2. Use an IP lookup page to check the exit address and location, and confirm in the connection log that the lookup went through the intended node.
3. Open the actual service and check sign-in, playback, or the specific feature you need—not just whether the home page loads.

IP databases can disagree about a location. Video, payment, and some other online services may also consider your account’s registration region, payment method, device location, and risk checks. An IP lookup showing a particular region does not guarantee that every service will accept it.

An exit location nearby often means lower latency, but detours, congestion between networks, and relay paths can change the result. For video calls, try a nearby location first. For services with a specific location requirement, meet that requirement before comparing latency. For accounts you use regularly, keep the exit location relatively consistent and avoid unnecessary region changes.

Comparing protocols: check core support, then network fit

Clash is a common name in the client ecosystem, but protocol support depends on the core actually running and its version. Clash Meta continued development under the name mihomo, but having a graphical client does not guarantee that its core supports every protocol in your subscription. Before troubleshooting, note the full version number from the client’s About or core information screen, then check the documentation for that version.

The same protocol can run over very different routes, and a good route may offer several protocols. Evening congestion, server load, and network peering often explain real-world performance better than the protocol name. Do not assume that a “newer protocol” is automatically “faster on every network.”

After choosing a node: verify rule matching and backup routes

In rule mode, manually selecting a node in the “Proxy” group affects only connections that actually use that group. Video, downloads, or specific domains may be handled by other proxy groups or match DIRECT. If the exit does not change after switching nodes, check the connection details for the domain, matched rule, and policy chain before reimporting the subscription.

Four checks after switching nodes

1. Traffic capture: Make sure the system proxy is enabled or turn on TUN if needed. Some apps do not use the system proxy settings.
2. Policy chain: Open the target website, find its connection in the connection list, and check the final node name.
3. Reconnect: Existing long-lived connections may keep using the old node. Send a new request and, if needed, close the old connection before testing again.
4. Test the service: Check page loading, the target service, and any required UDP features—not just the speed-test button.

It also helps to understand how automatic groups choose nodes: url-test primarily selects based on latency to a specified URL, subject to tolerance and test settings; fallback selects the first candidate in the configured order that passes its health check. Neither means “automatically choose the fastest download speed,” and neither checks traffic multipliers or regional eligibility.

For everyday use, keep two verified routes: one as your regular node and another with a different exit or upstream as a backup. Nodes with different names but the same underlying route may not provide meaningful redundancy. After updating your subscription, check node names and group selections so a removed node is not silently replaced by an unexpected route.

Use this order when choosing a node: target service works → reliable connection → acceptable response time and throughput → reasonable traffic multiplier. Keeping notes on the test date, network, three latency results, and actual use case makes long-term comparisons more useful than saving a screenshot of the lowest latency. For further troubleshooting, see the connection troubleshooting guide and the custom rules guide.