How to Choose Clash Nodes: Latency, Traffic Multipliers, Regions and Protocols

Start with what you need the node for, then compare the numbers

A Clash node is a proxy egress option in a configuration. The client displays the list, the core establishes connections, and the provider determines the ingress, egress, routes, and billing. Labels such as “Japan,” “dedicated route,” or “0.5×” are usually provider notes—not performance claims verified by the core.

First, define what you need: web browsing, large downloads, access from a specific region, or real-time communication. Browsing depends more on connection setup time; downloads on sustained throughput; region-specific access on the actual egress location; and voice or gaming on UDP support, jitter, and packet loss. One latency figure cannot answer all of these questions.

• Everyday browsing: Choose a consistently available node with stable response times, and keep a backup egress.
• Streaming and downloads: Compare sustained speeds in the evening and check the traffic multiplier. Don’t rely on a single peak reading.
• Region-restricted services: Verify the egress IP location and test access to the service before comparing speeds.
• Voice and gaming: Confirm that the app’s traffic is actually proxied, that the node supports UDP, and check latency and packet loss in the app itself.

Latency readings: test targets, timeouts, and variability

What the millisecond reading measures

Clash clients commonly test proxy availability and response time by requesting a specified URL. This usually isn’t an ICMP ping to the server or a bandwidth test. Results depend on the connection from your device to the ingress, the proxy handshake, the route from the egress to the test site, and whether connections are reused. Timing details can also differ between client and core versions.

For example, if node A shows 68 ms and node B shows 126 ms for a test URL, that only means A responded faster to that URL in this test. If the site you actually use is closer to B’s egress, B may still perform better. Don’t treat rankings for one test domain as a speed ranking for every website.

Repeated tests are more useful than a one-time ranking

1. Compare nodes on the same network and with the same test URL. Pause large downloads and cloud sync for now.
2. Test each candidate five times, about 10 seconds apart, and record the number of successful tests and the range of results.
3. Open the sites you actually use and check initial page load and whether ongoing interactions feel sluggish.
4. Test again during your usual usage hours—for example, 8–11 p.m.—to check peak-time variability.

The figures below illustrate how to assess nodes. They are not measurements or performance guarantees for any route from this site.

A timeout doesn’t mean the subscription has expired

A timeout may mean the node is offline, the test site is unreachable, DNS resolution failed, the handshake failed, or the timeout threshold is too short. First check whether other nodes are failing too, then try a real website. If all nodes fail, check your local network and configuration; if only one fails, inspect that node’s connection logs. A successful HTTP test also doesn’t prove that UDP is working.

Traffic multipliers: how usage is billed, not a measure of bandwidth

“0.5×,” “1×,” and “2×” usually indicate the provider’s traffic billing multiplier for a node. This isn’t a universal Clash protocol field, and the core won’t double bandwidth just because a node is labeled “2×.” Check the provider’s usage policy and account dashboard for the exact billing rules.

Example usage calculation

Suppose the provider deducts plan usage by multiplying combined upload and download traffic by the node’s multiplier. The billable usage would be: billable traffic = measured traffic × node multiplier. If measured usage is 8 GB, the deductions at different multipliers would be:

Actual deductions may also depend on how upload and download traffic are counted, the difference between GB and GiB, protocol overhead, and delays in updating the billing dashboard. The download amount shown in the client may not exactly match the account dashboard. Even if a node is labeled “0×,” check when that rate applies, any speed limits, and the usage rules—don’t rely on the node name alone.

Speed tests use up your data allowance, too

A small URL latency test usually uses little data, but a full bandwidth test can transfer a lot. At an average download speed of 50 Mbps for 30 seconds, that’s about 50 ÷ 8 × 30 = 187.5 MB, before overhead. At a 2× node multiplier, about 375 MB would be deducted on this basis. Running bandwidth tests on dozens of nodes can quickly eat into your plan.

Node regions: distinguish ingress, egress, and how sites identify you

A node labeled “Hong Kong ingress | US egress” might connect to a nearby server first, then use a relay route to reach the destination site from the US. Ingress affects the route from your device; egress determines the IP address websites see. The server hostname or address in the configuration may only identify the ingress—it doesn’t by itself confirm the country of the final egress.

Choose a region based on what you’re accessing

• For everyday browsing: Start with a region that has a short route to the ingress, but compare it with other regions. A nearby location doesn’t guarantee a shorter route through your ISP.
• For region-specific content: Look up the node’s egress IP, then test access to the service. IP geolocation databases may take time to update.
• For accounts you use regularly: Stick to a consistent egress region where possible to reduce security checks triggered by frequent region changes.
• For downloads from overseas: Speed depends on connectivity between the egress and the download host. Try an egress near the source; the node closest to your device isn’t necessarily the best choice.

