How to Choose V2Ray Nodes: A Practical Order for Latency, Traffic Multipliers, Regions, and Protocols

Test Real Connection Latency First—Don’t Rely on Node Names

Labels such as “low latency” and “high speed” in node names are just grouping text; they do not reflect current performance. Home broadband, mobile networks, peak-hour congestion, and ingress routes can all change the result. The same node might measure 86 ms in the morning and rise to 240 ms at night, while a node labeled as a standard route may stay near 120 ms over time.

Run a real connection latency test before choosing. The client establishes a proxy connection through the selected node and visits its configured test address. This reading usually includes DNS lookup, the protocol handshake, transport setup, and the target site’s response time, making it closer to the experience of opening a webpage than a simple ICMP round-trip measurement. It is still only a brief test and cannot by itself indicate sustained download speed.

1. Update Subscription

   Open “Subscription Groups” in the v2rayN main window and run “Update All Subscriptions” first. Stale nodes can distort the ranking, so test only after updating.

2. Check the Core

   Open “Settings” → “Parameter Settings” → “Core Type” and confirm that the active node’s protocol has a compatible core. In v2rayN 7.12.5, for example, VLESS, VMess, and Trojan can commonly use the Xray core.

3. Batch Testing

   Select candidate nodes from the same region in the server list, open the context menu, and choose “Test Server Real Connection Latency.” Test a small group first to prevent dozens of simultaneous connections from affecting one another’s readings.

4. Test Three Times

   Run three tests 20 to 30 seconds apart. Record the median and watch for timeouts. A node that returns 72 ms once but times out twice should rank below one that measures 125 to 140 ms all three times.

5. Set as Active

   Select the most stable node, set it as the active server, and then enable the system proxy. If the local SOCKS port is 10808, also check the core log for a port conflict.

Low Latency Does Not Mean High Bandwidth

Real connection latency mainly reflects connection setup and short-request response time. For a 500 MB download, sustained throughput, packet loss, and congestion matter more. One node may measure 95 ms but manage only 3 MB/s in the evening, while another measures 150 ms and steadily delivers 12 MB/s. The first may feel snappier for browsing, while the second is better for large transfers.

Do not overemphasize differences of a few dozen milliseconds. Test results of 103 ms and 116 ms usually feel the same. The range of variation matters more: 98, 105, and 111 ms is a better default profile than 62, 190, and 420 ms.

Traffic Multipliers Affect Usage, Not Speed

A 0.5x, 1x, 1.5x, or 2x label in a subscription name usually indicates the traffic billing multiplier. Downloading 10 GB may consume 5 GB of quota on a 0.5x node or 20 GB on a 2x node. The exact calculation is defined by the subscription provider. The client only displays the node name and does not correct the quota for you.

A multiplier is not a speed rating. A 2x node may have a better ingress route or more available capacity, or it may simply belong to a different billing group. A 0.5x node is not necessarily congested. Treat the multiplier as a cost factor, then combine three latency tests with real throughput measurements.

Calculate Multiplier Cost for Real Workloads

Suppose your monthly quota is 200 GB and everyday video and downloads use about 120 GB. Using a 2x node throughout would count roughly 240 GB against your quota and could exhaust it early; a 0.5x node would use about 60 GB. A more practical setup is to keep three purpose-specific nodes: 1x as the default, 0.5x for high-volume tasks, and 2x only when standard routes are congested.

• When a node name includes both a multiplier and a region, identify the multiplier field first—for example, “JP-02 | 0.5x.”
• Names may change after a subscription update, so do not rely on manual renaming to preserve multiplier information.
• Client traffic statistics and server-side deductions may refresh at different times. Use the remaining quota shown in your subscription account as the source of truth.
• When several devices share a subscription, desktop downloads and video playback on Android count against the same quota.

Choose Regions for the Destination; Proximity Is Only a Starting Point

Region selection usually starts with geographically nearby servers, but the closest city is not always the best choice. Network paths are not straight lines; the ingress provider, cross-border route, and data-center peering all affect the final result. A farther node with a stable route may outperform a nearby node that repeatedly takes a detour.

