For users who have imported a subscription but aren't sure which server to choose. First rule out unusable options with a real connection test, then narrow the list by target site, traffic multiplier, and peak-hour performance. This guide covers a consistent testing process, multiplier examples, and protocol fields to check—so you can keep one primary server and a backup on a different route instead of chasing the lowest latency number.
Understanding latency: a reachable TCP port doesn't mean the proxy works
The “latency” shown in a server list can refer to different kinds of tests. A TCP test usually measures how long it takes to connect to a port on the server; it doesn't confirm that authentication, the TLS handshake, proxy forwarding, and access to the target site all work. A server port may be reachable even when subscription settings are invalid, resulting in “latency detected, but web pages won't load.”
A real connection test accesses a test URL through the selected server, making it more representative of actual use. Results still depend on the test site, DNS, connection reuse, and current network conditions. The test can tell you whether the proxy route works, but not whether every site will be equally fast. Don't compare TCP latency directly with real connection latency, and don't assume a timeout means the server is definitely offline.
- Web browsing and interactive use: Look for consistent results across repeated requests and whether pages regularly stall. Several similar results are more useful than a single record-low latency reading.
- Video and downloads: Focus on sustained throughput and buffering. Bandwidth, network congestion, and limits imposed by the destination often matter more than a fast handshake.
- Calls and real-time apps: Check jitter, packet loss, and the route actually used by the app. A successful browser speed test doesn't prove that the app's UDP traffic is being proxied.
How to test servers in v2rayN: check connectivity, then verify your use case
These steps use the common Chinese-language v2rayN interface. Menu labels may vary slightly by version; look for the functions corresponding to “real connection latency” and “system proxy.” Before testing, make sure the subscription comes from a trusted source. Subscription URLs may contain access credentials, so don't include them in public screenshots.
-
Update the subscription
In the main window, go to “Subscription Group” → “Update all subscriptions (without proxy).” If your current network can't retrieve the subscription and you already have a working proxy, choose “Update all subscriptions (through proxy)” instead. Confirm the group updated successfully before comparing nodes; don't test outdated entries.
-
Choose candidates
Pick three candidates from different locations and routes in the server list. Hold Ctrl to select multiple entries, then right-click and choose “Test real connection latency.” Rule out entries that consistently time out; there's no need to repeatedly test the entire subscription.
-
Enable a server
Right-click a candidate and choose “Set as active server,” then select “System proxy” → “Automatically configure system proxy” in the main window. This affects only apps that follow the system proxy; it does not route every program.
-
Verify your use case
Open the site you actually need in a browser and check sign-in, page loading, and resource downloads. If routing rules send the site directly, check the route first; don't attribute a direct connection's results to the server.
-
Retest and keep a backup
Test each candidate three times under the same conditions, recording the median and number of failures. Test again during your usual evening peak hours, then keep a primary and a backup. Prefer a backup with a different entry point or route, not just a different name on the same route.
In v2rayNG for Android, select the configuration, tap the connect button to start the service, and approve the system VPN permission on first connection. Then use the app's real connection test to verify it. Desktop “System proxy” and Android's VPN service work differently, so don't assume the same switch names apply. In either case, verify the result in the apps you use.
How traffic multipliers work: a lower multiplier doesn't always mean lower usage
Labels such as “0.5x,” “1x,” and “2x” in server names usually refer to the subscription service's billing rules—not a V2Ray protocol field or a speed multiplier. A common formula is “billable traffic = traffic measured by the server × node multiplier.” Check the subscription service's documentation and usage panel to see whether uploads and downloads are both counted, or whether multipliers vary by time of day.
For the examples below, assume the server has recorded 10 GB of traffic. These figures illustrate multiplier calculations only; they are not speed-test results or a representation of any subscription plan. Actual billing may be affected by unit conversions, reporting delays, and connection overhead, so it may not exactly match the size of files downloaded locally.
- Long videos and large files: Make sure a lower-multiplier server can reliably meet your needs before comparing speeds. Avoid spending more of your allowance on peak bandwidth you won't use.
- Short, time-sensitive tasks: A higher-multiplier server can serve as a backup, but “2x” alone doesn't mean it has dedicated bandwidth or less congestion.
- Testing also uses traffic: Real connection latency tests usually request little data, while throughput tests transfer much more. Don't treat bulk download speed tests as a routine refresh.
Choosing a server location: consider the exit and destination, not just distance
The location in a server name usually describes its exit location, but it may just be a label assigned by the provider. The entry point, relay, and exit may be in different places, so geographic proximity doesn't guarantee a shorter network route. A nearby entry point may still take a detour; a farther exit can be more reliable if its network peering is better.
Start with your intended use. For everyday browsing, prioritize route stability and traffic cost. For services with location restrictions, check the exit IP and how the service evaluates it at that time. An IP lookup page shows the exit for that request only; it can't guarantee that other apps or domains use the same route, or that the target service will accept that address.
Everyday primary
RecommendedChoose a server with a stable real connection on your usual network, working access to your target sites, and a reasonable multiplier. Compare the overall experience first, then use latency to distinguish between otherwise similar options.
Good for: web browsing, everyday work, and standard video streaming
Exit in a specific location
Choose an exit that meets the target location requirements, then test sign-in and content access. Keep the location consistent where possible to reduce extra checks caused by frequent region changes.
Good for: sites and accounts with specific location requirements
Backup on a different route
Choose a backup that avoids the same likely failure path as your primary. Different names don't necessarily mean different routes; check the provider's route details and test during peak hours.
Good for: switching when your primary times out, becomes congested, or is temporarily unavailable
Protocol comparison: choosing between VMess, VLESS, and Trojan
Protocol names describe how a connection authenticates, encapsulates, or protects traffic; they don't determine speed on their own. Server resources, route quality, transport, and client-core support matter too. v2rayN is a desktop client, and its protocol support depends on the core and version in use. For Android, v2rayNG uses the Xray core and v2flyNG uses the v2fly core; don't assume they support the same configurations.
| Protocol | Key differences | What to check |
|---|---|---|
| VMess | Includes authentication and encryption; supports different transport layers | Client compatibility, system time, and matching transport and TLS settings |
| VLESS | Lightweight authentication protocol; doesn't encrypt payloads on its own, and is commonly paired with TLS or REALITY | Whether the core supports the combination, and whether Flow, security layer, and server settings match |
| Trojan | Typically uses password authentication within a TLS connection | Check that the password, server name, certificate verification, and transport settings are correct |
Don't assume every VLESS setup uses REALITY or that VMess always uses WebSocket. Protocol, transport, and security layer are separate dimensions. The two cards below are examples of fields to check, not ready-to-use server configurations. Port 443 is shown only as a common example; use the actual value provided by your service.
VLESS + REALITY
- Protocol
- VLESS
- Transport
- TCP; check against the value in your subscription
- Security layer
- REALITY
- Example port
- 443; don't use this in place of the actual port
- Additional fields
- Check the public key, server name, Short ID, and Flow
Whether Flow uses xtls-rprx-vision depends on the server configuration. Support for standard VLESS alone doesn't mean this combination is supported.
VMess + WebSocket + TLS
- Protocol
- VMess
- Transport
- WebSocket
- Security layer
- TLS
- Example port
- 443; use the actual value in your subscription
- Additional fields
- Check the path, Host, and TLS server name
The WebSocket path must match the server configuration; don't change it to /ws at random. This combination doesn't necessarily use a CDN.
Common questions about choosing a server: narrow down the cause by symptoms
Why does the server with the lowest latency still buffer during video playback?
Latency reflects the time taken by a particular request, not sustained bandwidth. Pause background downloads and test two candidates with the same video at the same resolution, comparing buffering and playback stability. Retest during your usual evening peak hours so you don't rely on results from an idle network.
All servers are timing out. Is my subscription expired?
First check your local network and system time, then update the relevant subscription group. If the client log shows that the core failed to start or a port is already in use, fix the local issue first. If only one server fails, check that entry's address, authentication, and server status.
Why does a site still show my old location after I switch regions?
In v2rayN, first check that “System proxy” is set to “Automatically configure system proxy,” then check whether routing rules send the site directly. Close and reconnect your browser, then compare the exit IP. The site may also infer your location from your account region, location permissions, or an existing session.
Will a 0.5x server give me only half the speed?
The multiplier doesn't determine speed. Check the subscription service's billing information to confirm what 0.5x means, then test it against a 1x server under the same conditions. The multiplier affects how much traffic is deducted; bandwidth and congestion need to be tested separately.
What should I do if my old servers disappear after updating the subscription?
Confirm that you updated the original group, then check whether the service provider changed its server list. Don't guess an address or port based on an old server name. Choose working candidates from the new list and compare them by real connection, intended use, and multiplier.
Your final notes can be simple: server name, test network, time of test, median real connection latency, result for the target site, and multiplier. Retest when settings change, you switch broadband networks, or persistent stuttering starts. This gives you primary and backup servers suited to actual use, rather than just a list sorted by latency.