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

Start with your use case, then compare four factors

Pick two or three candidates from your subscription first; don’t set the top result in the latency list as your permanent default. Everyday browsing, sustained downloads, region-restricted services, and remote access all have different network requirements. A node that quickly reaches a speed-test URL won’t necessarily perform just as well with every site you use.

The Clash client displays your configuration and lets you switch policies. The Clash or Clash Meta (mihomo) core establishes proxy connections and applies rules. Node names, multipliers, and location labels come from your provider; the core doesn’t verify that they’re accurate or choose the most data-efficient route based on your plan balance.

Factor	What to check	Common pitfall
Latency	Repeated test results, failures, and real-world responsiveness	A single low reading doesn’t mean it’ll be stable all day
Multiplier	Provider billing rules and remaining data	A higher multiplier doesn’t mean higher speed
Location	Actual exit IP and how the target service identifies it	A node’s name may not match its actual exit location
Protocol	Core support, network restrictions, and server implementation	Protocol names aren’t a reliable performance ranking

How to read latency: look at variability, not just the lowest ping

Client latency tests aren’t download speed tests

A typical proxy latency test measures how long a request takes when routed through a proxy to a specified URL. The test URL, connection reuse, DNS cache, core implementation, and how the client reports results can all affect the reading. This isn’t the same as pinging a server with ICMP, and you can’t use an 80 ms reading in the dashboard to calculate download speed.

When comparing nodes, use the same test URL, timeout, and local network. Run one round of tests, wait about 30 seconds, then repeat; record at least five results. Don’t download large files at the same time. Congested local Wi-Fi or a saturated upload can also make a node seem inconsistent.

Check the median: Sort five results and use the middle value, so one unusually low reading doesn’t skew your choice.
Check variability: A node that jumps from 70 ms to 900 ms may feel less responsive than one that stays around 180 ms.
Count failures: Don’t treat a timeout as 0 ms. Record it as a failure and count failures separately.
Test at different times: Run one test during the workday and another during the local evening peak, keeping conditions the same.

Use actual results, not just “it feels fast”

These sample results illustrate how to compare nodes; they aren’t measurements of real routes by this site. Node A returns 62, 65, 71, 680, and a timeout across five tests. Node B returns 165, 172, 178, 181, and 190 ms. A has lower successful readings, but also one timeout and a major spike. For web forms, remote desktops, and frequent API requests, B is usually the more promising candidate to test further.

Next, verify performance with the apps and services you actually use: open three familiar pages, sign in once, watch video for ten minutes, or keep a remote session open for fifteen minutes. If the test URL works but an app doesn’t, the cause may be the target site’s restrictions, exit IP reputation, routing rules, or location detection—not simply “high node latency.”

How traffic multipliers work: check your plan’s billing rules

A multiplier is usually a billing label set by the provider, not a standard performance metric in the Clash core. If your provider deducts plan data by multiplying measured traffic by the node’s multiplier, then 1 GB of billable traffic on a 2× node deducts about 2 GB from your allowance; on a 0.5× node, it deducts about 0.5 GB. This only applies if your provider actually uses that formula.

Plan data deducted = provider-measured billable traffic × node multiplier

10 GB billable traffic × 0.5× = 5 GB deducted
10 GB billable traffic × 1×   = 10 GB deducted
10 GB billable traffic × 2×   = 20 GB deducted

Actual deductions may also depend on upload traffic, protocol overhead, reporting intervals, and the difference between GB and GiB. Check your plan dashboard for the provider’s rules and usage records; client connection statistics aren’t necessarily the same as your bill. Labels such as “standard,” “dedicated,” and “high-speed” don’t follow a universal billing standard either.

Low-multiplier nodes suit heavy usage, but still check stability

Video, system updates, and cloud downloads: test low-multiplier routes first and make sure sustained throughput meets your needs.
Browsing, messaging, and code hosting: data use is usually low, so prioritize connection reliability and responsiveness.
Region-specific services: confirm the exit location works first, then compare multipliers. Saving data won’t help if you can’t access the service.

Suppose a 2× route reaches 12 MiB/s while a 1× route reaches 8 MiB/s. That’s a trade-off between speed and data allowance, not proof that the faster route is always better. For background downloads, taking longer may be worth it; for an urgent file, a higher-multiplier route may make sense for a short time. Speed tests also use your data allowance, so there’s no need to repeatedly download test files several gigabytes in size.

Choosing a node location: verify the exit, not just the name

A node labeled “Hong Kong,” “Japan,” or “US” may indicate its exit location—or simply a product group. The entry point, cross-border route, and final exit can all be in different places. A nearby entry point doesn’t mean the exit is nearby, and low latency to the entry point doesn’t guarantee a short end-to-end route to your destination.

Select a candidate node manually, then check the connection panel to confirm the test site used that node—not DIRECT or another policy group.
Check your public exit IP through that connection. Note the IP address, geolocation database results, and network operator.
Open the service you actually need and check its content, location prompts, and sign-in results. Treat database labels as a guide, not a guarantee.
Reconnect and check whether your exit changes. Dynamic exits may work for everyday browsing, but can trigger unfamiliar-location sign-in checks.

Region-restricted services may also check IP type, account region, payment details, or device location. An IP database labeling an address as “Japan” doesn’t guarantee every service will recognize it as Japanese—or allow access from it. Switching regions in the client only addresses one part of the network requirements.

