When choosing a V2Ray node, first check that your current core supports its protocol, then use real-connection tests to rule out unusable options. Finally, compare peak-hour stability, server location, and traffic multipliers. This guide is for users who have imported a subscription but aren't sure how to rank its nodes. It provides repeatable test steps and billing examples, so you don't mistake one low latency reading for reliable long-term performance.
Latency tests: TCP reachability doesn't mean the proxy works
In v2rayN, a TCP latency test typically measures how long it takes the client to establish a TCP connection to a specified server port. It can show whether the server address and port are reachable, but it doesn't fully test proxy authentication, transport settings, or access to a destination website. If the port is open but the account credentials are invalid, the TCP test may still return a normal-looking result in milliseconds.
A real-connection test sends a request through the node to the test address configured in the client, covering more of the actual proxy route. Results can be affected by DNS resolution, the proxy handshake, the TLS handshake, the destination server's response, and connection reuse. Test implementations and timing scopes may vary between versions, so compare nodes in the same client using the same test address. Don't subtract the TCP result from the real-connection result to estimate the time spent on a specific part of the route.
| Test method | What it tells you | What it can't tell you by itself |
|---|---|---|
| TCP latency | Connection response from the server's specified TCP port | Whether authentication works, websites are accessible, or bandwidth is sufficient over time |
| Real-connection test | Result of accessing the test address through the proxy | Whether every website works or the connection is stable at all times |
| Download speed | Throughput to a specific destination at a specific time | Whether jitter and packet loss are low, or other destinations will be just as fast |
| Real-world task check | Whether the target webpage, video, or sign-in works as expected | Whether the exit IP will stay the same or access permissions will remain valid |
Testing v2rayN nodes: standardize conditions before ranking
Before running batch tests, pause large downloads and other speed tests, and keep the same network connection. Don't change Wi-Fi, proxy mode, and test address all at once during a test round; otherwise, you won't know what caused the results to change. Menu labels may vary by client version. The steps below refer to the options in the server list's right-click menu; if the wording differs slightly, look for the TCP and real-connection test options in your current interface.
-
Check test settings
Open “Settings” → “Parameter Settings” and find the setting for the speed test address or real-connection test address in your version. Note the current value. Keep the address unchanged while comparing nodes, and don't repeatedly adjust the timeout just to get a lower reading.
-
Check port reachability
Select a candidate in the server list, right-click, and run the TCP latency test. The menu item is commonly labeled “Test server latency (Tcping).” Note any timeouts separately instead of deleting those nodes right away; first check for network restrictions or a transport that doesn't use TCP.
-
Run a real-connection test
Select the candidate and right-click “Test server real connection latency.” Check whether the test succeeds consistently, and record the result separately from the TCP test. If TCP works but the real-connection test fails, check authentication, transport settings, TLS parameters, and the test destination first.
-
Repeat at different times
Test each shortlisted node five times and record the number of successful attempts and the median. Run another round during the evening hours when you typically use the service, rather than ranking nodes by their lowest reading during off-peak hours. Avoid repeatedly updating the subscription during testing, since that can change the candidate configurations.
-
Verify real-world tasks
Set a candidate as the active server, open a target website in your usual browser, then try a short download or video playback. Confirm that the app is actually using the proxy; setting an active server alone doesn't mean all app traffic is routed through it.
The median reduces the influence of unusually low or high readings, but it doesn't hide failures. If a node succeeds only twice out of five attempts, those two low-latency results don't make it a good everyday choice. For a rough idea of variation, you can subtract the minimum from the maximum, but don't call that range a standard jitter metric used in professional network testing.
Traffic multipliers: translate usage into quota costs
Traffic multipliers are usually a subscription provider's billing rule, not a VLESS, VMess, or Trojan protocol parameter. A 2× multiplier commonly means that twice the billable traffic is deducted from your quota. Check the provider's terms for whether uploads count, how units are converted, and whether billing varies by time. Multiplier labels in node names may be out of date, so check your plan details even after updating the subscription.
The following is an arithmetic example only. Assume the billing method has been confirmed and 10 GB is billable, without accounting for overhead or measurement differences. These figures aren't measurements from this site and don't describe the billing rules of any particular node.
- Batch testing also uses traffic. If a single download test generates 50 MB of billable traffic, testing 20 nodes once each uses 1,000 MB. At a 2× multiplier, about 2,000 MB will be deducted from your quota.
- A low multiplier doesn't mean low speed. The multiplier is set by the provider's billing rules; it doesn't reveal bandwidth, congestion, or connection stability.
- A high multiplier doesn't mean higher priority. Use a high-multiplier node regularly only if it performs better for your actual tasks and the quota cost is acceptable.
For everyday browsing and documents, a stable node with a low multiplier is usually easier on your quota. For large file transfers, also check your remaining quota and throughput over time so one fast download doesn't use up your allowance for the current billing period.
Server locations: distinguish the entry, exit, and destination
A location in a node's name usually describes its exit, but the name doesn't prove the full route. A relay node might connect to a nearby entry point first, then access the destination website from another region. An IP lookup in your browser can show the apparent exit location, but not the networks in between. Low TCP latency between your client and the entry point doesn't mean the entry-to-exit or exit-to-destination legs will be just as fast.
Geographic distance is only one factor. Peering between providers, cross-border routing, evening congestion, and the destination website's CDN can all affect performance. Nearby regions are a good place to start your shortlist, but don't treat location names as a fixed speed ranking. If you need content from a specific region, check separately how the service identifies the exit IP.
Stable everyday exit
RecommendedStart with regions that have a shorter route from your local network, then check real-connection results during peak hours and test your usual websites. Base your final choice on repeat results, not a location label or a single lowest reading.
Best for: browsing, document collaboration, everyday use
Region required for a specific service
First check which regions the service permits and review its account rules. Then test exit-IP detection and actual access. A matching region name doesn't guarantee the website will accept the exit IP.
Best for: legitimate access to services with specific regional requirements
Backup with a different route
Keep a node with a different entry point, exit location, or service route as a backup. Nodes with different names may share the same entry point and fail together, so don't assume they're independent based on their names alone.
Best for: switching when your primary node is congested or a region is down
Protocol types: check core support, then verify the full configuration
“V2Ray node” is a common term for a proxy configuration; it doesn't mean every node runs on the same core. v2rayN is a desktop client, and the core it calls handles the connection. On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Importing a link only confirms that the configuration was read; it doesn't confirm that the core supports its features.
| Protocol or combination | What to know | What to check first |
|---|---|---|
| VMess | The protocol provides authentication and encryption; it can be combined with different transport methods | Credentials, system time, transport type, path, and TLS settings |
| VLESS | The protocol doesn't encrypt traffic by itself; check the security layer and transport settings | Core support, TLS or REALITY, flow, and transport type |
| Trojan | Typically relies on TLS to protect the connection; a correct password alone isn't enough | Credentials, server name, certificate validation, and transport settings |
| VLESS + REALITY | Requires a core that supports this combination and matching server-side parameters | Server name, public key, shortId, flow, and related handshake parameters |
Protocol names don't tell you how fast a node will be. The same VLESS node can perform very differently on another entry network, sometimes more so than if you changed protocols. VMess and Trojan speeds also depend on the route, server load, and client device. For WebSocket transport, check the Host and path; for TLS, check the server name and certificate chain. Don't assume settings are interchangeable just because the protocol is the same.
Node selection order and common questions
Narrow your choices using five checks: supported by the core, connection works, target is accessible, results are consistent, and the cost is acceptable. This is usually more reliable than sorting once by milliseconds. Keep brief notes for your primary and backup nodes, including the test date, network connection, test address, number of successful attempts, multiplier, and target website results. Retest when network conditions change; there's no need to run a full set of download tests every time you open the client.
Why can't I open a webpage with a node that shows 30 ms?
First check whether the reading came from a TCP test or a real-connection test. If it was only a TCP result, run a real-connection test and check the logs for authentication or TLS errors. If the real-connection test succeeds too, check whether your browser is using the proxy and whether routing rules are sending the website through another outbound connection.
It’s fast during the day but slow at night. Should I change protocols?
First test your primary and backup nodes five times each during the same evening hours, then check them against the same website. If one route consistently gets worse, switch routes first. Only adjust settings based on server-provided configuration when the logs clearly show a protocol or transport incompatibility; changing the protocol on the client alone won't work.
What if download speeds are high but video keeps buffering?
Check that the download test and video use the same node and route, then check the connection to the video destination. The download server and video CDN may be different. Pause background downloads and retest with a backup node; don't use the results from a single speed test site as a substitute for testing video playback.
Should I always use global mode to test nodes?
The important thing is to ensure test requests actually go through the candidate node—not to force all everyday app traffic through the proxy. You can temporarily use global routing for a controlled test, then restore your usual rules. System proxy settings determine whether some apps use the proxy; routing mode determines where traffic goes after entering the core. Check them separately.
- Round 1: Remove candidates with unsupported cores or obviously incomplete configurations.
- Round 2: Use real-connection tests and your actual tasks to confirm availability; record failures as well as successful timings.
- Round 3: Compare stability during your usual hours, then choose an acceptable multiplier among nodes that meet your needs.
- Keep in the end: One everyday primary and one backup with a different route if possible. Don't chase the lowest number in the list.