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

Start with your needs, then compare the numbers

Latency in a Clash node list is a test result, not an overall score. Whether a node suits your needs also depends on the site you’re accessing, sustained throughput, stability, exit region, and traffic multiplier. First rule out nodes that can’t reach your target service, then compare stability and cost. Use latency to break ties between otherwise similar options.

Keep three candidates to start: a primary node for everyday use, a backup on a different route, and a region-specific exit only if you actually need one. Labels such as “dedicated route,” “native IP,” and “high speed” are names chosen by the provider. They don’t replace testing or confirm how a route is built.

• Web browsing and remote interaction: Check initial response time, pauses between repeated requests, and fluctuations during evening peak hours.
• Video and large downloads: Check sustained download speed, buffering, and the traffic multiplier. A single low-latency reading says little about throughput.
• Region-restricted services: First check how the service identifies the exit IP, then test speed. The region in a node’s name may not match the region the service detects.
• Gaming and real-time voice: Make sure the app’s traffic actually goes through the proxy and that the node supports the UDP forwarding you need. Web latency is no substitute for in-game metrics.

Latency tests: check what’s measured, repeat the test, then try real requests

What does the millisecond reading in Clash measure?

A typical node latency test sends a request through the proxy to a specified test URL and records the request time reported by the core. It isn’t simply an ICMP ping to the node server. Results can vary with the test URL, connection reuse, and core implementation, so readings from different clients or test URLs aren’t directly comparable.

If one test shows 80 ms and another shows 130 ms, that only means the first node was faster in that test. A real website may use a different exit route and also requires DNS resolution, a TLS handshake, and server processing. A reachable test URL doesn’t prove that every target site is reachable.

Repeat tests under the same conditions; don’t cherry-pick the lowest reading

1. Use the same device, network, and test URL each time. Pause large downloads so they don’t saturate your local bandwidth.
2. Test each candidate five times, about 10 seconds apart. Record the median, highest reading, and number of timeouts.
3. Retest during your usual usage hours and evening peak hours, such as 10:00 and 21:00. These are test conditions, not a performance guarantee.
4. Open the site you actually plan to use. Refresh it repeatedly or perform the same action, and confirm that page resources load too.

For example, node A might return 65, 70, 68, and 900 ms, followed by a timeout. Node B might return 115, 120, 118, 125, and 122 ms. B has a higher median, but these results are more consistent. These figures illustrate how to read test results; they are not measurements of this site’s routes. A small sample can’t predict long-term availability.

Traffic multipliers: calculate usage from the billing rules, not speed

A multiplier usually describes how a provider deducts traffic from your plan; it isn’t a speed boost in the Clash core. For example, if a provider bills the combined upload and download traffic, transferring 5 GB uses about 10 GB of quota on a 2× node and about 2.5 GB on a 0.5× node. Check the provider’s billing rules. Client connection statistics alone aren’t enough to determine whether you were overcharged.

A higher multiplier doesn’t guarantee lower latency, and a lower multiplier doesn’t necessarily mean slower speeds. If you transfer 4 GB a day, that adds up to 120 GB over 30 days. Using 2× nodes for all of it would consume about 240 GB of quota under the billing rules above. Estimate your monthly usage before choosing a plan, rather than discovering halfway through the month that you’ve run short.

Speed tests use traffic too. A 30-second download averaging 80 Mbps transfers about 300 MB, before counting any other usage. There’s no need to max out dozens of nodes one by one. Narrow the options with lightweight latency tests, then briefly test throughput on two or three candidates.

Choosing a region: distinguish the entry point, exit point, and the region a site detects

The server address your device connects to can be considered part of the entry point; target sites usually see the exit IP. With a relayed route, the entry and exit may be in different regions. A node labeled “Japan” doesn’t mean your device connects directly to a server in Japan, nor can you infer the final exit from the connection address alone.

A nearby location doesn’t always mean a shorter route

Geographic distance affects propagation delay, but peering between providers, detours, and congestion also matter. The same node may perform differently on home broadband, a company network, or a mobile hotspot. Retest your primary node after switching networks; don’t assume results from another connection still apply.

