How to Choose a Clash Proxy Node: Latency, Traffic Multipliers, Regions & Protocols

Check the actual route first, then compare node metrics

Latency, region, and traffic multiplier describe different things in a Clash proxy list. Latency measures how long a probe takes; region usually refers to the provider-labeled exit location; and the multiplier affects how much traffic is deducted from your subscription. None is a substitute for the others. When choosing a node, first identify the exit location your target site requires, then check availability and stability, and finally compare speed and usage costs.

If a node test looks fine but webpages are still slow, first check whether the page’s traffic is actually routed through that node. In mode: rule, rules are matched in order, and a rule can point to a policy group or to DIRECT. Switching a policy group that the current request doesn’t use won’t change its route.

1. In the client’s Connections view, find the connection for the target domain and check the matched rule, outbound route, and policy group.
2. Make sure you’re changing the group used by this route, not a similarly named group.
3. Reconnect after switching nodes. Existing TCP connections usually don’t migrate automatically when you change the selection.
4. Pause background downloads and cloud sync before comparing nodes, so competition for local bandwidth doesn’t skew the results.

Latency tests: an HTTP probe isn’t a download speed test

A typical client latency test sends a request through a selected proxy to a test URL and records how long the probe takes. It isn’t simply an ICMP ping to the proxy server. Results can be affected by the node connection, TLS handshake, test site response, local network, and connection reuse. Implementation details can also vary between cores and clients.

For a useful comparison, keep the test URL, network, and time of day consistent. Ranking 80 ms from one client against 110 ms from another usually isn’t an apples-to-apples comparison. A single “timeout” only means that this probe didn’t finish before the deadline; on its own, it doesn’t prove that every website is unreachable.

Repeat tests to compare latency and stability

The data below illustrates how to interpret results; it isn’t a measurement from this site. Test each node five times, about 10 seconds apart, under the same network conditions.

Web browsing and interactive use are more sensitive to round-trip time and failures; large downloads depend more on sustained throughput. Node A’s 60 ms doesn’t mean it will download faster than node C. Sustained speeds also depend on route capacity, shared load, server-side throttling, and the destination site. Variation in probe results isn’t a formal measure of network jitter, nor can it be used to calculate packet loss across the whole route.

Test downloads and video separately

• Use the same trusted download source for about 30–60 seconds and check the sustained speed, not just the initial peak.
• Distinguish MB/s from Mbps: at the theoretical conversion rate, 10 MB/s is about 80 Mbps, before protocol overhead.
• For video, check startup time, buffering, and the connection speed shown by the player. A successful load once doesn’t guarantee reliable playback during peak hours.
• Speed tests use traffic. Check your remaining quota and the node’s multiplier before testing with large files.

Traffic multipliers: how providers calculate usage

A traffic multiplier is part of a subscription provider’s billing policy, not a universal local billing switch in Clash. Clash and mihomo don’t have a standard node ratio field that lets the client change what your provider deducts from your account. “2×” in a node name is only a hint; check the provider’s node details, bill, and account usage records for the actual terms.

A common formula is “traffic counted × node multiplier.” Suppose the provider counts combined uploads and downloads: 8 GB downloaded plus 2 GB uploaded gives a 10 GB base total. A 0.5×, 1×, or 2× node might then deduct 5 GB, 10 GB, or 20 GB, respectively. These examples use the same unit throughout. Check whether the platform uses GB or GiB, how it rounds, and whether rates vary by time.

Convert the multiplier into an estimated usage budget

• With 100 GB left in your account, sustained use of a 2× node would allow about 50 GB of base traffic under the same accounting method.
• A 0.5× multiplier doesn’t guarantee slower speeds, and 2× doesn’t guarantee double the bandwidth. Multipliers describe billing, not performance.
• For long video sessions, large downloads, and device backups, check your quota first. For a brief login or access from a specific region, first confirm that the service works.
• Traffic totals in the client may differ from provider deductions. Differences in what’s included, the measurement period, and protocol overhead can all affect the numbers.

Choosing a region: assess exit location and route quality separately

A node’s region usually refers to its public-facing exit location, which may differ from the physical location of the subscription’s server address. The entry point, relay, and exit can all be on different networks. Nearby locations such as Hong Kong, Japan, and Singapore can be useful starting points, but geographic distance doesn’t account for cross-carrier routing, peak-hour congestion, or exit quality.