Comparing protocols: check core support and network conditions first

A protocol determines how a connection works and some of its transport characteristics, but performance also depends on server load, entry-point bandwidth, routing, congestion control, and client device capabilities. Don’t treat protocol names as speed tiers. Two routes using the same protocol can perform more differently than routes using different protocols.

Protocol	What to verify	What matters when choosing
Shadowsocks	Encryption method, plugins, and core support	Matching configuration and a stable route
Trojan	TLS, server name, and certificate settings	Successful handshake and valid certificate checks
VLESS	Transport method, TLS, or REALITY settings	Use a core that supports the required features
Hysteria2	UDP reachability, authentication, and TLS settings	Whether a connection works on restricted networks
TUIC	UDP reachability and server-client compatibility	Stable sessions and device resource usage

Hysteria2 and TUIC use QUIC-based transport, which relies on UDP. They may fail to connect on public Wi-Fi or corporate networks that restrict UDP; that doesn’t mean every node in your subscription is broken. Keep a TCP-based route as an alternative and test both on the same network.

For nodes using VLESS, Hysteria2, TUIC, and other protocols, check that your specific core supports them. Seeing a node name in the client doesn’t mean the current core can load all its protocol settings correctly. Check the core name, configuration logs, and error messages; don’t assume older Clash builds and mihomo have the same capabilities. Before upgrading, see the client comparison guide and back up your current configuration.

UDP transport at the protocol level and whether an app sends its traffic over UDP through the proxy are two separate things. For example, proxying a game’s UDP traffic also depends on node capabilities, rules, and how traffic is intercepted. Enabling TUN won’t fix a server without UDP support, exit restrictions, or network congestion.

Test nodes the same way every time to avoid checking the wrong proxy route

Step 1: Lock in the policy group and test route

In the client’s node panel, switch the relevant policy group to manual selection. If it’s still using url-test to select automatically, the node you record may change during testing. Check the destination domain, matched rule, and proxy chain in the connection panel to confirm the request actually went through your candidate node. You can leave rule mode enabled, but make sure the test domain matches the expected policy.

The system proxy only affects apps that use that setting. Terminal commands don’t necessarily follow your browser’s proxy settings, so specify the local HTTP or mixed port explicitly. The examples below assume the client listens on 127.0.0.1:7890. First check port or mixed-port in your current configuration; if the port differs, update the command accordingly.

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 \
  --max-time 20 \
  --output /dev/null \
  --silent --show-error \
  --write-out "HTTP=%{http_code} TTFB=%{time_starttransfer}s TOTAL=%{time_total}s\n" \
  https://www.example.com/

This command example works in common Unix shells and uses a reserved example domain. For a real comparison, substitute an HTTPS page you regularly use and are allowed to access. In Windows PowerShell, use curl.exe and enter the command on one line, changing the output target to NUL. Specifying a proxy only routes the request to your local proxy port; the final exit still depends on the core’s rules, so check the connection panel too.

time_starttransfer measures the time from the start of a request until the first byte arrives, including connection setup and other stages. time_total measures the entire request. These aren’t exact reproductions of the client’s node latency readings; they’re an additional way to verify the route used by a real request. An HTTP 403 means the request may have reached the destination but was denied. Don’t treat every non-200 response as a broken proxy connection.

Step 2: Record a complete comparison

Use the same device, network, and test URL, and pause other bandwidth-heavy tasks.
For each node, record five latency results, the number of failures, the multiplier, and the actual exit location.
Test the same apps for 10 to 15 minutes, noting interruptions, reconnects, and sign-in issues.
Repeat during the evening peak. Keep nodes that perform reliably; don’t rank them by a single peak result.

If every candidate fails, first check your subscription balance, whether the configuration is enabled, the local listening port, and your network connection. Then check DNS and rules. If only your browser or only your terminal fails, start by checking the proxy entry point. See Troubleshooting for more help. Don’t change DNS, TUN, rules, and nodes all at once, or it’ll be hard to tell what fixed the problem.

Keep three types of nodes: everyday, region-specific, and backup

Once testing is done, you usually don’t need to save dozens of routes. Choose one reliable node with a suitable multiplier for everyday use, keep one exit that you’ve verified with the region-specific service you need, and select a backup with a different entry point or network path. Confirm the backup works independently on your current network.

Everyday browsing: Prioritize consistent responsiveness and a reasonable multiplier. Don’t switch constantly to shave off a few dozen milliseconds.
Video and downloads: Prioritize sustained throughput and data usage, not just quick-request latency tests.
Remote work: Prioritize stable long-lived connections and a consistent exit location. Check your current exit before important tasks.
Backup for restricted networks: Keep a verified alternative that uses a different transport—not just another name for the same route.

For automatic switching, url-test selects nodes based on test results, while fallback generally tries available nodes in list order. Both depend on the test URL being reachable; neither accounts for traffic multipliers, account region restrictions, or sign-in status. load-balance distributes connections according to its configured strategy; it doesn’t combine every node’s bandwidth for a single download. For services that depend on a specific exit, manual node selection is easier to control.

After updating your subscription, recheck node names, multipliers, and policy group selections. Nodes may be removed, renamed, or moved to a different exit. The best setup isn’t a single winner with the lowest latency, but a set of nodes with clear roles, predictable costs, and verifiable routes. If performance changes, repeat the same tests to distinguish local network issues from route load or target service behavior.