When choosing a node, first make sure it connects. Then compare real-connection latency and repeat-test results on the same network. Finally, filter by traffic multiplier, target location, and client compatibility. This guide is for users who have imported a subscription but aren't sure how to interpret test results. Follow the steps to choose a primary node and a backup with a separate failure path, instead of chasing the lowest number of milliseconds in the list.
1. What latency tests measure: TCP, real connections, and download speed
“Latency” in a node list isn't a standardized metric. A TCP test mainly measures how long it takes to connect to the server port. A real-connection test accesses a test URL through the proxy and may include the proxy handshake, connection to the destination, and response time. Clients, cores, and test URLs can all measure different intervals, so don't rank millisecond readings from different apps side by side.
| Metric | What it tells you | What it can't tell you on its own |
|---|---|---|
| TCP latency | Connection response from your device to the node's port | Whether authentication succeeds or a website is reachable |
| Real-connection latency | Whether a specified test destination responds through the proxy | Whether every website is reachable or the connection stays stable over time |
| Download speed | Throughput to a specified resource during the test | Performance during peak hours or responsiveness in interactive use |
| Failed repeat tests | Availability fluctuations under current conditions | Whether the node server is definitely at fault |
In v2rayN, select a node, open its context menu, and look for options such as “Test server real connection latency” and “Test server speed”; wording may vary by version. In v2rayNG, look in the top-right menu for “Test real connection for all configurations.” First use the connection test to filter out unavailable nodes, then run speed tests on just a few candidates instead of repeatedly testing the entire subscription.
2. Keep test conditions consistent: small batches, repeat runs, real-world use
The same node can produce different results on wired, Wi-Fi, and mobile networks. For a fair comparison, keep the network, test URL, client, and time of day consistent, and pause cloud sync and large downloads. Don't switch networks between tests; otherwise, routing changes can be mistaken for differences in node quality.
- Start with 3–5 candidates. Filter by connectivity and target location, then run real-connection tests. Don't run speed tests on every node at once.
- Test each node 3 times. Leave about 30 seconds between runs and record each response time and any failures. Use the median to gauge typical latency, but keep the highest reading too so that obvious fluctuations aren't hidden by an average.
- Use a consistent download sample. Compare only authorized, trusted test resources, and record the sample size and time taken. Check the node's multiplier first; speed tests can also use up your plan allowance.
- Test your actual use case. Open websites you use regularly, play a video at a fixed resolution, or make a real call. Test again during your usual hours; a single early-morning result doesn't reflect the evening experience.
These are test procedures and a calculation example, not a claim about measured performance on any particular route. For example, 20 MiB transferred in 5 seconds averages 4 MiB/s, or about 33.6 Mbps. Clients may report speeds in MB/s or use other conventions, so standardize units before comparing. Short tests are also affected by handshakes and connection warm-up, and shouldn't be treated as sustained download speeds.
Consider this hypothetical set of results: Node A records 70, 240, and 85 ms across three runs; Node B records 100, 105, and 102 ms. Neither has any failures. Node A has a lower median, while Node B is more consistent. Both may be fine for browsing, but Node B is worth trying first for remote interactive work. Three runs are only a first-pass check, though; they can't establish long-term reliability or a fixed packet-loss rate.
3. How traffic multipliers work: compare data allowance separately from speed
A traffic multiplier is usually a billing rule set by the service provider, not a protocol setting or a speed boost. If a panel shows a 2× multiplier, it commonly means that the measured data transfer is charged at twice the amount. It does not mean the node downloads twice as fast. Check the provider's terms, especially whether upload and download are both counted and whether it uses GB or GiB.
Billable traffic = traffic measured under the provider's rules × node multiplier
Assuming 10 GB of measured traffic:
0.5× multiplier → 5 GB deducted
1× multiplier → 10 GB deducted
2× multiplier → 20 GB deductedThese figures assume there are no additional billing rules. If your plan has 100 GB remaining, a 2× node could theoretically carry about 50 GB of measured traffic; a 0.5× node could carry about 200 GB. Actual usage and the panel's figures may still differ due to measurement scope and units, so treat this as an estimate, not an exact balance calculation.
- High-volume use: Compare sustained throughput and the multiplier first. For large downloads, a slightly faster node with a much higher multiplier may not be the better choice.
- Low-volume interactive use: Browsing and terminal sessions benefit more from responsiveness and successful connections. Once you understand the cost, a steadier route may be worth choosing.
- Unclear multiplier details: Check the node information in the provider's panel. A “low multiplier” label in a node name is just text; the client can't verify the actual billing rule.
- Run a small usage check: Stop traffic from other devices, note the panel balance, transfer a small amount of data with a known size, then compare after the panel updates. Keep in mind that simultaneous use on other devices can skew the result.
4. Choosing a location: your entry route and exit location aren't the same thing
A node's location can refer to at least three different places: the network entry point, the proxy exit, and the server hosting the website you visit. A location in a node's name usually identifies the exit label. It doesn't guarantee that your local network connects there first, or that the website will identify the exit as being in that same location. Relays, carrier peering, and content delivery policies can all change the actual route.
So “geographically closer” is only a starting point. A nearby route with significant detours may be slower than a farther route with better routing. Two nodes labeled with the same location can also perform very differently because of their entry points, upstream networks, or load. If your use case requires a specific location, check how the service actually identifies the exit rather than relying on the node name.
Nearby routes that stay stable during your usual hours
RecommendedIf you don't need a specific exit location, start with candidates in this category. Choose based on your repeat tests, multiplier, and real-world performance—not the location label alone.
Best for: everyday browsing, remote interaction, and a general-purpose primary node
Routes with an exit in a target location
First meet the location requirements of the service you use, then check latency and exit-location detection. The same location label doesn't guarantee the same access, account risk checks, or content availability.
Best for: use cases that specifically require an exit in a certain location
Backup routes with a different entry point or upstream
The goal is a different failure path from your primary node. A different node name won't help if both nodes share the same entry point and it goes down.
Best for: switching temporarily when your primary node is congested or under maintenance
5. Choosing between VLESS, Trojan, and SS: check compatibility first
The protocol determines how the client and server negotiate a connection, but it doesn't determine how fast the route is by itself. VLESS, Trojan, SS, and VMess can all be used on routes of varying quality. Bandwidth, congestion, the entry path, and server load usually affect throughput more directly than the protocol name. Protocol, transport, TLS, and routing are separate configuration layers—not a single measure of node quality.
| Type | Configuration to check | What to consider |
|---|---|---|
| VLESS | UUID, transport, security settings, and flow | The protocol itself doesn't provide transport encryption. If the configuration uses REALITY or Vision, the core must support those features. |
| Trojan | Password, TLS, and server name | Common configurations rely on TLS. If certificate verification fails, check the domain, system time, and configuration instead of disabling verification. |
| SS | Encryption method, password, and port | SS is short for Shadowsocks. The client must support the method specified by the server; check UDP support separately. |
| VMess | UUID, security options, and transport settings | Check the system clock. The protocol's own security mechanisms and outer TLS are separate settings. |
v2rayN is a desktop client, and its protocol support depends on the core in use. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. For subscription entries using REALITY or Vision, first make sure the bundled core can handle the configuration. A failure due to incompatibility doesn't mean the network in that location is poor.
- Keep the original subscription parameters: Don't manually change the transport, server name, or flow just to make node names look consistent.
- If you see an unsupported-field error: Note the client and core versions, then check the node's requirements. Don't just keep rerunning the latency test.
- For calls or gaming: Test UDP and the application's actual route separately. A successful TCP connection test doesn't mean UDP is working.
- To compare protocols alone: Keep the server and network conditions as consistent as possible. Speed tests across different providers and locations can't prove that one protocol is always faster.
6. Make your picks: one primary node and one independent backup
Once you've narrowed down your options, there's no need to rerank every node daily. Keep a small, well-documented shortlist and focus on everyday performance and failover. After updating a subscription, node IDs, ports, or multipliers may change. Check that the selected node still has the expected configuration, and recheck any exit-location requirements for your use case.
Recommended setup: verify your primary and backup separately
Primary node
- Run 3 real-connection tests during your usual hours.
- Check your regular websites and sustained-connection performance.
- Record the multiplier, exit location, and core requirements.
- Prioritize stability, then compare peak speed.
Backup node
- Choose a route with a different entry point or upstream if possible.
- Test in advance that it works for the same use cases.
- Record any differences in multiplier or location restrictions.
- After switching, reconnect the app or service and test again.
Choose based on repeatable results in your actual use case. The lowest latency from a single test is for shortlisting only, not a final verdict.
Switching nodes usually affects only new connections. Existing downloads, calls, or long-lived web connections may continue using the old route, so reopen the test page or reconnect the app before comparing. If the system proxy or routing rules don't send the test app through the proxy, switching nodes won't change its route.
7. Frequently asked questions about choosing a node
Why is a page still slow when latency is only 50 ms?
First check whether the reading came from a TCP or real-connection test, then try the actual website again. A fast TCP connection doesn't guarantee a quick proxy handshake, DNS lookup, or response from the destination. Run a real-connection test against the same destination, then compare the speeds of just two candidates. Testing many nodes at once can cause bandwidth contention.
The node test succeeds, but nothing changes in my browser. Which node should I switch to?
Don't switch nodes just yet. Check whether the system proxy is enabled in the v2rayN main window and whether routing rules send that destination directly. If the browser uses a manually configured proxy, verify the address and local port. For example, 127.0.0.1:10808 works only if that port actually provides a proxy protocol the browser can use; check the client settings.
Is a 2× node always faster than a 1× node?
No. The multiplier is a billing rule, not a bandwidth guarantee. Compare samples of the same size, then check stability in the evening. For occasional browsing, consider whether the better response time is worth the extra data usage. For large transfers, check your remaining allowance first.
Why is it fast on my computer but slow on my Android device? Is the protocol wrong?
Connect both devices to the same network and confirm they're using the same node and test destination. Then check core support in v2rayNG or v2flyNG, per-app proxy settings, and whether the device is using mobile data. Only after those conditions match should you investigate differences in the device or configuration.
Is it enough to keep only the fastest node?
Keep a verified backup as well, ideally on a different entry point or upstream. Record the test date, network type, three results, multiplier, and real-world performance. If the primary node has problems, reconnect the app and test the backup instead of relying on a single number from an earlier test.