How to Choose a V2Ray Server: Latency, Data Multipliers, Location, and Protocols

Understand the server list: latency isn’t download speed

A V2Ray server, often called a node, is a set of connection parameters for a client, including an address, port, protocol, authentication details, and transport settings. A subscription distributes these settings in bulk, while clients such as v2rayN manage the entries and use a core to connect. Providers assign node names, so labels like “high speed,” “dedicated line,” or a location abbreviation aren’t test results.

Before choosing a node, understand what each test measures. System Ping mainly measures ICMP round-trip time. TCP latency measures how long it takes to establish a connection to a port. A real-connection test typically accesses a specified test address through the proxy. These tests use different paths and workloads, so their results shouldn’t be ranked together.

For example, a 60 ms TCP connection doesn’t guarantee fast, uninterrupted video. A 130 ms real-connection result doesn’t necessarily mean the node is poor either, since it includes proxy processing and connecting to the destination. A speed test showing 5 MB/s is about 40 Mbps in decimal units; convert units before comparing it with a video bitrate.

Testing nodes in v2rayN: compare them under the same conditions

Choose a small set of candidate nodes and test them on the same device, network, and test address. The menu steps below refer to common Windows desktop versions; names and locations can vary. If you can’t find an exact match, check your version’s menus and settings documentation. Don’t change subscription authentication fields just to match a guide.

1. Check the test conditions

   Open “Settings” → “Parameter settings” and note the local listening port and test settings. If your local HTTP proxy port is 10809, configure your browser to use that port as well. This is an example for verification, not a default for every version.

2. Narrow down the candidates

   Select 3 to 5 nodes in the server list, right-click, and choose “Test real-connection latency.” Use the same test address for each and note any failures. Don’t use a node as your primary if its TCP test succeeds but its real-connection test fails.

3. Test real-world access

   Right-click a candidate and choose “Set as active server,” then check the “Auto configure system proxy” status under “System proxy.” Open a site you actually use and check the client logs to confirm requests are going through the expected proxy route.

4. Retest and keep a backup

   Repeat the tests for your candidates and check them again at your usual usage times. Keep one primary node and one backup with a different exit or route. Two entries with different display names may still use the same server.

The test plan below is a practical guide, not a benchmark from this site or a protocol performance threshold. Three successful rounds only show that a node worked in the short term; verify it with your actual workload. If a test times out, try again rather than keeping only the best-looking result.

How traffic multipliers work: check the billing rules

Traffic multipliers are a billing rule set by the provider, not a technical property of protocols like VMess or VLESS. A common setup deducts actual traffic multiplied by the listed factor: if a route has a 2× multiplier, transferring 10 GB may use 20 GB of your allowance under that billing model. A higher multiplier doesn’t mean faster speeds, and a zero multiplier doesn’t mean a better route.

• Check the rules first: Find out whether uploads and downloads both count, whether multipliers change by time of day, and how the account panel defines a GB.
• Estimate monthly usage: If you expect to use 60 GB of video traffic, a 1.5× route would use about 90 GB of allowance under a multiplier-based billing model.
• Leave room for other activity: Include system updates, file sync, and speed tests in your estimate—not just video watched in a browser.
• Check where usage is calculated: Client stats usually show traffic transferred by your device. The provider’s panel may apply multipliers, count both directions, or update with a delay, so the figures may not match.

At an average video bitrate of 8 Mbps, one hour of continuous playback transfers about 3.6 GB using decimal units—or about 7.2 GB on a 2× plan. Actual usage depends on adaptive bitrate, audio tracks, and buffering. If your allowance is limited, choose a lower-multiplier node that can sustain the stream rather than paying more for a one-off speed-test peak.

Choosing a server location: distinguish the entry point, exit, and destination

A location label may refer to the entry server or the final exit server; they can differ on a relayed route. Your client connects to the entry point, while the destination website usually sees the exit IP. For location-specific services, check the exit location and how the service actually identifies it. For low latency, consider the full route—not just the distance on a map.

A nearby server with a circuitous route can be slower than a distant one with a more direct path. The same exit location doesn’t guarantee the same IP type, routing, or load. Access can also depend on account region, IP databases, content licensing, and risk controls; switching locations won’t necessarily resolve every restriction.

Choosing a protocol: check compatibility before comparing routes

VMess and VLESS are proxy protocols; WebSocket is a transport; TLS and REALITY are security settings for a connection; and XTLS Vision is a specific flow-control scheme. These terms refer to different layers, so they can’t be ranked as if they were equivalent options. VLESS doesn’t provide encryption by itself, so a deployment needs suitable transport security.

The cards below show example subscription parameter combinations to help identify settings; they aren’t ready-to-use server configurations. The address, port, user ID, and security parameters must match the server. Don’t change VMess to VLESS just to use a particular protocol name, or add Vision to a server that doesn’t support it.

The desktop version of v2rayN can manage configurations for different cores; available features depend on the installed version and selected core. The Android clients v2rayNG and v2flyNG are based on Xray and V2Fly, respectively. For settings such as REALITY, first check that the core supports them. A failure caused by an unsupported protocol isn’t the same as a congested route. For more background, see the protocols section of the reference guide.

Choose primary and backup nodes for your use case

Before comparing nodes, decide what you can’t tolerate. For browsing, it’s frequent waits and occasional timeouts; for video, insufficient sustained throughput; for remote work, dropped connections and changing exit locations. Matching your tests to your workload is usually more useful than chasing the lowest latency in the entire list.

For video, leave headroom above the average bitrate to handle peaks and network fluctuations, but there’s no fixed multiplier that works for every platform. Work meetings may use UDP. Being able to open websites in a browser doesn’t mean the meeting connection will work—test audio, video, and screen sharing in the app you use.

• Primary node: Test it during your most common usage hours and record the location, multiplier, real-connection results, and actual experience.
• Backup node: Choose a different route or exit if possible, so it gives you a useful alternative when the primary route fails.
• When to switch: Make sure it’s safe to disconnect from your current task first. Long-lived connections usually can’t move to a new node without interruption.
• Retest periodically: Subscription updates can change server addresses and settings, so retest even if the node name stays the same.

If every node is slow, check for local issues first

If all candidate nodes are having problems, the subscription may not be the cause. System proxy settings affect only apps that follow them; manual proxy settings, TUN, and client routing can each take a different path. Browser extensions, an outdated proxy port, and local DNS can also change the results. Change just one setting at a time while troubleshooting so you can tell what made a difference.

1. Pause background downloads and test a normal task on the same network without the proxy to check for local congestion.
2. Check the active server, system proxy address, and listening port. For example, if the client listens on 127.0.0.1:10809, the app shouldn’t still be pointed at an old port.
3. Check the logs for connection failures and resolution errors, and confirm that test requests use the proxy rather than a direct-connection rule. See the routing and split-tunneling guide for more details.
4. If only one site fails, test another destination and check the site’s access requirements before rebuilding your entire configuration.