How to Choose a Proxy Node: Latency Tests, Traffic Multipliers, Locations, and Protocols

Choose nodes for your needs before comparing latency

After importing a subscription into Clash, the node list may show locations, traffic multipliers, route names, and protocols all at once. You don't need to run full-speed tests on every node. First, identify the region your target site requires. Then rule out nodes with unsuitable traffic costs, and compare availability and stability among the rest. This saves a lot of unnecessary testing.

Here, “proxy provider” refers to a service that offers proxy subscriptions. Node names are set by the provider; they are not connection parameters verified by the client. Labels such as “dedicated route,” “high speed,” and “residential” are only useful as initial clues. Check actual connection performance, exit IP, and the provider's documentation before drawing conclusions.

• Web browsing and research: Prioritize nodes that handle repeated requests reliably and load pages quickly. Peak download speed isn't essential.
• Streaming and large downloads: Check the traffic multiplier and remaining allowance first, then sustained throughput. A difference of a few dozen milliseconds is rarely the main concern.
• Remote desktop and voice calls: Pay attention to latency variation, drops, and UDP support. Also confirm whether the app's traffic is actually routed through the proxy.
• Services that require a specific region: First verify the exit region recognized by the service and any account requirements. Consider latency rankings afterward.

What Clash latency tests actually measure

Latency tests in Clash and mihomo clients typically send an HTTP or HTTPS request to a test URL through the selected proxy and record how long it takes. This isn't simply an ICMP ping to the node's server, nor is it a download speed test. Results may not be directly comparable when the test URL, connection reuse, core version, or client settings differ.

Low latency doesn't mean fast downloads

Connection setup, the TLS handshake, and response time can all affect the result. A quick small request doesn't mean there's enough bandwidth during peak hours. Conversely, a route over a longer distance may have higher latency but deliver more consistent download speeds.

For example, if candidate A reports 45 ms and candidate B reports 95 ms, that only tells you their response times differed under the conditions of that test. It doesn't mean A downloads twice as fast as B, let alone guarantee that a particular video service will work properly through A.

Compare three rounds under the same conditions

1. Pause system updates, cloud sync, and other downloads. Stay on the same Wi-Fi or wired connection.
2. In the client's “Proxies” page, find the group you want to compare and use its latency test button. Some clients call this page “Proxy Groups.”
3. Test each candidate three times, about 10 seconds apart. Record timeouts and the range of results instead of noting only the lowest reading.
4. Switch to each candidate and open the target site. Check whether the initial page load, login, and continued use all work as expected.

Suppose one node returns 62, 65, and 63 ms, while another returns 40 ms, 260 ms, and a timeout. The first is usually a better fit for interactive tasks. These are example readings, not a performance claim about any route tested by this site. If the client has options such as unified-delay that affect latency calculations, keep them consistent when comparing nodes.

How traffic multipliers work: 0.5×, 1×, and 2×

A multiplier is usually a billing factor set by the provider, not a speed multiplier. A node marked 2× isn't necessarily twice as fast as a 1× node; 0.5× doesn't mean the connection runs at half speed. Check the provider's traffic policy to see whether it applies to uploads, downloads, or both.

The table uses a 10 GB base allowance from the provider to illustrate the multiplication. Downloading a 10 GB file may also incur upload traffic, protocol overhead, and retries. Account dashboards may update with a delay, so don't expect the client and account panel to match byte for byte in real time.

Speed tests also use your allowance

As a decimal-unit estimate, downloading continuously at 100 Mbps for 60 seconds transfers about 750 MB. If all of it is billed at 2×, that uses about 1.5 GB of allowance. Running bandwidth tests on dozens of nodes can consume far more traffic than running a few latency checks.

• Use latency tests and real websites to narrow the list to two or three candidates, then run brief throughput tests.
• To check the multiplier, pause traffic on other devices, note the allowance shown in your account, run one controlled download, and compare after the usage data updates.
• Check node names and provider documentation again after refreshing the subscription. Multipliers may change.

How to choose a node location: entry point, exit location, and target service

A location in a node name, such as Hong Kong, Japan, or the United States, usually describes its exit location, but the address your client connects to first may be somewhere else. A relayed route may connect to a nearby entry point before continuing over another link to an overseas exit. Geographic distance is a useful starting point, not a substitute for testing.

For general browsing, start with the network route

