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

Start with your use case: node rankings don’t predict real-world performance

Names in a Clash node list often combine location, route, protocol, and traffic multiplier details. These names are supplied by the subscription provider; they are not proof that a route has been independently verified. When choosing a node, first identify the location your target service requires. Then check connection stability and traffic costs, and compare latency and throughput.

Clash is a common name for a family of proxy clients and core implementations. Clash Meta is now maintained under the name mihomo, and bundled cores vary by client. Successfully importing a subscription only means the configuration was accepted. Seeing nodes in the list does not guarantee that the current core supports every protocol or transport setting they use.

Don’t change the node, DNS, TUN, and routing rules all at once. Change one variable at a time to see what made a difference. The figures below illustrate how to evaluate and calculate; they are not measurements by this site or performance guarantees for any route.

Latency tests: look at the measurement path, not just the milliseconds

URL tests and ICMP ping are not the same

In many Clash clients, a node latency test asks the core to request a test URL through a selected node. The result reflects how long that proxy route takes to reach the test target. Connection reuse, DNS caching, the TLS handshake, and the client’s timing method can all affect the number. It is not simply the ICMP round-trip time between your device and the proxy server.

So the result of the system ping command is not a direct substitute for a client test. A server may block ICMP while still allowing proxy connections. The test URL may also be blocked by the node’s exit or the target site, causing a “timeout” even when other websites work. Conversely, a successful test doesn’t guarantee access to a video service or code-hosting site.

Use repeated results to spot jitter

1. Keep the network, test URL, and timeout settings consistent. Pause downloads and other bulk speed tests.
2. Test each candidate node five times, a few seconds apart, and record timeouts. Don’t keep only the fastest result.
3. Compare the median and range, then try the services you actually use.

For example, node A returns 45, 46, 48, 290, and a timeout across five tests; node B returns 72, 74, 75, 78, and 80 ms. A has the lower best result, but B is more consistent in this sample. Remote terminals and voice calls usually benefit more from that consistency. Five tests are only an initial screen, not a substitute for longer-term observation.

Traffic multipliers: calculate usage based on your provider’s billing rules

Labels such as “0.5×,” “1×,” and “2×” in node names usually refer to the subscription provider’s traffic billing multiplier. They are not speed multipliers or standard billing fields in the Clash core. The client can’t confirm the billing formula from a node name alone. Check whether the provider counts upload and download traffic, how it defines units, and whether multipliers vary by time of day.

The example below assumes the provider explicitly uses “billable traffic = measured traffic × multiplier.” The 10 GB shown is traffic measured according to the provider’s method; it may not match the file size shown in your browser.

Estimate usage before running high-volume tests

If you have 60 GB of quota left and use only 2× nodes, the simplified formula above gives you about 30 GB of measured traffic. Speed tests also use traffic. For example, downloading continuously at an average of 10 MB/s for 60 seconds transfers about 600 MB in decimal units. On a 2× node, that alone would use about 1.2 GB of quota, before any other counted traffic.

• For everyday browsing, keep a stable low-multiplier node available to avoid unnecessary quota use.
• Use high-multiplier nodes only for services that need them, rather than routing every background update through them by default.
• The client’s connection panel shows observed traffic. Use your provider’s billing page for the final balance.

Exit location: service detection matters more than the node name

Your device’s location, the proxy entry location, and the final exit location can all differ. A route named “Hong Kong relay” may not exit in Hong Kong, and “Japan” may simply be the operator’s label. Websites usually identify location from the exit IP, but may also consider account region, payment details, device location, and session history.

Check where requests actually go

1. Select a candidate node in the client and make sure the relevant policy group is using it.
2. Visit the target site and check the matching rule and policy chain in the Connections or Logs view; labels vary by client.
3. Use the same proxy route to visit an IP lookup page and check the exit address and location, then test the target service.
4. If the IP lookup page and target site match different policy groups, fix the rules first. Don’t use the lookup result to draw conclusions about the target site.

Different geolocation databases may assign the same IP to different locations. An IP lookup showing one region doesn’t guarantee that a target service uses the same database. Access failures can also stem from the shared exit’s reputation, concurrency limits, or account status—not just a location mismatch.

Protocol comparison: Trojan, VLESS, and Hysteria2

