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

Start with the Right Node-Selection Order

Node names often include labels such as “high speed,” “dedicated route,” or “low latency,” but names cannot replace real connection results. A connection may pass through your local network, an entry server, a relay route, an exit server, and the destination site; congestion at any point affects performance. Instead of judging nodes only by their listed region or provider label, filter them in this order: connectability, low latency, low jitter, a suitable multiplier, and a matching exit region.

Before testing, update the subscription and confirm that the client’s core supports the node protocols. v2rayN is a desktop client and can use different cores to process VMess, VLESS, Trojan, and other configurations. On Android, choose v2rayNG or v2flyNG according to the core required by the subscription. The client is only the configuration and control layer; the selected core establishes the connection. If the core has not started, the configuration cannot be parsed, or a local port is already in use, speed-test results are not meaningful.

1. Confirm the Group

   Open “Subscription Group” in the v2rayN main window and make sure the target subscription is enabled, so expired groups do not add outdated nodes to the test.

2. Update the Subscription

   Run “Subscription Group” → “Update All Subscriptions” and wait for the server list to refresh. If you have many groups, update only the sources you plan to test this time.

3. Set the Core

   Go to “Settings” → “Parameter Settings” → “Core Type,” choose a core that can parse the subscription protocol, save the change, and restart the core.

4. Run a Real Connection Speed Test

   Select candidate nodes in the same region, run a real connection latency test, repeat it for three rounds, and record latency, failures, and the size of the fluctuations.

5. Run a Verification Test

   Test again during your actual usage hours. Enable the system proxy, visit services you use regularly, and confirm that the exit region, loading speed, and connection stability meet your needs.

Judge Latency by Real Connections, Jitter, and Peak Hours

Lower latency does not always mean faster performance, but it reflects the baseline for interactive responsiveness. The TCP probe shown in a list usually reaches only the node’s entry point and may not include the full proxy handshake. A real connection test sends an actual request through the node and more closely resembles everyday web browsing. Prioritize real connection results, and distinguish a one-off outlier from consistently high latency.

Suppose three candidate nodes have average latencies of 62 ms, 79 ms, and 104 ms. Looking only at the averages would favor the first node. But if the first node records 38, 55, and 93 ms across three rounds while the second records 75, 79, and 83 ms, the second has much less jitter. The difference may be minor when browsing, but sustained video, remote sessions, and long-lived connections are more sensitive to large fluctuations. A steady 79 ms is usually more dependable than a lower average that frequently jumps above 150 ms.

Keep testing conditions consistent. Compare results on the same device, network, client version, and roughly the same time of day. Do not rank a morning home-broadband result directly against an evening mobile-network result. If you mainly use the service at night, run at least one retest between 8:00 and 11:00 p.m. If weekday daytime use is more common, collect another round during your actual working hours.

Multipliers and Regions Determine Cost and Exit Use

A traffic multiplier indicates how much subscription quota is charged for 1 GB of actual traffic. A 1x node uses 1 GB of quota, a 2x node deducts 2 GB, and a 0.5x node deducts about 0.5 GB. A higher multiplier does not guarantee higher speed; it may reflect route costs, the entry type, or the provider’s operating model. Treat the multiplier as a cost metric, then use real tests to see whether that cost buys lower latency or more stable throughput.

The exit region affects the network location services see, connection latency, and content availability. Nearby regions usually provide shorter round-trip paths and work well as everyday defaults. When a service requires a specific region, filter by that requirement first, then compare latency within the region. A region in the node name does not guarantee the final exit is there; after connecting, use a trusted exit-IP lookup page to confirm the actual country or region.

A practical approach is to filter by region first and compare multipliers afterward. If you need a specific exit region, select four to six nodes there, remove those with repeated timeouts, and prioritize 1x or lower-multiplier routes among the survivors. If the 1x node stays at 110 ms during peak hours while the 2x node stays at 95 ms, the 15 ms difference usually is not worth paying double quota for everyday browsing. If the former frequently rises to 300 ms while the latter remains below 120 ms, the high-multiplier route may be worth using as the primary peak-hour option.

