Start by choosing an exit region that matches the service you want to use, then check that your client core supports the protocol. Next, compare real connection latency and stability, and factor in the traffic multiplier. This guide is for new users who have imported a subscription but aren't sure which server to pick. Follow these steps to narrow a long list down to everyday, high-traffic, and backup nodes—instead of choosing by the lowest ping alone.
What the Four Node Details Tell You
Node names are labels supplied by the provider, not performance reports verified by the client. Check names like “Hong Kong,” “dedicated line,” or “high speed” against the actual exit region, performance for your use case, and plan details for the traffic multiplier. A subscription distributes connection settings; it doesn't guarantee that every node will always be available.
| Detail | What it tells you | What it doesn't tell you |
|---|---|---|
| Latency | Request response time and variation | Sustained download speed or whether video will play |
| Traffic multiplier | How usage is weighted for billing | Bandwidth, route quality, or priority |
| Region | The exit IP's location and whether it suits the service | The full route or actual distance |
| Protocol | Whether the client core supports the protocol and connection settings | Which route is faster within the same region |
Choose one specific task to test, such as opening a frequently used website, streaming a particular video, or downloading a file. The same node may work well for browsing but struggle with large downloads. Run all tests on the same network, against the same destination, and at roughly the same time. Don't compare results from home broadband with results from a mobile network.
Test Latency: Port Connectivity vs. a Real Connection
TCP latency can show whether a connection to the server's port can be established. It doesn't confirm that proxy authentication, the TLS handshake, and access to the destination all work. A real-connection latency test accesses a test address through the selected node, so it better reflects the full proxy path—but only for that address. If the test address is restricted, the test may fail even when your actual service still works.
-
Choose Candidates
In the v2rayN main window, select 3–5 servers suited to the same task. First rule out nodes that aren't included in your plan, have expired, or use an unsupported protocol. There's no need to test the entire subscription repeatedly.
-
Test the Real Connection
Right-click the server list and select “Test real connection latency (multiple selection).” Menu wording and parentheses may vary by version. Choose the option that says “real connection latency”; don't treat a TCP latency test as equivalent.
-
Repeat and Record
Test the same nodes three times and record the number of successful tests, median latency, and highest latency. Pause downloads and cloud sync during testing, and keep the test address the same.
-
Test Your Actual Use Case
Set a candidate as the active server, then open the website or video you actually want to use. The test button can connect through a node directly; whether your browser uses that node depends on your system proxy and routing settings.
For example, one node might return 80, 85, and 900 ms across three tests, while another returns 120, 125, and 130 ms. These are illustrative figures, not results measured by this site. The first node has the lowest reading but also a major spike; the second may be better for a series of web requests. The median reduces the impact of a single outlier, but keep track of failures and the highest reading too.
Understand the Multiplier: Keep Traffic Costs Separate from Speed
A traffic multiplier is a provider's billing rule, not a V2Ray protocol field or a speed multiplier. In many plans, billed traffic is approximately actual usage multiplied by the multiplier. Check your plan to see whether uploads and downloads both count, how units are converted, and whether the multiplier changes by time of day.
These figures are for illustration only. Under the same rule, 10 GB through a 0.5× node would count as 5 GB. A lower multiplier doesn't mean slower speeds, and a higher one doesn't guarantee a stable connection. Billing weight and network performance are separate factors.
- Browsing and messaging: These usually use little data. Prioritize connection reliability and consistent response times, then compare multipliers.
- Streaming and downloads: First make sure sustained throughput is sufficient. Then choose a lower-multiplier node from those that work, rather than relying on a high-multiplier route over the long term.
- Speed tests: Tests transfer data and may count against your plan. Test only a few candidates; don't repeatedly run download speed tests on every node.
The client's cumulative traffic and the provider's billing records may differ because of measurement methods, refresh intervals, and protocol overhead. Check your provider account for remaining data; the client's download counter alone may not match the final billed amount.
Choose a Region: Check the Exit, Not Just the Node Name
A region in a node's name may refer to its exit location, an entry point, or simply the route label. With a relayed connection, the server you connect to and the exit IP seen by a destination website may differ. First determine which exit region your target service requires, then compare candidate routes in that region.
Choosing a Region: General Browsing vs. Region-Specific Services
General Browsing
- If you don't need a specific region, start by testing nearby locations.
- Compare actual response times; geographic distance alone doesn't indicate route quality.
- Once you choose a primary node, keep one in another region as a backup.
Region-Specific Services
- Check the target service's regional requirements first.
- Check the exit IP through your current proxy before accessing the service.
- Keep your account environment consistent; avoid logging in from multiple regions in quick succession.
Meeting the region requirement is only the first step. A service may also consider your account region, payment details, and IP type.
When checking your exit IP, make sure both the IP lookup page and the target website use the selected proxy. Split-routing rules might send the lookup site direct while routing the target site through the proxy, making their results incomparable. An exit-IP check also can't tell you whether a video will play; open the content and check for uninterrupted playback.
Check Protocol Compatibility Before Comparing Routes
VMess, VLESS, and Trojan are connection protocols. WebSocket is a transport method, while TLS and REALITY are connection security settings; these aren't interchangeable options at the same layer. VLESS doesn't provide encryption by itself, so deployments need an appropriate security layer. Whether a node connects depends on the complete configuration, not just the protocol name.
VLESS + REALITY
- Protocol
- VLESS
- Security layer
- REALITY
- Example Flow value
xtls-rprx-vision, must match the server- Check these fields
- Server name, public key, Short ID
On desktop, use an Xray core that supports this combination. On Android, v2rayNG is an option. Don't assume the same setup works with v2flyNG.
VMess + WebSocket + TLS
- Protocol
- VMess
- Transport
- WebSocket
- Security layer
- TLS
- Check these fields
- Server name, Host, path, and port
The server determines the path; it isn't necessarily /ws. Using this combination doesn't guarantee that traffic goes through a CDN.
Trojan deployments commonly use TLS, so the connection password, server name, and certificate validation must all be correct. Don't disable certificate validation just to troubleshoot speed. With VMess, also check the system clock: a significant time difference can affect authentication. Don't reuse VMess fields for VLESS or Trojan.
- v2rayN: A desktop client whose capabilities depend on the selected core and its version. Successfully importing a profile doesn't mean every configuration will run.
- v2rayNG: An Android client that uses the Xray core. For newer features, check whether your current version supports them.
- v2flyNG: An Android client that uses the V2Fly core. Being part of the V2Ray ecosystem doesn't mean it supports Xray's REALITY and XTLS Vision settings.
After importing a subscription, keep the provider's settings as given. If the logs report an unsupported field or transport, check the client, core, and subscription format rather than changing the port, path, or encryption settings at random. A protocol name alone doesn't predict speed; differences between routes using the same protocol can be much greater.
Keep Primary, High-Traffic, and Backup Nodes for Different Tasks
After comparing the four factors, there's no need to find one “best node” for everything. A small set of clearly assigned options is easier to manage. When choosing for the first time, test during your usual hours, then test again during a busy evening to see whether route quality has changed significantly.
| Use case | Selection order | How to verify |
|---|---|---|
| Everyday browsing | Compatibility and availability → stable latency → region → multiplier | Open several frequently used pages in a row and check for repeated delays or failures. |
| Video streaming | Suitable region → successful playback → sustained throughput → multiplier | Stream at a fixed resolution for 5 minutes and check for buffering or interruptions. |
| Large downloads | Traffic budget → sustained throughput → connection stability | Briefly test the same source file and keep test traffic under control. |
| Backup connection | Availability → a different route from the primary → regional requirements | Switch to it and access the target service; a node name in the list isn't proof that it works. |
Use consistent speed units too. Apps may show MB/s, while network speeds are commonly expressed in Mbps. As a rough conversion, 1 MB/s is about 8 Mbps, though protocol overhead affects the actual rate. Don't rank one node's MB/s figure directly against another node's Mbps figure.
Keep a short record of each node's label, exit region, multiplier, three real-connection test results, and the outcome of your use-case test. If the network gets worse, try a backup node first to narrow down whether the issue is with one route, the target service, or your local network. That's more useful than re-ranking the whole latency list every day.