The right region doesn’t guarantee access to a particular service. Access may also depend on data center IPs, account region, billing details, or other risk signals. Labels such as “streaming unblocked” can become outdated, so test the service yourself and follow its terms of service.

Understanding “dedicated,” “direct,” and “relay” labels

These labels describe how the provider organizes its routes; there’s no universal client-side verification standard. A relay may help with congestion or add an extra detour. A “dedicated” route label is no substitute for testing at peak hours. When comparing nodes, record the ingress network, test time, actual egress, and stability rather than relying on node names alone.

Protocol types: check core compatibility first, then network conditions

Clash is a common name in the client ecosystem, but different clients may use different cores. mihomo continues the original Clash Meta project, and its supported protocols and configuration fields don’t exactly match those of older Clash cores. Check the client’s About page or core details for the core name and version, then consult that version’s documentation for the subscription’s type field. A client shell that can import YAML doesn’t necessarily have a core that can run every node.

Protocol names don’t translate directly into speed

Comparing different protocols on the same server isn’t the same as comparing two different servers. Route capacity, server load, congestion control, and your ISP’s route can all affect speed more than the protocol name. Hysteria2 or TUIC may work well on some networks but fail to connect where UDP is restricted; a TCP-based option may be more stable on another network.

Keep the node’s transport protocol separate from the app’s UDP support. A protocol that can carry UDP doesn’t mean the provider has enabled it or that it’s enabled in the current configuration. Being able to browse the web doesn’t prove that game or voice traffic can use the same node.

Manual selection and automatic testing: what policy groups do

A node provides an egress; a policy group determines which egress to use. A manual group works well for a fixed region or account. url-test selects automatically based on results from a specified URL; fallback usually tries available nodes in order. These features are mainly for availability and test response—not for automatically picking the fastest download speed.

mihomo policy group example

This snippet assumes your existing configuration already defines two nodes named “Daily-A” and “Backup-B.” It shows policy groups only, not a complete subscription. If your node names differ, update them to match or you’ll get an error because the referenced proxies don’t exist.

proxy-groups:
  - name: Daily Auto
    type: url-test
    proxies:
      - Daily-A
      - Backup-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: Manual Select
    type: select
    proxies:
      - Daily Auto
      - Daily-A
      - Backup-B

interval: 300 sets the test interval to 300 seconds. When tests actually run can also depend on core behavior such as lazy testing. tolerance: 50 sets a 50 ms switching tolerance to avoid switching back and forth over small differences. The test URL in this example is accessed through the node, so its reachability also affects the result. Choose a reliable test URL for your needs.

For your traffic to use this group, the relevant rules must point to “Manual Select” or “Daily Auto.” Adding a policy group alone won’t change existing rules. Subscription-management clients may overwrite local files during updates, so use the client’s override or merge feature to preserve custom settings. See the configuration guide for steps.

TUN isn’t a speed boost

TUN captures network traffic from more apps, while the system proxy usually affects only programs that follow proxy settings. Enabling TUN can change which connections enter the core, but it won’t increase the node’s bandwidth. If the browser works but other apps aren’t proxied, check how traffic is being captured. If you’ve confirmed they use the same node and it’s still slow, compare routes and destination sites instead of treating TUN as a universal speed-test fix.

Choose a node in 10 minutes: a repeatable checklist

1. Check the configuration: Make sure the subscription is loaded, the core supports the node’s protocol, and your plan is active with data remaining.
2. Filter by region and multiplier: Shortlist two or three candidates based on your needs, and note their egress regions and billing multipliers.
3. Test availability: Run five tests with the same URL and rule out candidates with frequent timeouts or large fluctuations.
4. Test your actual use case: Open a frequently used page, stream a video, or briefly download the same file. Don’t use a peak-speed screenshot as a substitute for real-world performance.
5. Check the connection: In the Connections view, confirm the rule, policy group, and final node so you don’t compare a direct connection with a proxied one.
6. Keep a backup: Choose one regular node and a backup on a different route, then check them again during peak hours.

Keep simple notes: date, network type, node name, five latency results, average speed over 30 seconds, multiplier, and whether the target service worked. Note that Mbps and MB/s are different: 100 Mbps is about 12.5 MB/s before overhead. Use the same units when comparing results to avoid mistaking different display formats for an eightfold performance gap.

If all candidates slow down at the same time, compare another local network first, then check background uploads, your device’s DNS, and traffic capture settings. If only one node slows down, try a different egress for comparison. For more troubleshooting, see Troubleshooting. The best node is the one that reliably handles your actual use case at a reasonable cost—not the one with the lowest number in the list.