How to Choose Clash Proxy Nodes: Latency Tests, Traffic Multipliers, Locations & Protocols

Choose nodes in order: check availability first, then compare stability and cost

After importing a subscription, the node list may show locations, traffic multipliers, route labels, and protocol names. Clash GUI clients display this information, but node names are usually set by the subscription provider—not verified route reports from the core. When choosing a node, first confirm that it can reach the service you need. Then compare latency variation, sustained transfer performance, and traffic costs. This is more reliable than simply clicking the entry with the lowest millisecond reading.

1. Check the configuration and mode: Enable the imported configuration and use Rule mode. Make sure the rule for the site you want to test points to the policy group you intend to use.
2. Keep the shortlist small: Start with three nodes across two locations or route types. Avoid testing hundreds of nodes at once.
3. Repeat the latency test: Test five times on the same network and against the same URL. Record failures and the typical result rather than looking only at the best run.
4. Test real-world tasks: Open a frequently used site, stream a video, or transfer a file of known size. Check sustained speed and whether the connection drops mid-transfer.
5. Set up a primary and backup: Choose one everyday node and keep a backup on a different route. Test again during the evening peak.

Clash latency tests: what the millisecond reading measures

Common latency tests in Clash and mihomo send an HTTP request to a test URL through the selected proxy; they do not run a standard ICMP ping to the node server. Results can be affected by establishing the proxy connection, route round-trip time, the destination’s response, caching, and connection reuse. Exact timing depends on the core and client implementation.

An 80 ms reading therefore indicates a quick response from that node along this test route, but it does not mean downloads will be fast or that other sites will respond just as quickly. The test can time out if the URL is unreachable, DNS resolution fails, or node authentication is invalid. A client’s timeout means this test failed; check the logs to find out why.

Use the same URL and network; compare five results

URL-test groups often use an endpoint that returns a small response, such as https://www.gstatic.com/generate_204. When comparing two nodes, keep the test URL, Wi-Fi network, and rules configuration the same. The figures below are hypothetical examples to show how to interpret results. They are not test results from this site and do not represent the performance of any subscription service.

Messaging and interactive sites generally benefit from consistent response times, so Candidate A is a better first choice than Candidate B, which looks appealing only if you focus on its lowest result. Large-file transfers also depend on throughput: Candidate C may sustain higher speeds if it has more available bandwidth, despite its higher latency. Five tests are useful for an initial screen, but they cannot establish long-term reliability.

How URL-test group settings work

The mihomo policy group snippet below uses url-test to compare two existing nodes. It is valid only if HK-01 and JP-01 are already defined in your configuration. Replace them with the exact node names from your subscription, then add the group to the existing proxy-groups list.

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

• interval: 300 sets the test interval to 300 seconds. Settings such as lazy loading can affect whether a test runs immediately.
• tolerance: 50 sets the switching tolerance. It helps prevent frequent switches caused by small latency changes; it is not a node timeout limit.
• Automatic selection is based on latency to the test URL. It does not assess video availability, account risk controls, or download throughput.

GUI clients may manage policy groups through subscription overrides or enhanced configurations. Direct edits to a downloaded subscription file may be overwritten the next time it updates. Check how your client handles local overrides before saving a custom test group. For information on referencing policy groups in rules, see the rule-based routing guide.

Traffic multipliers: how node labels affect subscription usage

Labels such as 0.5x, 1x, and 2x in node names usually indicate the provider’s billing multiplier. They are not speed tiers in the Clash core or bandwidth multipliers. 2x does not mean twice the speed, and 0.5x does not mean half the transfer rate. The provider’s backend determines how traffic is billed; check its documentation and your account usage for the final figures.

Estimate costs from actual data usage

Suppose a provider explicitly states that the combined upload and download volume is multiplied by the node’s rate. Transferring 4 GB would then use about 2 GB of allowance at 0.5x, 4 GB at 1x, or 8 GB at 2x. These estimates use the same units throughout. Displayed usage may differ depending on whether the backend uses decimal GB or binary GiB, as well as on its measurement method.

• Long video sessions and system updates: Compare the sustained throughput of standard-multiplier nodes first. Reserve higher-multiplier routes for tasks that genuinely need them.
• Occasional access to region-specific services: Create a separate manual-selection group so that all traffic does not go through a high-multiplier node.
• Node labels don’t match the account panel: Refresh the subscription and check the provider’s announcements. Don’t assume an old label reflects current billing.

Location labels: ingress, exit IP, and the service you’re accessing

“Hong Kong,” “Japan,” or “United States” may indicate the exit location—or simply be a marketing label for a route. With some relayed nodes, the connection enters in one location and exits to the internet in another. The server address shown by the client alone cannot confirm where the destination site sees your IP.

