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

1. Start with your use case, then compare latency

A node shown in Clash is typically a set of parameters for connecting to a remote proxy server. A working connection doesn't make a node suitable for every task, and low latency doesn't necessarily mean fast downloads. Start by defining what you need: everyday browsing benefits from quick response times, video streaming depends more on sustained throughput and regional availability, and remote meetings also require checking jitter, packet loss, and UDP connectivity.

Filter nodes in this order: target service works → exit location meets your needs → multiplier is acceptable → stable during peak hours → low latency. Eliminate nodes that fail any must-have criteria, then compare the rest. This is more reliable than simply picking the lowest latency number.

2. Test latency repeatedly, not just the lowest result

HTTP latency isn't the same as an ICMP ping

Clash-based clients commonly check proxy availability by requesting a small HTTP or HTTPS URL and reporting the result in milliseconds. This isn't simply an ICMP ping to the server. Which stages contribute to the time depends on the core implementation, connection reuse, protocol handshake, and test URL. The result mainly reflects how that particular request performed through the proxy to the specified URL.

The same node may use different exit routes or CDNs to reach different websites. A fast response from the test URL only shows that this probe path is working well; it doesn't guarantee the same experience on video platforms, code hosting services, or remote meetings. The test URL itself may also be unreachable. If every node times out, check the test target before removing your subscription.

Keep conditions consistent and run five tests

1. Use the same device, network, and test URL each time. Pause downloads, cloud sync, and other bandwidth-heavy tasks.
2. Choose three candidate nodes and test each five times, about 10 seconds apart. Record the latency in milliseconds and the number of timeouts.
3. Compare the median and range first. Then retest during your usual hours, such as 8–11 p.m. local time.
4. Check real-world performance too: load a webpage several times, watch a video for a few minutes to check buffering, and listen for audio dropouts or packet loss during a meeting.

For example, suppose the results are A: 45, 48, 220, timeout, 190 ms and B: 80, 82, 79, 85, 81 ms. A has the lower minimum, but B is much more consistent across all five tests. For interactive browsing and meetings, B is usually the better candidate for further testing. These numbers illustrate how to compare results; they aren't measurements from a real route.

Consider latency, throughput, and jitter separately

A node with 40 ms latency may have limited available bandwidth, while one at 150 ms may transfer large files reliably. Download speeds depend on server load, congestion between networks, remote rate limits, and your local broadband connection. Throughput tests use data, so screen nodes with small tests first, then check sustained speeds on a few finalists. There's no need to run large downloads on every node.

3. Traffic multipliers: Calculate usage based on the provider's rules

“0.5x,” “1x,” and “2x” are usually billing labels set by the subscription provider, not standardized billing fields in the Clash core. A multiplier in a node name is just text; renaming the node won't change how usage is charged. Check the provider's billing rules and usage dashboard, including whether uploads and downloads are both counted, whether multipliers vary by time, and whether separate traffic pools apply.

Billable usage = billable data transferred × node multiplier

Example: 8 GB downloaded, 2 GB uploaded, with both directions counted
0.5x: 10 GB × 0.5 = 5 GB
1x:   10 GB × 1   = 10 GB
2x:   10 GB × 2   = 20 GB

This is a simplified example. Billing periods, unit conversions, and protocol overhead can cause client-side usage figures to differ from the provider's dashboard. Don't assume a billing error based on one small test. Note the dashboard reading, transfer a controlled amount of data, then check again after the dashboard updates.

• Web browsing and messaging: These usually use little data, so prioritize responsiveness and stability.
• Operating system images and large updates: First check whether they need a proxy, then compare sustained speeds on low-multiplier nodes.
• Long video sessions: Include your daily viewing in your data budget; don't focus only on whether a single playback is smooth.

A high multiplier may indicate a special route defined by the provider, or simply reflect product pricing. It doesn't guarantee bandwidth or stability. For long-term use, track performance and data deductions at the same times of day to judge whether the cost makes sense.

4. Exit location: Check what the target service sees

Names like “Hong Kong,” “Japan,” or “United States” usually indicate the expected exit location, but a node name isn't proof. The relay entry point and final exit may be in different regions, and IP geolocation databases can lag behind changes. What matters is which exit IP the target service sees and where that service locates it.

A matching location doesn't guarantee the service will work

Streaming platforms and other region-restricted services may check IP location, whether the address belongs to a data center or residential network, account region, payment details, and risk signals. A node that loads the sign-in page may not play all content; playing one title doesn't mean the entire catalog is available. Verify access against the specific service and content at the time you plan to use them, rather than relying on a node label.

1. Select a node in the proxy group used by the target service, then close the old page or end the existing connection before trying again.
2. Check the client's connection log to confirm the service's requests matched the expected rule and node.
3. Verify the exit IP location, then test the service itself—for example, by playing the content you need.
4. If the results don't match, check the account region, app location permissions, IPv6 routing, and whether any relevant domains are bypassing the proxy.

