How to Choose a V2Ray Node: Latency, Traffic Multipliers, Regions, and Protocols

Step 1: Test latency and real connectivity

Low latency only means one part of a request was fast; it doesn’t guarantee fast downloads. A client’s latency test may measure a TCP handshake or an HTTP request sent through a proxy. Results from different methods, target addresses, or timeout settings aren’t directly comparable. One number in a node list doesn’t represent the full experience of reaching every website from your device.

A TCP test typically checks whether your device can connect to a specified port on the node server. For example, a result of 45 ms on port 443 means the TCP connection was established quickly; it doesn’t confirm that the UUID, TLS settings, REALITY parameters, or server egress are working. A real connectivity test sends a request through the proxy, making it closer to actual use, but it still reflects only that test target and the network conditions at the time.

Testing sequence in your client

Update your subscription first, then filter nodes using the same test method. The steps below use common v2rayNG menus as an example; labels may vary slightly between versions. In v2rayN, select a candidate in the server list and right-click to find the real connectivity latency test. Don’t treat figures from different clients or test addresses as a single ranking.

1. Update the subscription

   In v2rayNG, open the menu in the top-right corner and tap “Update subscription.” Make sure the node list has refreshed so you don’t test an expired address. A subscription link is an access credential—don’t paste it into public speed-test websites.

2. Run a real connectivity test

   Open the top-right menu and tap “Test real connectivity for all configurations.” Keep your network conditions unchanged and note successes, failures, and test times. Testing many nodes at once can cause contention; if results look unusual, retest a smaller set of candidates.

3. Repeat for three rounds

   Pick 3 to 5 candidates and repeat the test three times, about 30 seconds apart. Record every round, including timeouts; don’t keep only the lowest result. Testing uses a small amount of real traffic.

4. Verify the target service

   Switch to a candidate, connect, and open the website you actually need. Confirm that your routing rules send the target through the proxy; otherwise, a successful direct connection could be mistaken for a successful node. Verify again during your usual hours of use.

Step 2: Calculate traffic multipliers and quota usage

A traffic multiplier is usually a billing factor set by the provider, not a speed multiplier. The VMess or VLESS protocol used for a client connection doesn’t define how a subscription quota is charged. Labels such as “0.5x” or “2x” are usually provider notes; check the plan details and usage dashboard for the actual terms. Nodes in the same region can have different multipliers.

A basic estimate is “billed traffic = traffic measured for billing × multiplier.” Whether the provider counts uploads, downloads, or protocol overhead—and how it converts GB and GiB—depends on its billing rules. Compare plans using the same measurement basis; don’t estimate charges from the file size shown in your browser alone.

The table assumes there are no extra charges, the billing basis is consistent, and all traffic uses the same multiplier. For mixed usage, calculate each portion separately: 20 GB on a 0.5x node plus 15 GB on a 2x node comes to about 20 × 0.5 + 15 × 2 = 40 GB charged. A higher multiplier doesn’t guarantee better speed or access to a particular service.

• Web browsing and lightweight apps: Prioritize stability. You usually don’t need to pay a higher multiplier just to get lower latency on a single test.
• Video and large downloads: Estimate your weekly traffic first, then run a small-scale speed test. Speed tests also use quota.
• Specific exit-region requirements: Route only the traffic that needs it through a high-multiplier node; send the rest through other routes.

Step 3: Choose a node region for your needs

Use region labels to filter for the exit location you need, not to predict connection quality. Your device-to-entry, entry-to-exit, and exit-to-website routes may all differ. A node labeled as nearby might take a roundabout route, while a farther-away exit may be more stable thanks to better peering. Test on your own network instead of relying on someone else’s ranking.

If a service requires a specific region, first narrow your options to exits that meet that requirement, then compare connectivity and multipliers. Websites may also use account details, payment region, location permissions, and their own IP databases to determine your region. A location in a node’s name doesn’t guarantee that every service will recognize it as that location—or that the content you want will be available.

Everyday use and sustained downloads

Step 4: Check protocol and core compatibility

Make sure your client can run the subscription configuration correctly before comparing performance. v2rayN is a desktop client that can manage different cores; what it supports in practice depends on the selected core and its version. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Similar names don’t mean their protocol fields are interchangeable.

VLESS and VMess are proxy protocols; WebSocket is a transport; TLS and REALITY are connection security mechanisms; Vision is a flow-control mode in Xray. These are different layers, not interchangeable options. Don’t change a subscription’s WebSocket transport to TCP or switch TLS to REALITY just to lower latency. Without matching server-side settings, the connection will fail.

A protocol can’t make up for poor routing. Under the same network conditions, protocols and transports can affect handshake overhead and throughput, but cross-carrier congestion, entry bandwidth, and exit load also matter. A “new protocol” doesn’t automatically mean a faster node.

Keep notes on primary and backup nodes

Once you’ve completed the four steps, start with one primary and one backup; there’s no need to run full speed tests on every node every day. Record the test time, network, method, and target service. Results are comparable only when conditions are similar. Home broadband and mobile networks can produce different outcomes, so don’t rely on one fixed ranking.

• Primary node: Record the node name, exit region, multiplier, results from all three real connectivity tests, and whether your usual websites work.
• Backup node: Record the same details and, if possible, check whether its entry point or route differs from the primary. If you can’t confirm, note that instead.
• When to retest: Retest after changing networks, updating the subscription, noticing significant slowdowns, or seeing repeated failures during your usual hours.
• When switching: Try the backup first to see whether the problem affects one route, then check DNS, routing rules, and your local network connection.

For example, a node that passes all three real connectivity tests, has a 1x multiplier, and exits in the region you need may be a better primary even if its latency is 20 ms higher than another node’s. You might keep a 3x node that occasionally times out only for a specific need. The right choice depends on your use case; there’s no need to combine milliseconds, multipliers, and regions into an arbitrary score.

Common questions about choosing a node