Verify the exit with the target service, not just the flag

1. Manually select the candidate node in the policy group used for the target site.
2. Close existing connections and reopen the page. If needed, fully quit and restart the app to avoid reusing an existing session.
3. Check the exit IP and location with a reputable IP lookup service, then test access to the actual target service.
4. If the results don’t match, consider an outdated IP geolocation database, account region, payment details, or restrictions imposed by the service itself.

A location match does not guarantee that a service will work. The server may detect data center IPs, require the account’s region to match, or limit requests from a shared exit. DNS settings can also affect service routing, but changing DNS cannot turn one exit IP into an address in another country. For accounts that need a consistent login region, keep the exit relatively stable and avoid automatic groups that switch between countries.

“Dedicated route,” “relay,” and “direct” also mean different things. A direct node typically connects from your local network straight to the remote server. A relay adds a forwarding hop, while the scope of a dedicated route depends on the provider’s plan. Labels do not prove the full end-to-end route; check for congestion, detours, and packet loss by testing real tasks at different times.

Protocols: compatibility, UDP, and battery life on mobile devices

Clash GUI clients provide the interface and configuration management, but protocol support depends on the core they run and its version. The original Clash and Clash Meta (now called mihomo) have different capabilities. Converting a subscription does not add protocol implementations missing from an older core. If you see a configuration error such as “unknown proxy type,” note the core version and check protocol support before repeatedly switching to nodes of the same type.

Protocol names don’t rank speed

Protocol performance depends on server load, network quality, congestion control, transport encapsulation, and device processing power. Two nodes using the same protocol can perform very differently. Hysteria2 or TUIC may fail to connect on networks that restrict UDP, but work well on others. Games, voice calls, and other UDP apps also require the node, policy, and local network setup to handle that traffic. A working browser connection alone does not prove that the UDP route is working.

Compare battery use with the same task

Encryption isn’t the only factor in phone battery use. Weak signal, repeated retransmissions, frequent tests, background connections, and large data transfers all increase power consumption. TUN mode captures network traffic; it is not a proxy protocol. It may route more app traffic through the proxy core, so any change in battery life cannot be attributed solely to the selected node protocol.

• Use the same Wi-Fi, similar screen brightness, and the same task—for example, play a video at the same quality for 20 minutes.
• Turn off unnecessary frequent tests to reduce their impact on mobile data and battery life.
• Check your system’s battery stats and device temperature. Short-term changes in battery percentage are only a rough guide.
• If only one node causes noticeable heat or drops, check reconnection logs and server load before deciding whether to switch protocols.

Test real throughput: local proxy ports and reproducible results

A low latency reading in the client is not enough to measure sustained download speed. First check response times on sites you commonly use, then test throughput with a short transfer of a fixed size. Pause system updates and other downloads during the test. Record the network, time, node, multiplier, and task, then repeat the same test during the evening peak.

Check requests through the local HTTP proxy

If the configured mixed-port is actually 7890, use the command below to access the example site through the local proxy. On Windows, explicitly run curl.exe; on macOS or Linux, use curl in most cases. If the port isn’t 7890, replace it with the value shown in your client.

curl -x http://127.0.0.1:7890 -o /dev/null -sS \
  --connect-timeout 10 --max-time 30 \
  -w "connect=%{time_connect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" \
  https://example.com/

The command above is for macOS and Linux. On Windows, use this one-line version:

curl.exe -x http://127.0.0.1:7890 -o NUL -sS --connect-timeout 10 --max-time 30 -w "connect=%{time_connect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

Here, time_connect mainly measures the time to connect to the local HTTP proxy; it is not the latency to the remote node. time_starttransfer includes several stages before the first byte arrives. This checks a small request, not bandwidth, and the core still chooses the outbound route according to its rules. Check the Connections page to confirm which policy group handled the domain.

Use consistent units to avoid misreading speeds

Download tools often show MB/s, while network bandwidth is usually expressed in Mbit/s. In decimal units, 10 MB/s is about 80 Mbit/s. A 100 Mbit/s connection has a theoretical equivalent of 12.5 MB/s, though protocol overhead and network bottlenecks reduce real-world speeds. When testing a large file, look at the sustained rate rather than the initial peak just after the connection starts.

Common issue: normal latency, but sites won’t load

A simple record can make everyday node selection easier: node name, exit location, multiplier, five latency results, real-world task results, and test time. Use the data to rule out failed or highly variable nodes, then keep a primary and backup for each use case. For client installation and connection setup, see the proxy connection guide. If policy groups and TUN are unfamiliar, start with the glossary.