• Labels such as “relay” and “direct” in node names are only route descriptions. Always defer to real connection results and the actual exit region.
• A single region may have multiple entry cities or network providers. Even similarly named nodes can perform completely differently during peak hours.
• Low-multiplier nodes help manage quota, but frequent retries, disconnects, or repeated downloads may make the actual experience and traffic cost no better.
• When you do not need a fixed exit region, keep candidates in two different regions so maintenance in one area does not leave you without an alternative.

How to Choose Between VMess, VLESS, and Trojan

Protocol type is first a compatibility requirement and only afterward a performance variable. The client must hand the subscription’s protocol, transport layer, and security parameters to a core that supports that configuration. Do not replace node fields manually just because a protocol name looks newer; mismatched server and client parameters cause the handshake to fail. For most users, the safest approach is to leave the subscription-provided configuration unchanged and compare route quality among nodes using the same protocol.

VMess is a common protocol in the V2Ray ecosystem, with broad coverage across older subscriptions and existing nodes. VLESS has a leaner protocol structure and is often handled by the Xray core; its actual configuration may also combine TLS, Reality, WebSocket, gRPC, and other transport or security methods. Trojan is closely tied to its TLS configuration, and an incorrect certificate domain, server name, or system time can cause connection failures. The protocol label alone cannot predict node speed; cross-region routing and server load often matter more.

If the same subscription offers VMess, VLESS, and Trojan nodes, group them by region and multiplier first, then choose two candidates from each group for real connection tests. Suppose the three protocols measure 84 ms, 78 ms, and 81 ms; the difference is too small to claim that one protocol is faster. Continue observing peak-hour jitter, first-connection success rate, and stability after 15 minutes of sustained use. Protocol differences are meaningful only to a limited extent when the entry point, exit region, and test period are the same.

Common Speed-Test Problems and Practical Fixes

When results look abnormal, first determine whether every node failed or only one node did. Simultaneous timeouts across all nodes usually point to the local network, core startup, subscription status, or proxy-port settings. If only one region or group fails, route maintenance, an expired group, or a server-side configuration change is more likely. The v2rayN core log records configuration parsing, port listening, and connection-handshake details, making it more useful for troubleshooting than repeatedly clicking the speed-test button.

Split routing can also make “the speed test works, but access results differ” look like a node failure. Rules may send some domains directly and others through the proxy, so the exit-IP lookup and the target service may use different outbound routes. During troubleshooting, temporarily switch to global proxy mode for comparison: if global mode works, the issue is probably in the routing rules or domain matching; if global mode still fails, check the node configuration, DNS, and core log.

Example Test Record
Region A / Node 1 / 1x
Off-peak: 62 ms, 68 ms, 71 ms
Peak: 105 ms, 118 ms, 126 ms
Exit: Matches the node label
Conclusion: Primary candidate

Region B / Node 2 / 0.5x
Off-peak: 96 ms, 103 ms, 101 ms
Peak: 112 ms, 119 ms, 115 ms
Exit: Matches the node label
Conclusion: Low-multiplier backup

Keep Primary, Backup, and Retest Records

After filtering, you do not need to keep only one node. A safer setup is two primary candidates and two backups, with backups preferably coming from different entry points or regions. Primary nodes should emphasize low everyday latency; backups should emphasize peak-hour stability or a lower multiplier. When the node list is too long, narrow it with subscription groups and keyword filters, but do not directly modify critical connection parameters supplied by the subscription.

1. First remove or hide nodes that timed out in all three rounds, as well as subscriptions that have expired and cannot be updated.
2. Within the target region, keep four to six candidates with low average real connection latency and small variation across the three rounds.
3. Compare 0.5x, 1x, and high-multiplier nodes, and record whether the high-multiplier route genuinely improves peak-hour performance.
4. Enable the system proxy for real-world access, use it continuously for at least 15 minutes, and watch for disconnects, reconnections, and loading pauses.
5. Record the test date, network type, region, multiplier, and results. Refilter the nodes after every major subscription update.

Node quality changes with route adjustments, server load, and local network conditions, so one speed test cannot represent performance forever. Retest weekly or whenever performance noticeably slows; do not switch constantly based only on the smallest number in the list. As long as the primary node remains stable during real usage hours, fits your quota plan, and provides the required exit region, it is the better choice for the current environment.