Set filters based on how you’ll use the node

A website may use its own IP geolocation database and may also check your account region, billing details, and device location. An IP lookup showing one region doesn’t mean every platform will identify it the same way. Test the service you need directly; a matching region label doesn’t guarantee access.

Choosing a protocol: check core compatibility, then network performance

Protocols determine how connections work and what they can do, but they can’t be ranked independently of the network route. Support for protocols such as Shadowsocks, Trojan, VMess, VLESS, Hysteria2, and TUIC depends on the core in use. mihomo supports a different set of protocols from legacy Clash cores, and clients with similar interfaces don’t necessarily use the same core.

If importing a node produces an error such as “unsupported proxy type,” first check the node’s type and the client’s actual core instead of repeatedly changing the test URL. If you need a different client, start with the client selection guide, then choose the right platform on the download page.

UDP, system proxy, and TUN: what each covers

• Hysteria2 and TUIC rely on UDP for transport. If your current network restricts UDP, they may fail to handshake or behave unreliably, while TCP-based connections may still work.
• For supported node types, udp: true allows UDP forwarding. It can’t give the server or local network UDP capability they don’t have, and it doesn’t apply to every protocol type.
• A standard HTTP system proxy mainly serves apps that honor proxy settings. It doesn’t mean a game’s or voice app’s UDP traffic is being proxied.
• TUN takes over traffic at the virtual network adapter level, but routing, rules, DNS, and permissions still need to be configured correctly. Enabling TUN doesn’t increase the bandwidth allocated to your node by the provider.

On the same route, protocol differences can affect handshakes, congestion handling, and resource use. Across different routes, bandwidth and load are often more significant. Choose based on connection success, real-world performance, and device load on your network—not just how new a protocol sounds.

Policy groups: manual selection and automatic testing

Use select for a fixed region or exit, or to compare nodes manually. url-test automatically selects a candidate based on probes to a specified URL. It doesn’t account for provider multipliers or check whether a video platform is available in a given region. Putting nodes for different purposes in one automatic group can produce a node that tests fast but doesn’t meet your needs.

The following is a mihomo policy group snippet, not a complete configuration. Before using it, make sure proxies contains nodes named exactly “Hong Kong-A” and “Japan-B.” If you use a proxy provider, reference it with use according to your configuration structure; don’t just copy the two node names.

proxy-groups:
  - name: Everyday selection
    type: select
    proxies:
      - Automatic latency test
      - Hong Kong-A
      - Japan-B

  - name: Automatic latency test
    type: url-test
    proxies:
      - Hong Kong-A
      - Japan-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

• interval: 300 sets the probe interval to 300 seconds; it isn’t the subscription update interval.
• tolerance: 50 sets the switching tolerance in milliseconds to prevent frequent switches over small differences; it isn’t a maximum latency for your workload.
• lazy: true enables lazy probing. The group may not be tested on schedule while unused, so an old value in the interface may not be current.
• url is the health-check target. Choose an address that’s consistently reachable; results taken before and after changing the target aren’t directly comparable.

After adding a policy group, make sure the relevant rule references “Everyday selection” for requests to use it. Back up your configuration before editing, then check the logs and Connections view after loading it. Subscription updates may overwrite direct edits to generated files. For lasting changes, use the client’s override or merge feature; its location varies by client.

Node selection checklist

1. Define your needs: Note the target site, whether you need a specific region, whether you rely on UDP, and your remaining monthly quota.
2. Choose candidates: Start with 2–3 nodes that meet your region and protocol requirements, then check their multipliers and core compatibility.
3. Test under consistent conditions: Run five probes per node on the same network and URL. Eliminate candidates that repeatedly time out or vary widely.
4. Test your actual workload: Reconnect before testing webpages, play video continuously, check sustained download speeds, and use in-game latency for games.
5. Verify the route: Check the rule and proxy route in the Connections view so you don’t mistake a direct connection for node performance.
6. Retest at peak hours: Test again during your usual usage period and keep a backup node that meets the same requirements.

For your final comparison, record just five things: node name, use case, multiplier, repeated probe results, and real-world performance. Choose based on this information you can verify, not on a single lowest-latency reading. For help with ports, rules, or DNS fields, see the configuration reference.