The location of a DNS resolver and the location of the final proxy exit are different things. Changing DNS servers won't automatically move the proxy exit to another country. If some requests go direct or IPv6 bypasses the expected route, fix traffic interception and routing rules first, then check the node location. For details on the relevant fields, see the full documentation.

5. Protocols: Check core support and network conditions first

Shadowsocks, Trojan, VMess, VLESS, Hysteria2, and TUIC are different protocols or protocol families, not fixed speed tiers. Real-world performance depends on protocol settings, the transport layer, server implementation, congestion, and local network restrictions. Switching servers can make a bigger difference than switching protocols.

• Shadowsocks: Check the encryption method and supported core versions. If the node uses an additional plugin, make sure the client supports it.
• Trojan: Common deployments use TLS. The server address, port, authentication parameters, and TLS settings must match.
• VMess / VLESS: Check the transport and TLS settings as well as the protocol name. WebSocket and gRPC configurations aren't interchangeable.
• Hysteria2 / TUIC: These use QUIC and require UDP connectivity. If your network blocks UDP, they may not connect. The fact that other TCP nodes work doesn't mean their configuration is correct.

Clash is a common name for a client ecosystem; actual protocol support depends on the core in use and its version. The original Clash and Clash Meta (now called mihomo) support different sets of features. If importing a profile gives an “unsupported proxy type” error, check the core first. Don't change type in the YAML to another value; renaming it doesn't change the server protocol.

6. url-test: Automatically choose the lowest-latency eligible node

Once you've filtered nodes by location, multiplier, and service availability, use url-test to compare latency among the remaining candidates. Don't put every node in one automatic group if they differ in location, cost, or usage restrictions—the lowest-latency node may not meet the needs of your current task.

This example is for mihomo. It assumes your existing proxies list already contains nodes named HK-01 and HK-02, and that both have been verified for the same service. The names are examples to show how references work; when using this, they must exactly match your existing node names.

proxy-groups:
  - name: HK-AUTO
    type: url-test
    proxies:
      - HK-01
      - HK-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

• interval: 300: Tests every 300 seconds, not every 300 milliseconds.
• tolerance: 50: Sets a 50 ms switching threshold to reduce unnecessary changes caused by small latency differences.
• lazy: true: Enables lazy testing. When the group isn't in use, don't assume probes will keep running at the configured interval.
• url: Use a stable test URL that returns a small response. The example URL usually returns HTTP 204, but make sure it's reachable from your network and nodes.

This isn't a complete configuration. Add the group entry to your existing proxy-groups list; don't add the same key twice at the YAML top level. If your nodes come from proxy-providers, follow the provider structure and use use with appropriate filters. Don't assume the static node references above can replace provider configuration directly.

7. fallback: Keep a working backup in order

fallback and url-test serve different purposes: the former selects an available node in candidate order, while the latter compares probe latency. Use fallback when you want to keep using a preferred route and switch to a backup if the probe fails. It doesn't guarantee an immediate switch for every kind of service failure.

proxy-groups:
  - name: HK-FAILOVER
    type: fallback
    proxies:
      - HK-01
      - HK-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

  - name: PROXY
    type: select
    proxies:
      - HK-AUTO
      - HK-FAILOVER
      - HK-01
      - HK-02

This snippet uses the same proxy-groups list as the previous section; HK-AUTO must already exist. Then point the rules that need a proxy to PROXY, and select the automatic group, fallback group, or an individual node in the client. If your configuration already has a group with the same name, edit that entry instead of adding another one.

For example, the following rule sends matching requests to github.com and its subdomains to PROXY. Place it before broad rules that might match this traffic first and before the final MATCH rule. Don't replace all your existing routing rules just to use this example.

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  # Keep existing rules; leave the final MATCH rule at the end

If the preferred node can still reach the probe URL but the video service returns an error, fallback may keep using the preferred node. This happens when the probe target and the actual service behave differently. Switching nodes mainly affects new connections; existing downloads, video sessions, and other long-lived connections may not move automatically. The app may need to reconnect.

8. Everyday node selection checklist

1. Check the route: The target app is routed through the system proxy or TUN, and the connection log shows the expected rule.
2. Check must-have criteria: The target location and service work, and any required capabilities such as UDP have been tested.
3. Check the cost: Confirm the multiplier, upload billing, and remaining data in the provider dashboard—not just the node name.
4. Compare stability: Run five tests under the same conditions, then check variation, timeouts, and sustained speeds during your usual hours.
5. Build a candidate group: Put nodes with the same use case in an automatic group, and keep a verified manual option available.
6. Save changes safely: Back up the configuration, validate it, and check the logs. After updating the subscription, make sure your custom groups are still there.

Choosing a node isn't about finding one latency number that stays lowest forever. It's about keeping a shortlist for a specific task, with clear criteria, manageable costs, and results you can reproduce. Route performance changes with time and network conditions. When something goes wrong, check traffic interception, rules, the probe URL, and the service itself before switching nodes.