For everyday browsing, start by testing three nearby regions and keep two candidates from each. When accessing region-aware services, the server location can also affect content, language, currency, and login risk alerts. Frequently switching between far-apart regions may trigger additional verification, so keep the primary region relatively consistent.

Set a Region Order for Each Use Case

If your main tasks are ordinary browsing and document synchronization, save regions in this order: “low-variance nearby → stable secondary region → distant backup.” For extended video playback, run a continuous test of at least five minutes and watch for repeated buffering. A single 90 ms latency reading says nothing about sustained bandwidth during peak hours.

1. Nearby primary: The three-test median is below 180 ms, there are no timeouts, and the multiplier is acceptable.
2. Same-region backup: Use a different node number from the primary so maintenance on one node does not take both options offline.
3. Different-region backup: Slightly higher latency is acceptable, but the connection must remain stable so you can switch when the entire region’s route becomes unstable.
4. High-multiplier temporary node: Enable it only for meetings, remote connections, or primary-route congestion, then switch back to a standard node.

Evaluate the Protocol After Confirming Availability

VMess, VLESS, Trojan, and Shadowsocks are different proxy protocols. The protocol name alone does not determine how fast a node will be. Real-world performance also depends on the transport layer, TLS settings, server load, ingress route, and client core. A correctly configured VMess node on a stable route may outperform a VLESS node on a congested route.

First confirm that the client can load the configuration correctly, then test connectivity and stability. On desktop, v2rayN typically uses the Xray core to handle VLESS, VMess, and Trojan; v2rayNG 1.10.31 uses the Xray core for the corresponding configurations. If you need a v2fly core environment, Android users can choose v2flyNG. When the subscription already provides complete parameters, do not manually change the UUID, transport, or TLS fields just to pursue a particular protocol name.

Check the Logs First When a Protocol Error Appears

If a node shows negative latency, a test fails immediately, or no traffic appears after startup, open the v2rayN log panel. If the log says a configuration field is unsupported, update the client and core first. If it reports a local listener failure, check whether another program is using SOCKS port 10808 or HTTP port 10809. Verify the port numbers under “Settings” → “Parameter Settings”; the active configuration is authoritative.

If the connection is established but webpages will not open, the protocol itself may not be the problem. Check whether the system proxy is set to automatic configuration or global mode, whether the browser has its own proxy settings, and whether routing rules are incorrectly sending the target domain through a direct connection.

• After a subscription imports successfully, do not manually replace the transport layer. Server and client parameters must match.
• Treat the TCP and WebSocket configurations for the same node as two separate candidates and test them independently.
• When a protocol connects normally, compare latency variation, multiplier, and region first. Do not sort by protocol name alone.
• If an old configuration stops working after a core update, update the subscription again first, then inspect the specific field named in the log.

Turn the Results into Primary, Backup, and High-Volume Groups

Choosing nodes is not a one-time task. Subscription lists, ingress load, and local networks change. The easier approach is to reduce candidates to three types: one daily primary, one backup on a different route, and one low-multiplier node for high-volume traffic. After each subscription update, retest only these few nodes instead of repeatedly switching among dozens of names.

In v2rayN, start by viewing nodes by subscription group, then sort by the real connection latency column. Do not enable automatic selection and ignore the result, since the lowest latency in a single test may be an outlier. In v2rayNG, retest on the currently connected network as well: a node that measures 110 ms on Wi-Fi may reach 260 ms on a mobile network.

Recommended Final Decision Order

1. Update the subscription and remove nodes that cannot connect, have configuration errors, or time out frequently.
2. Run three real connection latency tests on the same network, prioritizing the median and variation.
3. Check multipliers such as 0.5x, 1x, and 2x, then assign roles based on your monthly quota.
4. Choose a relatively consistent server region for your destinations while keeping a backup in another region.
5. Confirm protocol and core compatibility. Use the logs to troubleshoot problems instead of changing parameters blindly.
6. Validate the choice with a real webpage, video, or download task lasting at least five minutes before making it the default node.