After importing a subscription into v2rayN, v2rayNG, or v2flyNG, node names often combine region, route, traffic multiplier, and protocol details. They may look complicated, but you do not need to investigate every entry. First confirm that a node connects, then compare real connection latency, filter by exit region and multiplier, and only then check protocol and core compatibility. This usually narrows dozens of candidates down to three to five.
This guide is for users who have just imported a subscription and are unsure how to prioritize a large node list. Filter in this order: availability, real connection latency, geographic distance, traffic multiplier, and protocol compatibility. Then use three tests and a short real-world browsing check to choose primary and backup nodes.
Filter in a fixed order instead of chasing the lowest number
The lowest latency in a node list does not necessarily mean the best experience. One node may test at just 42 ms while its exit bandwidth is congested; another may show 86 ms yet consistently load pages, buffer video, and transfer large files. A single result can also be affected by local jitter, temporary server load, or changes in the test target. The right approach is to remove unusable nodes first, then retest the remaining candidates.
- Check availability: Run one real connection latency test first, then remove or hide nodes that repeatedly time out.
- Filter by region: For everyday browsing, favor exit regions that are geographically closer and use shorter routes.
- Compare multipliers: When the experience is similar, choose the lower-multiplier node to avoid consuming your subscription traffic too quickly.
- Verify the protocol: Confirm that the VMess or VLESS configuration loads correctly with the current core.
- Test real-world access: Observe the same website on the same network for five to ten minutes.
Use real connection tests and watch stability
v2rayN may show results from different types of tests. ICMP Ping mainly measures the network round-trip time between your device and an address, but some servers do not respond to these requests, and the node entry address may not be in the same location as the actual proxy exit. Real connection latency establishes a connection through the proxy core, making it closer to the handshake cost of everyday browsing. Download speed tests also account for exit bandwidth, the test file, and concurrent transfers, so they help measure throughput but should not replace latency tests.
| Test | What it mainly measures | Best for evaluating | Common mistake |
|---|---|---|---|
| Ping | Basic network round-trip time | Whether the entry route takes a detour | Treating no response as proof that the node is unusable |
| Real connection latency | Time required to establish a connection through the proxy | Webpage loading and short-connection performance | Ranking nodes after only one test |
| Download speed test | Throughput between the node exit and the test target | Video playback and file download performance | Ignoring the local bandwidth limit |
For example, on a home connection with 300 Mbps downstream bandwidth, three candidate nodes may show real connection latencies of 48 ms, 76 ms, and 182 ms, with three-test variations of 6 ms, 11 ms, and 95 ms. The first is usually suitable for interactive tasks, the second remains a reliable backup, and the third may still show occasional high download speeds yet pause noticeably when opening several pages. The key issue to eliminate is high variance, not just a higher average.
- Run three consecutive tests about 10 seconds apart so a momentary spike in congestion is not mistaken for long-term performance.
- Prefer nodes whose three results are close, such as 72, 78, and 75 ms.
- Be cautious with nodes whose results swing sharply, such as 65, 310, and 94 ms.
- Test once during the day and once in the evening to see whether performance consistently degrades during peak hours.
- Pause cloud sync, system updates, and other high-bandwidth tasks during testing.
Traffic multipliers determine usage cost; speed still needs a separate test
A traffic multiplier describes how the service counts subscription traffic. Transferring 1 GB through a 1× node usually uses 1 GB of quota; the same transfer through a 2× node usually counts as 2 GB; a 0.5× node may count only about 0.5 GB. Follow your subscription provider’s documentation for the exact rules. A multiplier is a billing or usage-statistics parameter, not a field of the V2Ray, VMess, or VLESS protocol itself.
A high-multiplier node is not necessarily faster or more stable. Multipliers may distinguish entry resources, bandwidth costs, or route types, but the experience still depends on your local carrier, cross-region routing, server load, and exit bandwidth. For everyday web browsing, documents, and music, start with 0.5× or 1×. For a temporary high-bandwidth task, compare 1.5× or 2× candidates to confirm that they actually deliver higher, more consistent speeds.
Nearby low-multiplier node
RecommendedLatency is usually lower and traffic usage is easier to control, making this a good long-term primary node. Sustained speeds reaching 30–50% of your local bandwidth are generally enough for web browsing and high-definition video.
Best for: everyday browsing, documents, audio and video, and long-lived connections
High-multiplier optimized node
On some networks, it may offer better peak-hour routing or throughput, but verify the actual benefit with the same test target first.
Best for: short downloads, peak-hour backup, and situations with a clear need for speed
Distant standard node
Physical distance and route hops are usually greater, which may increase latency, but these nodes can still be useful when you need a specific exit region.
Best for: tasks that require a specific exit region
Choose regions based on both entry distance and exit requirements
A region name usually describes the proxy exit or a route group; it does not necessarily show every leg of the data path. For ordinary browsing, start with a region closer to your current location: shorter propagation distance and fewer routing variables often make connection setup and concurrent page-resource loading more stable. When website content, account regions, or service endpoints depend on a particular location, however, the exit region may matter more than the lowest latency.
- Everyday use: Start by testing nearby regions, then choose the node with lower latency and less variation among nodes with the same multiplier.
- Video playback: In addition to latency, watch buffering and download speed for five continuous minutes.
- Real-time communication: Prioritize low latency, low jitter, and low packet loss; peak speed is not the main metric.
- Large file transfers: Choose a node with higher sustained throughput, even if its latency is 30–50 ms higher than your primary node.
- Location-specific content: Meet the exit-region requirement first, then compare latency and multiplier within that region’s group.
Labels such as “direct,” “transit,” and “dedicated route” in node names are provider-specific route tags, so performance cannot be inferred from the name alone. A safer approach is to record three real metrics: the median of three real connection latency tests, whether the connection drops during five minutes, and the stable download speed for the same test file. For example, node A may deliver 58 ms latency and 38 Mbps with no drops, while node B shows 45 ms but fluctuates repeatedly between 4 and 72 Mbps. Node A is usually more predictable for interactive use.
The same node can behave differently on different access networks. Stable home broadband does not mean a mobile hotspot will use the same route; conversely, a node congested during the evening peak may recover the next day. Keep two levels of choice: a frequently used primary node and a backup from a different region or route group. Do not select both based on a single ranking.
Check compatibility before comparing protocol features
VMess is a long-established protocol in the V2Ray ecosystem and commonly appears with transports such as TCP, WebSocket, and TLS. VLESS separates authentication and transport more clearly and does not provide encryption by itself; it is commonly paired with TLS or secure transports such as Reality supported by Xray. For most users, a protocol name is not a speed rating. On the same route, server load and network routing often affect the experience more than the difference between VMess and VLESS.
The desktop client v2rayN can use a suitable core for the configuration. On Android, v2rayNG generally uses the Xray core, while v2flyNG uses the v2fly core. Whether a subscription node works depends on the client version, core capabilities, and matching configuration fields. If import succeeds but startup fails, check the logs for protocol, transport-layer, and parameter errors instead of repeatedly testing latency.
-
Update subscription
In the v2rayN main window, open “Subscription Groups,” choose Update All Subscriptions, and confirm that the node name, address, port, and protocol fields have been refreshed.
-
Choose a core
Go to “Settings” → “Parameter Settings” → “Core Type,” then choose a compatible core for the node protocol. VLESS with Reality configurations generally work best with the Xray core.
-
Confirm ports
Check the local listening settings. Common configurations use SOCKS port 10808 and HTTP port 10809; if you changed them, use the current values shown in Parameter Settings.
-
Start the node
Set the candidate as the active server, start the core, and review the logs for port conflicts, missing fields, or mismatched transport parameters.
-
Retest
Run three real connection latency tests on candidates in the same region and with the same multiplier, then compare actual performance using a fixed webpage and test file.
| Configuration type | Common combinations | What to check |
|---|---|---|
| VMess | TCP、WebSocket、TLS | Verify the UUID, port, transport, and TLS settings |
| VLESS | TCP、WebSocket、TLS、Reality | Verify flow control, security type, server name, and public-key parameters |
If two nodes share the same region, multiplier, and route but use different protocols, run each for ten minutes before comparing them. Record initial webpage response time, stability while loading multiple resources, and whether the core log shows reconnects. Do not replace a stable node just because a protocol was updated, and do not ignore client or core updates simply because an old node still connects.
Build three tiers: primary, backup, and task-specific nodes
After the initial filtering, do not chase the lowest latency in the list every day. A more practical setup has three tiers: the primary handles most everyday traffic, the backup is ready when the main route is congested or under maintenance, and the task-specific node is enabled only when you need a particular region or higher throughput. This reduces frequent switching and makes it easier to identify meaningful changes after a subscription update.
- Primary node: Prefer a nearby 0.5× or 1× node with low variation across three tests and stable real-world access.
- Backup node: Choose a different entry point or region group to avoid sharing exactly the same failure path as the primary node.
- Task-specific node: Keep one for a particular exit region, high bandwidth, or protocol requirement, then switch back to the primary when finished.
- Retest regularly: Run the three-test check again after a subscription update, a change in access network, or repeated reconnects.
Why does the lowest-latency node feel slow?
Run three consecutive tests, then perform one download speed test. If latency stays between 40 and 60 ms but speed remains below 2 Mbps, or the logs show frequent reconnects, a responsive entry does not guarantee stable exit bandwidth. Switch to a candidate with less variation.
What if every node times out?
Check the system time, confirm that the subscription is up to date, and verify that the core started successfully. Then go to “Settings” → “Parameter Settings” and make sure the local ports are not in use. If another program occupies 10808 or 10809, change the listening ports and restart the core.
Should a high-multiplier node stay enabled all the time?
No. First compare sustained speeds for the same task. If a 2× node offers no clear benefit over a 1× node, switch back to a low-multiplier node for everyday use and reserve the high-multiplier route for short, high-bandwidth tasks.
What if the primary node disappears after a subscription update?
Update all subscriptions and check the group filters first. Node names may have changed, so identify candidates again by region, multiplier, protocol, and actual latency instead of relying on the old name. If you cannot find it, select three to five new candidates from the same group.
Which should you choose, VMess or VLESS?
Choose the configuration that the current client and core can load reliably, then compare route performance. In v2rayN, go to “Settings” → “Parameter Settings” → “Core Type” to confirm the core. For VLESS with Reality, the Xray core is generally the preferred choice.
The final rule can be summed up in one sentence: once exit-region and protocol compatibility requirements are met, prefer a nearby low-multiplier node with low variation and stable real-world performance. Latency helps with initial filtering, the multiplier controls traffic cost, the region determines routing and exit requirements, and the protocol determines whether the configuration works correctly. Considering all four is more reliable than chasing the lowest latency or highest multiplier alone.