How to Choose a Node: Latency, Traffic Multipliers, Regions, and Protocols
Not sure which node to use from your subscription? Learn how to compare real-connection latency, traffic multipliers, regions, use cases, and protocols—and read speed-test results correctly.
After a subscription update, the client may show a long list of similarly named nodes. Choosing at random based only on a region label or latency number can lead to slow downloads, unstable evening performance, or unexpectedly fast traffic usage. The right approach is not to hunt for one permanently fastest node, but to define the use case first and evaluate latency, multiplier, region, and protocol together.
Each dimension answers a different question: latency reflects interaction delay, the multiplier determines how traffic is charged, the region affects routing and the target service’s response, and the protocol concerns configuration compatibility and transport combinations. No single number represents the full experience. Nodes are also affected by your local network, carrier routing, server load, and time of day, so one test only describes conditions at that moment.
How to Measure Latency: Prioritize Real-Connection Results
Latency tests in clients may use different methods. Common results include basic network probes, TCP connection time, and real-connection latency. They measure different stages and should not be compared as if they were the same. A node reporting a few dozen milliseconds only shows that the tested step completed quickly; it does not guarantee faster page loads, video buffering, or large-file downloads.
Basic Probes vs. Real Proxy Connections
A basic network probe mainly measures the round trip between your device and the server address. It is useful for quickly identifying unreachable nodes or obviously abnormal routes. Some servers do not respond to these probes, however, or handle probe traffic differently, so a timeout does not necessarily mean the proxy connection is unusable.
A TCP connection test usually checks only whether the target port can accept a connection. It is closer to real use than a basic probe, but it still does not cover the full protocol handshake, transport layer, security layer, proxy forwarding, or target-site response. Port connectivity proves only that the entry point is reachable—not that the node can forward all traffic normally.
Real-connection latency sends an actual proxy request through the selected configuration, making it more useful for comparing node experience. On the v2rayN desktop client, you can select a real-connection latency test from the node testing menu. The Android versions of v2rayNG and v2flyNG can also test the current configuration or a configuration list. Menu names may vary slightly by version; the key is to use a test that passes through the proxy configuration rather than checking only the server address.
Read Variance, Not Just the Lowest Number
Suppose node A records 75, 82, 79, 85, and 81 ms across five tests, while node B records 42, 160, 68, 310, and 55 ms. Node B reached a lower number once, but its variance is much greater. For web browsing, voice calls, or remote work, node A will often feel smoother. Evaluate the average level, worst spike, and failure count together.
Test each candidate three to five times on the same network and device, at roughly the same time. Remove nodes that fail repeatedly, then discard those with large latency swings. From the stable group, choose a lower-latency option. Test again during a busy evening period to gauge peak-hour performance rather than keeping only the best daytime result.
| Test metric | What it tells you | What it cannot tell you alone |
|---|---|---|
| Basic network probe | Approximate route response and reachability | Whether the proxy protocol completed its handshake |
| TCP connection time | How quickly the server port accepts a connection | Whether complete proxy forwarding works |
| Real-connection latency | Interactive wait time for an actual proxy request | Long-duration sustained download speed |
| Download speed | Current-period sustained throughput capacity | All-day stability and traffic cost |
Low latency does not mean high bandwidth
Latency and bandwidth are different metrics. Latency is how long one request takes to make a round trip; bandwidth is how much data can be transferred per unit of time. A node may have 60 ms latency but still download slowly because of server load or limited egress bandwidth. Another node may have 130 ms latency yet sustain a much higher download rate.
Web browsing, live interaction, and remote terminals are more sensitive to latency, while file downloads, system updates, and high-definition video depend more on sustained bandwidth. For large-traffic tests, use a legitimate, stable, repeatable download source and observe performance for a meaningful interval instead of judging by the first few seconds’ peak. Make sure your Wi-Fi, router, and broadband connection are not the bottleneck.
How to Read Traffic Multipliers: Calculate Actual Usage First
Labels such as “0.5x,” “1x,” and “2x” in node names usually indicate a traffic billing multiplier; follow your subscription provider’s definition. A common calculation is actual transferred traffic multiplied by the multiplier and deducted from your account quota. For example, 2 GB of actual traffic may count as 1 GB on a 0.5x node and 4 GB on a 2x node.
A multiplier is not a speed tier or a quality score. A 2x node is not necessarily faster than a 1x node, and a 0.5x node is not necessarily more crowded. Multipliers may reflect routing costs, regional resources, service tiers, or provider rules, so the number alone says nothing reliable about performance. Treat it as a cost factor, then use latency and actual throughput to judge the experience.
For low-traffic tasks such as browsing and document sync, multiplier differences may be negligible, so prioritize a stable node. If you frequently download large files or watch high-bitrate content, the multiplier can significantly affect your quota; test stable candidates among the lower-multiplier nodes first. Switch to a lower-latency node when a task requires more responsive interaction.
When checking traffic usage, account for background tasks. System updates, cloud sync, video preloading, and automatic app downloads can all consume traffic continuously. If system proxying or TUN mode is enabled, more apps may use the current node. If your quota drops faster than expected, check the proxy scope, routing mode, and background connections before blaming the multiplier.
How to Choose a Region: Follow the Route and Target Location
A farther node is not automatically better, and the geographically closest node is not always the fastest. Packets follow carrier networks and interregional routes, not straight lines on a map. A nearby region with a circuitous route may have higher latency than a more distant region with better interconnection. Use the node name for initial filtering, then verify it with real-connection tests and actual access.
Start with Nearby Regions for Everyday Browsing
When you have no specific regional requirement, start by testing two or three physically nearby regions. They often offer shorter theoretical propagation distances and lower interactive latency. Keep one primary node and one backup in a different region so a temporary regional slowdown does not force you to search the entire subscription again.
If a nearby node is clearly slower than nodes in other regions, do not keep refreshing in the hope that the number will drop. Check whether your local network is stable, then compare other nodes in the same region. If only one node is abnormal, its load or specific route is more likely responsible; if every node in that region is abnormal, the cause may be a regional route or a shared local egress issue.
Group Nodes by Use Case When Services Vary by Region
Some websites return different content, languages, server entry points, or access policies based on the region of the exit address. In that case, node selection is not just about speed; confirm that the target service responds normally from the region. Choose a suitable region first, then compare latency and stability within that region.
In v2rayN, v2rayNG, or v2flyNG, organize configurations by name and create clear candidate groups for frequently used regions. Subscription updates may overwrite some manual organization, so it is safer to preserve naming patterns and run another batch test after each update. Do not keep a node fixed indefinitely based on an old test; network conditions change over time.
Prepare a Cross-Region Backup
A backup should ideally not share the same region and route as the primary node. If they use the same upstream path, both may be affected by a regional outage or congestion. A practical setup is one low-latency primary, one stable backup in another region, and one high-volume node with a low multiplier. Together they cover interaction, availability, and traffic cost.
How to Choose a Protocol: Start with Complete, Compatible Configurations
VMess and VLESS are common in subscriptions. Both are proxy protocols, but the protocol name alone does not determine node performance. Actual connections also depend on the transport, security layer, server configuration, core version, network route, and server load. When you see a VLESS or VMess label, first confirm that the client can parse the subscription configuration correctly, then compare real latency and stability.
A VMess configuration typically includes a user ID, server address, port, and transport parameters. VLESS uses a lighter protocol design and is often combined with transport and security capabilities provided by the Xray core. v2rayN can use the appropriate core to process compatible subscription configurations; v2rayNG uses the Xray core; v2flyNG uses the v2fly core. A configuration supported only by a particular core cannot be converted simply by changing the protocol name.
If your subscription already provides working nodes, beginners should not manually change protocol fields, transport parameters, or security settings. The address, port, user ID, transport, service name, and other fields must match the server; any change can cause the handshake to fail. Compare the complete configurations supplied by the subscription instead of copying selected fields into a new node.
| Dimension | What to check first | Common misconception |
|---|---|---|
| VMess | Whether the complete parameters can be parsed and connected by the client | Assuming the protocol name directly determines speed |
| VLESS | Whether the core supports the transport and security combination | Changing only the protocol field and trying to connect |
| Transport | Whether client and server parameters match | Treating the transport type as a fixed performance ranking |
| Core | Whether the current client supports the complete configuration | Ignoring core differences when migrating a configuration |
If multiple protocols are available in the same region, test them on the same network and at similar times. Confirm that every configuration connects normally before comparing real-connection latency, failure rate, and actual throughput. If performance is similar, keep the configuration compatible with the current client core and stable across subscription updates; there is no need to switch repeatedly for the protocol label alone.
A Repeatable Node-Selection Process
When there are many nodes, trying each one for an extended period is inefficient. Narrow the list through four steps: initial screening, retesting, practical validation, and backup planning. Repeat the same process after every subscription update so results remain comparable and one abnormal peak does not mislead you.
- Update the subscription and remove dead results.Make sure the client has the latest node list. If old and new nodes share names, check whether the update process replaces old configurations so you do not keep testing historical configurations that no longer respond.
- Screen by use case and region.Choose a few candidates from nearby regions, regions required by your target services, and low-multiplier nodes. There is no need to test every node at the start.
- Run real-connection latency tests.Test three to five times in succession on the same network, recording failures, obvious spikes, and the stable range. Remove nodes that fail repeatedly or fluctuate heavily.
- Perform a short real-world check.Use familiar websites, legitimate download sources, or everyday apps to verify responsiveness and sustained throughput. Do not rely on a single number in the client’s node list.
- Keep primary, backup, and high-volume nodes.The primary node should offer overall stability, the backup should be in a different region, and the high-volume node should prioritize its multiplier and sustained speed.
- Retest during peak hours.Normal daytime performance does not guarantee the same results at night. Lower the priority of nodes that frequently become congested during your usual hours.
Keep other variables fixed during testing. Do not switch Wi-Fi networks while comparing nodes, and do not test latency while a large file is downloading in the background. Do not rank results from different dates or devices together. Keep the local environment consistent so the node remains the main variable.
If you use split routing, confirm that the test traffic actually passes through the proxy. Some targets may be configured for direct connection, in which case their load time does not represent node performance. Temporarily select an explicit proxy mode before testing, then restore your original routing settings afterward. Note the current mode first so you do not forget to restore it.
What Can Mislead Your Speed Tests?
Ranking nodes after a single test
A single test can be affected by momentary queueing, DNS response time, server load, and local network fluctuations. The lowest value shows an ideal moment, not long-term performance. Run multiple tests and watch the middle range and failure count. A stable 100 ms is usually more predictable than latency jumping between 50 and 500 ms.
Treating a client timeout as proof that a node is dead
A timeout may come from a temporarily unreachable test target, a DNS resolution problem, local network restrictions, or an actual node failure. Try a real connection first, then check the client log. If the same node fails real-connection tests repeatedly while others work, you have stronger grounds to locate the problem in that configuration or on the server.
Treating a speed peak as sustained speed
At the beginning of a download, caching, parallel connections, or the measurement window can produce a brief peak. For large files, watch the stable rate after running for a while, along with retries and sharp slowdowns. A consistently solid medium-to-high speed is usually more useful than an extreme peak lasting a few seconds.
Ignoring local network bottlenecks
Weak Wi-Fi, a heavily loaded router, broadband congestion at peak times, and background tasks on the device can all change the result. If every node slows down at once, test the direct connection and local device state first. If only certain nodes are abnormal, compare their region, multiplier, and protocol configuration. Distinguishing a global issue from a single-node issue reduces unnecessary switching.
Frequently Asked Questions
Why is a webpage still slow when the node has the lowest latency?
A latency test covers only part of the connection process. Page loading is also affected by DNS, the target site’s response, the node’s egress quality, packet loss, and bandwidth. After repeated real-connection latency tests, verify performance with actual webpages and sustained downloads instead of relying on the lowest number.
What latency is considered acceptable for a node?
There is no fixed threshold that works for every network. Compare nodes within the same subscription, on the same network, and during the same period. Low, steady latency suits interactive tasks; slightly higher latency with stable throughput may be better for downloads and video.
Does a higher multiplier mean a faster node?
Not necessarily. A multiplier usually describes traffic billing, not a speed tier. Speed still depends on routing, load, bandwidth, and your local network. Filter by a multiplier your quota can support, then test actual performance.
Why is the same node fast during the day but slow at night?
Peak hours can bring route congestion or higher server load. Retest during your normal usage period and prepare a backup in another region. Daytime results alone cannot represent nighttime performance.
Do I need to choose nodes again after a subscription update?
A quick retest is recommended. An update may add nodes, change names, or replace configurations, and the route status of an existing node may also change. Repeating the selection process is more reliable than depending on one old ranking.
Conclusion: Replace Single-Metric Rankings with a Combined Assessment
Node selection comes down to four principles: use real-connection latency to judge interactivity, repeated results to judge stability, the multiplier to control traffic cost, and region plus protocol to confirm suitability and compatibility. For downloads, add a sustained-throughput test; for evening use, retest during peak hours.
You do not need to maintain a long leaderboard. Keep one consistently stable primary node, one backup in another region, and one high-volume node with a suitable multiplier. After a subscription update or a change in network conditions, repeat the same process; it is usually more effective than chasing the lowest latency number.