Check region-restricted services on the service itself

• Connect to a candidate node, then confirm the target service’s requests actually go through it rather than being set to DIRECT by a rule.
• Check the region message or available content shown by the target service. IP lookup sites may use different databases from the service you’re accessing.
• The account’s registration region, payment details, device location, and session history may also affect the result. Changing your exit IP doesn’t guarantee a different outcome.
• For services you stay signed in to, keep the exit region consistent where possible. Frequent region changes may trigger extra verification.

For everyday browsing, start by testing nearby regions with good routing. Keep a node for a specific exit region only when a service actually requires it. More regions don’t automatically mean better availability.

Choosing a protocol: check core support first, then your current network

Clash is a common name across the client ecosystem, but different clients may use different cores. Clash Meta (now commonly called mihomo) doesn’t support exactly the same protocols as older Clash versions. Successfully importing a subscription only means the configuration was accepted at some stage; the current core must still support the node type, fields, and transport options.

If your network blocks UDP, transports that depend on UDP may fail to connect, while TCP-based options in the same subscription may work. Conversely, a properly configured QUIC-based transport may perform well on some high-latency or lossy networks. Test on the same network to compare; don’t rank options by protocol name alone.

Don’t disable certificate verification blindly to “speed things up.” For certificate errors, check your device’s clock, server name, and subscription settings, and contact your provider if needed. Connecting successfully and validating a certificate correctly are separate things; bypassing validation isn’t a general troubleshooting step.

Verify in Clash: check which node your traffic actually uses

If things are still slow after selecting a node, the target request may not be going through the chosen policy group. In rule mode, rules are matched in order and the matching rule determines how traffic is handled. Some domains may be set to DIRECT or routed through another automatic selection group. Check the client’s Connections or Logs view for the target domain, matched rule, and actual proxy chain. The exact menu name depends on the client.

Select a node manually first, then compare automatic policies

In mihomo, a select group lets you pin a candidate node manually; url-test selects based on results from a test URL; and fallback picks the first available option in the candidate list. Automated tests measure performance against their test URL; they don’t account for video quality, account region, or traffic multipliers.

Here’s a policy group excerpt from an existing mihomo configuration. It references a proxy-provider that’s already defined in the subscription; it isn’t a complete configuration you can import by itself. The test group probes every 300 seconds. Keep the manual selection group so you can compare nodes repeatedly under the same conditions.

proxy-groups:
  - name: Daily manual pick
    type: select
    use:
      - provider-main

  - name: Latency candidates
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300

Replace provider-main with the name of a provider that actually exists in your configuration. The test URL is for connectivity checks only; it doesn’t represent the service you’re trying to use. Save a copy of the configuration before editing so a subscription update doesn’t overwrite your changes. See the YAML guide for provider and rule syntax.

After switching nodes, test with a new connection

1. Select one candidate, open the target site, and note how it loads or downloads.
2. After switching to another candidate, start a new request. Existing long-lived connections may continue using the original proxy chain.
3. If needed, close only the old connections for that app to avoid interrupting other downloads or meetings.
4. Compare the same file at similar times. Note any pauses, not just the peak speed.

Final shortlist: keep a primary, a backup, and notes on each use case

Once you’ve compared the options, record the results in one line: network, test time, node name, actual exit region, multiplier, median latency, timeouts, and how the service performed. You don’t need to keep every reading forever, but note why you chose each node so you can reassess after a subscription update or network change.

• Primary node: Works with your target services, stays stable during your usual hours, and has a multiplier that fits your everyday usage.
• Backup node: Prefer a different entry point or route. Two nodes with different names may still share the same failure points.
• Special-purpose node: Use it only when you need its region or protocol support; it doesn’t need to carry all your traffic.
• When to retest: After changing broadband, updating the client core, modifying the subscription, or experiencing repeated timeouts, rerun the same tests under the same conditions.

A practical order is: can it access the service → is the connection stable → is the multiplier acceptable → are latency and throughput suitable? Checking these separately is usually more effective than repeatedly clicking “Lowest latency” to find a node that works on your current network.