This guide is for users who have imported a subscription but are unsure which node to choose. The focus is on building a repeatable testing method, then combining latency, stability, multiplier, region, and protocol data to select primary and backup nodes—not simply picking the lowest number in the list.
Test real connections, not just the latency shown in the list
The latency shown beside a node name usually reflects only one type of probe. A TCP probe mainly checks whether a connection can be established to the target address and port; it may not complete the proxy protocol handshake or pass through TLS, WebSocket, or gRPC transport layers. It is useful for quickly filtering out timed-out nodes, but it cannot fully represent page-load speed or sustained transfer performance.
A real connection test makes the client send an actual request through the node, so it more closely matches everyday use. The result includes the local network, entry route, server processing, protocol handshake, and target-site response. Test addresses and calculation methods can vary between client versions, so compare nodes on the same device, network, and time window rather than comparing absolute numbers shown on different devices.
-
Update the list
Update the current subscription first and confirm that node names, addresses, and groups are current. An outdated configuration may still appear in the list but no longer complete the handshake.
-
Check the core
In v2rayN, open “Settings” → “Parameter Settings” → “Core Type” and choose a core that matches the node protocol. Field locations may vary slightly between versions, but avoid switching cores repeatedly during testing.
-
Establish a baseline
Close programs that are downloading files or syncing data, then test each candidate node three times in succession. Leave about 10 seconds between tests and record the median rather than only the lowest value.
-
Test real latency
In v2rayN’s server list, select a candidate and run the real-connection latency test; in v2rayNG, use the test function in the node list to perform an actual connection check.
-
Verify sustained transfer
After connecting through a candidate node, open a few commonly used websites and run an actual 60-second download or video playback test. Watch for sudden speed drops, repeated buffering, or disconnections.
What latency, jitter, speed, and packet loss each tell you
Latency determines how long interactive actions feel, especially initial page loads, remote terminals, and real-time requests. Jitter is the amount of variation across test results; the greater the variation, the more inconsistent the experience. Download speed reflects sustained throughput, but it is also affected by server bandwidth, target-site limits, local broadband, and the testing period. No single metric can replace the others.
Below is a screening baseline from consecutive evening tests on the same broadband connection and device. These figures illustrate the decision-making method and do not represent fixed performance for any region. Assume the local network is idle, the client’s local SOCKS port is 10808, the HTTP port is 10809, and every candidate has completed three real-connection tests.
| Test result | Common interpretation | Recommendation |
|---|---|---|
| Low latency, little variation | The round trip is stable, so interactive requests are generally smoother | Prioritize it as a primary node |
| Low latency, frequent timeouts | The entry point is reachable, but the proxy handshake or downstream route is unstable | Do not choose it based on the lowest value alone |
| Higher latency, stable speed | The physical distance is greater, but bandwidth and sustained transfer are better | Suitable for large files or long playback sessions |
| Both latency and speed fluctuate | The route may be congested, or the local network may be competing for bandwidth | Retest at another time before deciding |
The port number itself says nothing about how fast or reliable a node is. Port 443 is commonly used for TLS services, but using 443 does not make a route more stable; a high-numbered port does not mean lower quality. What matters is the complete connection path. If local ports 10808 or 10809 are occupied by another program, the client log may report a listener failure. Every node may then appear unavailable, so change to an unused port in the client settings first.
Calculate traffic costs before judging a node by its price label
A multiplier determines how much subscription traffic is deducted when you use a node. With a 0.5× node, 10 GB of actual transfer is typically counted as 5 GB; with a 2× node, it is typically charged as 20 GB. Whether uploads and downloads are counted together, and when traffic is settled, depends on the subscription provider’s billing rules.
A low multiplier does not necessarily mean low speed, and a high multiplier does not automatically indicate a better route. Multipliers may reflect route costs, entry quality, regional resources, or operating policies. Start by estimating your workload: browsing and messaging use relatively little traffic, so stability may matter more; system images, video, and cloud sync consume much more, so consider both the multiplier and sustained speed.
Recommended approach: use a stable primary node and control the multiplier for downloads
Everyday interaction
- Prioritize nodes with minimal latency variation
- A multiplier from 0.8× to 1× makes usage easier to control
- Keep a backup with a different entry route in the same region
Sustained transfer
- Run a speed test lasting at least 60 seconds first
- Calculate the chargeable usage by multiplying actual transfer volume by the multiplier
- Avoid entry routes that remain congested in the evening
For example, a plan that transfers 120 GB per month would typically count about 60 GB on a 0.5× node and may count 240 GB on a 2× node; the multiplier directly affects your remaining allowance.
- 0.5× node: Suitable for high-volume downloads and updates, but verify route stability first.
- 1× node: Straightforward billing, suitable for everyday browsing, work, and ordinary video use.
- 2× or higher node: Choose it only when its latency, entry route, or target region genuinely fits your needs; a high multiplier is not a quality certification.
Choose a region based on the destination, not its name
A region label describes the approximate location of the server or egress point, not the complete route. Two nodes with the same region label may use different entry points, carriers, and return paths, producing latency differences of dozens of milliseconds. Physical distance usually affects round-trip time, but network routing does not always follow the shortest geographic path.
For everyday browsing, start by testing geographically closer regions, then adjust based on how commonly used services respond. When accessing corporate systems, developer services, or content platforms tied to a particular region, the target server’s location often matters more than the node name. If the second half of the route from the node to the target site is congested, the final page may still load slowly even when the local-to-node latency is only 40 ms.
- Low interaction latency: Test nearby regions first, focusing on the median and variation across three real-connection latency tests.
- Region-specific services: Choose a node near the target service’s egress location, then actually test login, search, and file retrieval.
- High-volume transfer: Use region only as an initial filter; make the final decision based on sustained speeds of at least 60 seconds and the number of interruptions.
- Cross-device use: Use v2rayN on desktop and v2rayNG or v2flyNG on Android. Test each platform separately because mobile and home-broadband routes may be completely different.
How to choose between VMess, VLESS, and Trojan
The protocol determines authentication and data encapsulation, but node speed is usually influenced more by the route, server load, transport method, and encrypted link. You cannot conclude that VLESS is always faster than VMess or that Trojan is always more stable. The first rule for protocol selection is to match the client core with the server configuration.
VMess is a common protocol in the V2Ray ecosystem. It authenticates with a user identifier and relies on an accurate system clock for relevant checks. VLESS has a leaner structure and is often combined with TLS, REALITY, and other security or transport settings, but its capabilities depend on the core and server in use. Trojan typically runs over a TLS connection and authenticates with a password; the server name, certificate-related options, and transport parameters must be entered correctly.
VMess
Compatible with traditional V2Ray configurations, with common combinations including TCP, WebSocket, and TLS. A significantly incorrect device clock may cause authentication failures.
Best for: existing VMess subscriptions and configurations that need compatibility with the v2fly core
VLESS
RecommendedIts authentication structure is streamlined and can be combined with various transport and security settings. When using features such as REALITY, choose an Xray core that explicitly supports the relevant configuration.
Best for: subscriptions that explicitly provide VLESS and desktop use with v2rayN
Trojan
Requires complete TLS parameters; the server address, port, password, and server name must match. Certificate or clock problems directly affect the handshake.
Best for: subscriptions that provide a complete Trojan configuration
v2rayNG typically uses the Xray core and works well with VLESS, VMess, and Trojan configurations provided by subscriptions. v2flyNG uses the v2fly core and is better suited to configurations within the V2Fly support range. If a subscription node relies on a feature specific to a particular core, do not convert it by changing only the protocol name or force an import after removing security parameters.
The same protocol can also behave differently depending on the transport. WebSocket, gRPC, TCP, and different TLS configurations vary in handshake count, encapsulation overhead, and network adaptability. Treat the protocol, transport, security layer, and core as one complete configuration when choosing a node; do not focus on just the VMess or VLESS field.
Build a primary, backup, and retest list
Choosing nodes is not a one-time task. Routes change with the time of day, entry-point load, and local carrier routing. A more practical setup is to keep one primary node, one backup with a different entry point in the same region, and one fallback in another region. When timeouts or speed drops occur, you can switch quickly and narrow down the problem.
- Run three consecutive real-connection tests for each candidate and record the median and number of timeouts.
- Choose two or three candidates, run a 60-second sustained-transfer test for each, and record the average speed and whether the connection drops.
- Convert the multiplier into actual subscription usage. For example, 20 GB of transfer counts as about 16 GB at 0.8× and about 30 GB at 1.5×.
- Retest once in the morning and once in the evening. If evening latency rises by more than 80 ms and sustained speed drops noticeably, move the node to the backup list.
- Keep the protocol and core matched. Once a configuration connects, do not casually remove TLS, the server name, or transport parameters just to chase a lower number.
Why is the lowest-latency node sometimes slow?
Low latency only means that the probe request returned quickly; it does not guarantee sufficient usable bandwidth. Run a 60-second real-transfer test for the node and compare it with another entry point in the same region. If speed remains low or repeatedly drops to zero, move it to the backup list.
Why does the result jump between 60 ms and 300 ms?
Pause downloads and cloud sync first, then run three consecutive tests. If the results still fluctuate widely while the local network is idle, the route has significant jitter. Keep the node with more consistent results rather than one that occasionally produces the lowest value.
All nodes time out. Should I change protocols one by one?
Do not change the protocol immediately. First check that the subscription is updated, the system clock is correct, the core is running, and local listening ports such as 10808 and 10809 are not conflicting. Then review handshake or connection errors in the core log.
Why does the same subscription work on desktop but not on Android?
Compare whether the protocol, transport, security layer, and server name were imported completely on both devices. If a node depends on a specific core feature, select compatible clients separately for desktop and Android; do not judge compatibility from the node name alone.
How often should I retest latency?
For everyday use, retest the primary and backup nodes once a week. Run three latency tests and a 60-second transfer check immediately after repeated timeouts, a major evening speed decline, or a large subscription update.
The final choice can follow this order: confirm configuration and core compatibility, use real-connection latency to remove unavailable nodes, use jitter and sustained speed to identify stable ones, calculate multiplier costs, and then choose a region based on the target service’s location. This produces a more reliable node set than sorting by name or a single latency reading.