For Android users who have imported a subscription but aren’t sure which node to use. First, filter out unavailable nodes with the same test. Then compare traffic multipliers and exit locations, and check protocol and client compatibility. Follow the steps below to choose a dependable everyday node and a backup on a different route—instead of sorting by lowest latency alone.
Check node availability in v2rayNG before comparing latency
Open the v2rayNG home screen and make sure your subscription group is up to date. Open the menu in the upper-right corner and select “Test real connection.” Depending on the app version, this may appear as “Test real connections for all configurations.” Choose the option that includes “real connection.” When the test finishes, keep nodes that returned a successful result; don’t delete a node based on a single timeout.
A TCP test, a real-connection test, and a download speed test measure different things. A TCP test mainly checks whether a connection can be established to the server’s listening port. A real-connection test routes traffic through the proxy to a test destination, giving you a better sense of whether the proxy path works. Neither test directly measures download bandwidth. A node reporting 80 ms can still slow down in the evening.
| Test | What it tells you | What it doesn’t tell you |
|---|---|---|
| TCP connection test | Whether your device can connect to the server port | Whether authentication, TLS, and access to the destination website work |
| Real-connection test | Whether the proxy route can reach the specified test destination | Whether every website is accessible or the exit location meets your needs |
| Download a fixed-size file | Actual transfer performance to that destination at that time | Whether the same speed will hold at other times or with other destinations |
| Test with the apps and sites you use | Whether everyday browsing, calls, or video work well enough | Whether the speed-test result will beat every other route |
Keep the network and test destination consistent when comparing results. Don’t rank a Wi-Fi result against one from mobile data, or mix v2rayN TCP latency with v2rayNG real-connection latency. Retest after switching to mobile data, since your carrier may use a completely different route.
- Pause large background downloads, stay on the same network, and run one round of real-connection tests.
- Pick 3–5 nodes that passed, test each one three more times, and record the median and number of timeouts.
- Retest during both a quiet period and your usual evening hours to see whether the connection stays reliable.
- Connect to a shortlisted node and open the websites you actually use. Check both initial page load and continued browsing.
Compare results under the same conditions; don’t draw conclusions from one low-latency reading
These are suggested comparison settings, not test results measured by this site. Use the same number of tests, time window, and download sample for each candidate to reduce random variation. Label nodes locally as A, B, and C; there’s no need to share their full addresses.
For example, node A returns 95, 98, and 420 ms; node B returns 125, 130, and 135 ms. Their medians are 98 and 130 ms, respectively, but A varies much more. These numbers only illustrate how to record results. If everyday websites repeatedly stall on A, the more consistent B may be a better primary node. Record timeouts separately—don’t remove failed samples and then call a route reliable.
How traffic multipliers work: check the provider’s rules, not just the node name
Check your subscription provider’s traffic policy or account dashboard to confirm what labels such as “0.5×,” “1×,” and “2×” mean. A multiplier is usually a billing factor, not a speed boost. “2×” doesn’t double your download speed; it means the same measured traffic may use twice as much of your allowance. Providers may handle uploads, downloads, units, and effective times differently.
| Node label | Example measured traffic | Traffic deducted at this multiplier |
|---|---|---|
| 0.5× | 10 GB | About 5 GB |
| 1× | 10 GB | About 10 GB |
| 2× | 10 GB | About 20 GB |
The 10 GB in this table is the traffic counted for billing by the provider; it isn’t the size of a downloaded file. If uploads and downloads are combined before applying the multiplier, calculate it from their total. If multipliers vary by time of day, recalculate using the rate in effect. Client and server traffic counters may also use different methods; follow the provider’s policy for your remaining allowance.
- Everyday browsing: Start with a reliable route with a reasonable multiplier; light browsing usually doesn’t require maximum throughput.
- Large downloads and long video sessions: Check your remaining allowance, the multiplier, and sustained speed. Estimate the total data charge before you start.
- No multiplier shown in the name: Don’t assume it’s 1×. Check the dashboard; subscription names may omit billing details.
- The name changed after a subscription update: Check the rules again instead of relying on an old screenshot for the multiplier.
Node location labels show the exit; performance also depends on the route in
Select a candidate node and connect, then check the location shown in the destination service’s account activity or connection details. The location in a node name, the server’s physical location, and the final exit location may differ. A relay can enter through a nearby server and exit in another region. The IP address returned by a domain lookup alone doesn’t prove where the traffic exits.
A nearby server often has a latency advantage, but peering, congestion, and detours can change the result. When accessing region-specific content, services generally determine your location using their own IP databases and account rules—not just the flag or label in your subscription. Matching the expected location doesn’t guarantee access; exit IP reputation, account region, and service restrictions can also matter.
- If you need a specific region, first check which location the destination service actually detects, then compare speed.
- For everyday browsing, prioritize reliability and responsiveness instead of automatically chasing a particular region.
- For a backup in the same region, look for a different entry point or route group. A different name may still use the same failure point.
- If Wi-Fi works but mobile data times out, record results separately and investigate differences in the access path.
VLESS, VMess, and Trojan: check compatibility before comparing routes
In v2rayNG, tap the edit control next to a node and check its protocol, server port, transport, and security settings. You don’t need to save any changes. The common port 443 doesn’t identify the protocol. Don’t switch VLESS to VMess to try to improve speed or disable TLS at random; client settings must match the server.
v2rayNG uses the Xray core, while v2flyNG uses the v2fly core; their support for extensions isn’t interchangeable. When using v2rayN on desktop, check which core actually handles the node. For configurations using REALITY, a particular flow, or specific transport settings, make sure the core version matches the server’s requirements. A protocol name alone doesn’t indicate latency or bandwidth.
VLESS: an everyday option when the settings match
RecommendedVLESS doesn’t encrypt the payload by itself and is commonly paired with TLS or REALITY. Check the security layer and transport settings, then test the route as described above. Consider it when you already have a compatible configuration; that doesn’t mean every VLESS node is faster than other protocols.
Best for: v2rayNG users whose subscription provides a complete configuration compatible with Xray
VMess: keep a configuration that already works well
VMess supports authentication and encryption and can use different transports. Modern configurations typically use AEAD with an alter ID of 0, but import the settings required by the server. A device clock that’s significantly off can interfere with authentication, so enable automatic time sync first.
Best for: users with a reliable VMess subscription who want to keep using their current route
Trojan: pay close attention to TLS settings
Trojan typically protects connections with TLS and uses password authentication. Check the password, server name, and certificate verification settings. An open TCP port doesn’t mean the TLS handshake or authentication succeeded; run a real-connection test as well.
Best for: users whose server provides complete Trojan settings and whose client supports the required transport combination
If two routes use VLESS and Trojan but have different entry points, exits, or bandwidth resources, you can’t attribute a speed difference to the protocol. Protocol overhead is worth comparing only when other conditions are similar. For everyday use, correct setup, reliable access, and reasonable billing usually matter more than the protocol name.
Choosing a primary and backup: test on Android, then retest on desktop
After narrowing down your options, keep one everyday primary node and one backup. You can add local notes about their purpose, multiplier, and test date, but don’t change the address or authentication fields. Subscription updates may overwrite local names, so save long-term notes separately. When sharing a subscription across devices, follow the provider’s device and concurrent-connection limits.
Suggested setup: one everyday primary node and one backup on a different route
Android：v2rayNG
- Run real-connection tests on both your usual Wi-Fi and mobile network.
- After connecting, verify that websites load and check VPN permission and per-app proxy settings.
- Prioritize reliability and a reasonable multiplier for your primary; choose a backup with a different entry point if possible.
Desktop: v2rayN
- Update the subscription and test again; don’t copy your phone’s latency ranking.
- Check the active core and node settings, then review system proxy or TUN mode.
- Compare using the same destination and network, and record how the node performs in the apps you actually use on desktop.
A shared subscription gives both devices the same list of candidates, but their networks, proxy settings, and core versions differ. The best primary node may not be the same on both.
V2Ray node selection FAQ
Why does the node with the lowest latency load websites more slowly?
Stay on the same network, connect to the node, and open a website you use regularly. Then repeat the same steps with another candidate. The test destination may take a different route from the website you’re using, and page loads can also depend on DNS, exit congestion, and the destination’s response time. Repeat the test three times and note timeouts and stalls instead of keeping only the lowest reading.
All nodes time out in the real-connection test. Do I need to buy a new subscription?
Disconnect and make sure your basic internet connection works. Then check the address under “Subscription group settings” and select “Update subscription” from the home screen menu. Check your account allowance, system time, and client logs. If node ports are reachable but every real-connection test fails, check whether the test destination itself is unavailable before assuming all servers are down.
Why do only some apps work after I select a node?
In v2rayNG, open “Settings” → “Per-app proxy” and check that it’s enabled, review the proxy mode, and confirm the target app is included. Then check whether routing rules send the target domain directly. Reconnect the VPN and restart the app after making changes. Selecting a node from the list doesn’t mean all app traffic will use it.
A node is marked 2×. Is it a better choice?
Check the provider’s multiplier policy, then compare reliability and sustained speed under the same conditions. If measured traffic is 5 GB, a 2× rule would deduct about 10 GB. If its performance is similar to a 1× option, the higher multiplier offers no direct benefit. It’s worth considering only if the route solves a location or reliability issue you actually have.