For users in mainland China, Hong Kong, Japan, and Singapore are reasonable starting points, but results vary by carrier, city, and time of day. Performance at 9 p.m. may differ from 10 a.m. Test at least once during the hours you normally use the service; a single daytime result isn't a reliable long-term benchmark.

For region-specific services, verify the exit location—not just the label

The same exit IP may be assigned to different regions by different databases. A service may also consider your account region, payment method, device location, and sign-in history when deciding access. A node labeled with a particular region doesn't guarantee access to all content there.

• Test the service itself instead of treating an IP lookup page as the final word.
• Check that the service's traffic actually matches the selected proxy group. The lookup page may use the proxy while the target app connects directly.
• For sign-ins and payments, try to keep the same exit location. Frequent region changes may trigger additional verification.
• For a backup route, look for a different entry point and exit resource—not just a nearby node number.

Trojan vs. VMess vs. Hysteria2: what to consider

A protocol defines how the client communicates with the proxy server. Route quality also depends on entry-point congestion, cross-border routing, server load, and exit bandwidth. No protocol is inherently “the fastest.” Before comparing protocols, make sure your client core supports the fields used in the subscription.

If UDP is restricted, don't keep switching between Hysteria2 nodes

Some office networks, guest Wi-Fi, and carrier routes restrict UDP. If several Hysteria2 nodes fail on the same network while TCP-based nodes work, compare results using a mobile hotspot first. Hysteria2 may perform well on some weak networks, but it isn't guaranteed to outperform other protocols under every packet-loss or throttling condition.

The same port number doesn't mean the same transport

Trojan can run over TCP 443, while Hysteria2 can run over UDP 443; the server determines the port. Allowing TCP 443 doesn't mean UDP 443 is allowed. Being able to browse HTTPS sites doesn't prove that the UDP path Hysteria2 needs is available.

Hysteria2 requires a compatible core, such as a current mihomo version that supports the protocol. Don't assume an older core can parse it just because the client has “Clash” in its name. If importing a subscription reports “unsupported proxy type,” first check the core details on the client's “About” page. Then update to a compatible client or ask the provider for a compatible configuration—don't just rename the node type.

Add candidate nodes to a proxy group and confirm the rules are taking effect

Even after choosing a node, an app may not use it. In Clash rule mode, connections are sent to the proxy group specified by the matching rule. Changing the “Manual” group doesn't change every other group. When troubleshooting, check the matched rule and connection route before looking at latency results.

1. Select “Rule” mode in the client, open the “Proxies” page, and check which proxy group the target rule uses.
2. Switch that group to a candidate node. If it contains nested groups, check and change the selection at the next level too.
3. Close existing connections to the target site and reload it. If needed, close the relevant connections from the Connections page so an old session doesn't keep using the previous route.
4. On the “Connections” page, check the target domain, matched rule, and proxy chain to confirm that traffic exits where expected.

Manual selection, automatic latency testing, and failover

• select: Choose a candidate manually. Useful for a fixed exit location and side-by-side testing.
• url-test: Selects a node using the configured test URL and policy. It generally favors lower test latency, but doesn't account for traffic multipliers or regional access requirements.
• fallback: Checks candidates in order and uses health checks to find an available one. Useful for backup routes with a preset priority.

An automatic test group may pick a low-latency node with a high multiplier, or switch to an exit that doesn't meet regional requirements. For easier management, group nodes by purpose, acceptable multiplier, and region instead of putting every node into one automatic group.

A five-step checklist for choosing a node

1. Define the use case: Decide whether you need everyday browsing, sustained downloads, or access from a specific region. Rule out candidates that don't fit.
2. Check the cost: Confirm the multiplier, remaining allowance, and billing policy. Don't use a bandwidth test as a substitute for budgeting traffic.
3. Check stability: Run three latency tests under the same conditions, then test again during your usual hours. Note timeouts and variation.
4. Test the service: Sign in, stream, or download for real. Confirm the matched rule and exit location instead of relying on a green number in the node list.
5. Keep a backup: Save a candidate on a different route. If something goes wrong, switch and compare first, then narrow down whether the issue is your network, subscription configuration, or server.

Your final choice doesn't need to be a permanent ranking. For everyday use, a primary node with stable response times, an acceptable multiplier, and the right exit location—plus a tested backup—is usually more practical than chasing the lowest latency every day. Repeat these five checks after changing networks, refreshing a subscription, or running into peak-hour congestion.