Protocol names describe connection methods and compatibility requirements, not route quality. The same protocol can perform very differently across networks. Before comparing, check the client’s core information page to see which core is actually in use, then verify the subscription’s requirements. In particular, don’t assume older Clash versions support everything mihomo does.

Trojan: check TLS settings first

Common Trojan configurations rely on TLS. Even if the server IP and port are reachable, a mismatched SNI, invalid certificate, or incorrect device clock can cause the handshake to fail. Don’t leave certificate verification disabled just to make a test pass. If the subscription uses an additional transport such as WebSocket, also confirm that the client core supports that combination.

VLESS: the protocol name doesn’t describe the whole configuration

VLESS does not encrypt traffic on its own; TLS, REALITY, or another protected environment must provide the relevant security. TCP, WebSocket, and gRPC settings are not interchangeable. With REALITY, parameters such as the public key and short ID must also match the server. Copying only the server address and UUID is often not enough to recreate a node.

Hysteria2: check UDP availability first

Hysteria2 may help on some lossy networks, but it is not necessarily faster. If your Wi-Fi, carrier, or firewall restricts UDP, performance may suffer or the connection may fail entirely. Configuring UDP 443 does not turn it into TCP HTTPS; using the same port number does not mean using the same transport. Hysteria and Hysteria2 configurations are not directly interchangeable.

Opening a website over Hysteria2 doesn’t mean games or voice calls will use the same route. Check separately whether the app uses the system proxy, whether the core handles its UDP traffic, and whether the server allows forwarding. TUN can capture more traffic that doesn’t use the system proxy, but it won’t increase the node’s bandwidth or bypass network restrictions on connections to the node.

Filter nodes in Clash: verify manually, then automate selection

For an initial shortlist, keep just three to five candidates: a low-multiplier node for everyday use, an exit in your target region, and a backup route. Select each one manually in the policy group and complete three checks—test URL, target-site access, and sustained use—before enabling automatic tests.

url-test selects nodes based only on its test target

This mihomo configuration snippet is for a setup with existing node definitions. Names under proxies must exactly match the actual nodes. This example contains no server details and cannot be imported as a complete configuration on its own.

proxy-groups:
  - name: Latency picks
    type: url-test
    proxies:
      - Everyday low multiplier
      - Regional backup
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

• interval: 300 sets the check interval in seconds. Actual scheduling also depends on settings such as whether the group is in use, so don’t treat it as a precise timer.
• tolerance: 50 is a switching tolerance in milliseconds. It helps avoid frequent switches for negligible gains; it is not a bandwidth threshold.
• The test URL must be reachable through candidate exits. The best node for that URL may not be the best for a video service or code repository.
• Automatic tests don’t interpret traffic multipliers in node names or verify account region and target-service availability.

Subscription updates may overwrite local changes. To keep policy groups over time, use the client’s supported override or merge features, and check the client documentation for processing order. For basic rule syntax, see the Clash configuration guide.

FAQ: timeouts, lag, and node switching issues

Low latency, but video still buffers?

First check which node actually handles video requests, then play continuously for a few minutes at a fixed resolution. A latency test only requests a small target, so it can’t show sustained throughput, the video CDN route, or congestion during peak hours. If pages load normally but sustained transfers slow down, compare backup routes at the same time of day rather than repeatedly changing DNS.

Every node times out. Is the subscription no longer valid?

First confirm that your direct internet connection works, the subscription hasn’t expired, and you have quota left; then check the core logs. timeout is a result, not a root cause. connection refused usually means the connection was rejected. For certificate errors, check the TLS settings and system clock. If only Hysteria2 fails, compare it with a TCP-based node to see whether the UDP path is the issue.

Changed nodes, but the website still shows the same IP?

Check the current mode, the rule matching the target domain, and whether your browser is actually using the proxy. Connections matched by a DIRECT rule won’t change exits when you switch proxy groups. Also check whether an old connection is still being reused. Don’t turn on TUN as a substitute for checking rules; first find out where the request enters the core and which policy it ultimately follows.

What’s the best order for choosing a node?

First, meet the target location and protocol requirements, then rule out disconnects and obvious jitter. Compare multipliers and sustained speeds among the usable nodes, and use latency to narrow the list further. Keeping a verified backup exit is more useful than switching repeatedly to chase the lowest single latency result. For installation and import steps, see the Getting Started guide.