For users who have imported a subscription but are unsure how to choose from dozens of nodes. Run real connection latency tests under the same network conditions, verify multipliers, regions, and protocols, then keep one primary node and two backups on different routes.
Test real connection latency before judging a node by its name
Latency is the time required for a request to leave your device, reach the test target, and return, usually measured in milliseconds. Lower numbers generally mean faster initial page responses and interactions, but latency is not bandwidth and does not determine stability on its own. A node showing 45 ms may deliver only 3 MB/s when downloading a large file, while another at 92 ms may consistently reach 18 MB/s.
Basic ICMP tests can be affected by disabled server responses, carrier prioritization, and intermediary routing policies. A real connection latency test in the client starts the relevant VMess, VLESS, or other supported outbound and reaches the test address through the node, making it closer to actual proxy performance. Before testing, pause downloads, cloud sync, and video playback that use bandwidth so local congestion is not mistaken for a node problem.
Update the subscription
In v2rayN 7.x, open “Subscription Groups” → “Update All Subscriptions.” In v2rayNG 1.10.x, open the top-right menu and select “Update Subscription.” This ensures you are not testing an expired configuration.
Confirm the core
On desktop, go to “Settings” → “Parameter Settings” → “Core Type,” then select the Xray core or the appropriate V2Fly core for the node protocol. Use the Xray core first for VLESS and REALITY configurations.
Keep the network consistent
Keep the device on the same network, pause background downloads, and note the test time. Do not directly compare figures collected over wired, wireless, and mobile networks.
Run the real test
In the v2rayN node list, select candidates from the same region and use “Test Server Real Connection Latency.” In v2rayNG, use “Test Real Connection for All Configurations” from the configuration-list menu. Wait for the entire batch to finish before sorting.
Repeat for three rounds
Leave about 30 seconds between rounds and record the median and number of failures. If the three results are 58, 64, and 61 ms, record 61 ms. A node that times out twice should not be your primary node.
Consider latency, jitter, packet loss, and throughput together
When filtering nodes, use real connection latency to eliminate unreachable or highly unstable candidates first, then run actual browsing and download tests. Latency helps assess interactive responsiveness; throughput helps assess large-file transfers and high-definition video. They measure different things. Keep the test target, time period, and local network consistent, or the figures cannot be meaningfully compared.
The range of results matters more than the single lowest value. A node producing 72, 76, and 79 ms across three tests may be less impressive than one with a low of 48 ms, but it is usually more stable than a node returning 48, 210, and 95 ms. The latter has a 162 ms spread and may cause pages to stall intermittently or connection setup times to vary wildly.
| Metric | Example result | How to assess it | Best for |
|---|---|---|---|
| Real connection latency | 61 ms | Below 100 ms usually provides responsive interactions | Web browsing, instant messaging, remote operation |
| Three-round spread | 18 ms | Lower values generally indicate less short-term variation | Meetings, persistent connections |
| Test failures | 0/3 attempts | Downgrade nodes with consecutive failures or frequent timeouts to backup status | Assessing availability |
| Actual throughput | 14.6 MB/s | Compare using the same test file and time period | Downloads, updates, high-definition video |
| Peak-hour performance | 82–105 ms | A smaller gap from daytime results makes a node more suitable as the primary | Long-term daily use |
- For web activity, prioritize nodes with low latency and little variation rather than chasing the highest download speed.
- For large files, compare sustained throughput and check the speed after 60 seconds—not just the peak during the first 3 seconds.
- For real-time communication, eliminate nodes that time out frequently, even if their single lowest latency result is excellent.
- If results suddenly worsen across the board, restart the local router first, then retest on another network.
Understand traffic multipliers and calculate actual usage
Labels such as “0.5x,” “1x,” and “2x” in node names usually describe billing multipliers, not speed. Transferring 1 GB of actual data through a 2x node may deduct 2 GB from your subscription allowance; through a 0.5x node, it may deduct 0.5 GB. The exact accounting method is set by the subscription provider, so follow its traffic policy and account records.
There is no fixed relationship between a multiplier and node quality. A high-multiplier node may use a more expensive route, or it may simply be priced by region or resource type; a low-multiplier node is not necessarily congested. First check your remaining allowance and monthly workload, then decide whether a higher multiplier is worthwhile for lower latency or better peak-hour stability.
Billed traffic = actual transferred data × node multiplier
Download a 4 GB file using a 0.5x node:
4 GB × 0.5 = 2 GB
Stream video using 3 GB of traffic through a 2x node:
3 GB × 2 = 6 GBRecommended approach: assign multipliers by task
Everyday browsing and downloads
- Prioritize 0.5x to 1x nodes
- Keep latency under 150 ms
- No timeouts across three consecutive tests
Real-time tasks and peak hours
- Prioritize stability over the lowest multiplier
- Compare the three-round spread after 20:00
- Use high-multiplier nodes only during critical tasks
Choose quality based on the task first, then calculate the multiplier cost. Do not assume a node marked 2x is automatically faster.
For example, if your monthly allowance is 100 GB and downloads are expected to require 40 GB, using a 2x node throughout could consume 80 GB for downloads alone, leaving little for browsing and video. Instead, assign large files to a stable 0.5x or 1x node and reserve the 2x node for short, latency-sensitive tasks.
Choose regions for the target service, not by distance alone
Physical distance affects latency, but routing quality, inter-carrier connectivity, and the target service’s location matter just as much. Nearby regions are usually a good first batch of candidates, but final decisions should rely on real connection tests and access to the actual target. A node may connect quickly to your device without providing an equally smooth route to the target server.
For ordinary web browsing, start by selecting three to five candidates in nearby regions. For services with region-based content delivery, choose nodes matching the target content region and verify that the account, pages, and resources load correctly. A region label only indicates the approximate exit location; it cannot replace a connectivity test.
Nearby-region nodes
RecommendedThey usually offer shorter routes and lower latency, making them good first-round candidates for a daily primary node.
Best for: web browsing, instant messaging, remote operation
Target-region nodes
When the exit location matches the target service region, these nodes are better for verifying regional content and actual reachability.
Best for: regional content, region-specific services
Long-distance, low-multiplier nodes
Latency may be higher, but stable throughput and a low multiplier can make these nodes suitable for background downloads and less latency-sensitive batch tasks.
Best for: large-file downloads, background sync
| Use case | Priority metric | Suggested filter |
|---|---|---|
| Ordinary web browsing | Latency and stability | Test nearby regions first and keep nodes that work in all three rounds |
| Live meetings | Low variation and low failure rate | Keep the spread preferably below 40 ms, with 0 test failures |
| Large downloads | Sustained throughput and multiplier | Test continuously for at least 60 seconds, then estimate billed traffic |
| Region-specific content | Exit region and reachability | Choose the target region and open the target page directly to verify it |
Infer the client and core from the protocol type
Subscription nodes usually include the protocol, transport layer, encryption method, server address, and port. You do not need to rewrite the subscription manually just to pursue a newer protocol, but the client core must support the configuration. If a node will not connect, check protocol compatibility and whether the subscription is complete before assuming a routing failure.
v2rayN is suited to centralized management of subscriptions, system proxy settings, and routing rules on desktop. v2rayNG uses the Xray core and works well with VLESS, VMess, and similar configurations on Android devices. v2flyNG uses the V2Fly core and is an option for V2Fly-compatible configurations. Whether the same subscription imports completely into both clients depends on the protocols and parameters it provides.
VLESS and REALITY
RecommendedUse the Xray core first, and confirm that the subscription provides required parameters such as the server name, public key, and short ID. Do not guess from the node name.
Best for: everyday primary configurations in v2rayN and v2rayNG
VMess and WebSocket
These are common in mature configurations. When troubleshooting, verify that the address, port, user ID, transport path, and TLS parameters were fully supplied by the subscription.
Best for: existing subscriptions and compatibility configurations
V2Fly-compatible configurations
On Android devices, use v2flyNG to import and test them. For extended parameters, first confirm that the V2Fly core supports them instead of repeatedly switching regions.
Best for: nodes that explicitly require the V2Fly core
Set up primary, backup, and retesting procedures
After filtering, do not keep only the node with the lowest latency. A safer setup includes one primary node, a backup in the same region with a different entry point or route, and a fallback in another region. This lets you switch quickly during server maintenance, regional routing fluctuations, or peak-hour congestion without retesting the entire subscription.
Record the test date, peak-hour latency, and multiplier in the client’s node remarks. For example: “Primary-61ms-1x-0708” and “Backup-88ms-0.5x-0708.” Subscription updates may overwrite local names, so important records can also be kept in local notes. Retest every one or two weeks, or immediately after repeated timeouts.
- Delete or hide nodes that fail to establish a connection in all three consecutive rounds.
- Group nodes by region and keep two or three candidates per group with strong real connection latency and stability.
- Run browsing, video, or download tasks during your usual hours and record actual performance for at least 10 minutes.
- Calculate multiplier usage and limit high-multiplier nodes to tasks that genuinely benefit from them.
- Configure a backup on a different route for the primary node, then reconfirm the system proxy status after switching.
What should I do if latency is negative or the test fails?
Update the subscription first, then confirm that the current core can read the node configuration. On desktop, check “Settings” → “Parameter Settings” → “Core Type,” restart the core, and run the real connection latency test again.
Why is a webpage still slow when latency is only 40 ms?
Check peak-hour throughput, DNS resolution, and the latter part of the route to the target site. Test three nodes against the same webpage; if only this node loads slowly, lower its priority instead of relying on a single latency result.
Is a 0.5x node necessarily worse than a 1x node?
Not necessarily. The multiplier represents billing weight, not speed. Run three rounds of real connection tests and a 60-second download test for both nodes, then decide based on your subscription allowance.
Do I need to test all the dozens of nodes in my subscription?
First filter to no more than 10 candidates by target region and protocol, then test them in batches. Remove timed-out nodes and retest the remainder during peak hours to reduce wasted effort.
Is it normal for a node to be fast today and slow tomorrow?
Short-term variation may come from the local network, cross-network routing, or server load. Retest three times using the same network and target. If performance remains poor across two consecutive periods you commonly use, switch to a backup node.
The final selection process has four steps: confirm protocol and core compatibility, then test real connection latency; use peak-hour stability and actual throughput to remove volatile nodes; finally, assign tasks based on the multiplier and target region. The lowest latency is only a candidate criterion. A suitable primary node must also be stable, sustainable, and cost-effective in traffic usage.