For users who have imported a subscription but aren’t sure which server to choose. Test candidates against the same target, rule out connection failures, then compare latency consistency, throughput, and traffic multipliers. Finally, check the exit location and protocol settings. By the end, you should have a reliable everyday server and a tested backup—not just the entry with the lowest number of milliseconds.
1. Understand latency, speed, and availability
A subscription entry typically includes a server address, port, authentication details, and transport settings. “Server” is commonly used to refer to this connection profile. Locations, traffic multipliers, and route descriptions in server names are supplied by the provider; they are not results detected by the client. Entries with different names may share an ingress or exit, so names alone cannot tell you whether routes are independent.
TCP connection latency only measures how long it takes to connect to the server’s specified port. Real connection latency usually also establishes a proxy protocol connection and sends a request to a test URL, making it closer to the path used for browsing. Even so, it reflects just one request to one target. A timeout at one test URL does not mean every site is unreachable, and a latency result does not guarantee smooth video playback.
| Metric | What it tells you | What it does not tell you |
|---|---|---|
| TCP connection latency | Time to connect from your device to the server port | Whether authentication succeeds or the destination site is reachable |
| Real connection latency | Time for a request to a test target through the proxy | Sustained download speed or performance across all sites |
| Download throughput | Transfer rate to a specific target during the test | Peak-hour performance or call upload quality |
| Failures and variability | Whether repeated requests complete reliably | Whether performance will always be stable in the future |
When sorting candidates, rule out those that time out frequently, compare consistency next, and then look at speed. For example, one server might occasionally show 60 ms but fail two out of five tests, while another stays between 110 and 130 ms. The more consistent server is usually a better one to try for everyday use. This is an example, not a measurement of our servers; there is no universal latency threshold that works for every location.
2. Test under the same conditions in v2rayN and v2rayNG
Keep the network, test URL, and approximate time of day consistent. Don’t compare results from home broadband with those from a mobile network. The menu names below describe common Chinese-language interfaces; wording may vary by version, such as “Test” versus “Test server.” If you can’t find the exact label, use the equivalent function. There’s no need to change authentication details in your subscription just to run a test.
-
Update the subscription
In desktop v2rayN, go to “Subscription Group” → “Update all subscriptions (without proxy)” to refresh the list. If a direct update fails and you have a working connection, try “Update all subscriptions (through proxy).” Confirm the update succeeded before testing so you don’t compare outdated profiles.
-
Test real connection latency
Select a candidate in the v2rayN main list, then right-click and choose “Test server real connection latency.” Start with a few candidates rather than testing a large subscription all at once. Record each result and its time; use the same test target for repeat tests.
-
Check on Android
In v2rayNG, tap “⋮” in the top-right corner of the main screen, then choose “Test real connection for all configurations.” After switching to a candidate and connecting, you can also tap the connection status area at the bottom to test the active connection. Batch tests and active-connection tests serve different purposes, so record them separately.
-
Test the destination
After setting a server as active, in v2rayN use the tray menu: “System Proxy” → “Automatically configure system proxy.” Then visit a real site in a browser that follows the system proxy. On Android, connect and confirm the system VPN prompt; also check whether per-app proxy rules exclude the app you’re testing.
-
Retest at different times
Run another round during your usual usage hours and at peak time in the evening. Record successful requests, latency range, page stalls, and sustained downloads. Don’t keep only the single best-looking result.
The figures below are suggested for initial screening, not client defaults or a performance guarantee. Repeated requests offer clues about consistency, but five samples aren’t enough to estimate long-term failure rates. Speed tests use traffic, so run them only after checking availability.
3. Traffic multipliers affect data usage, not speed
“0.5×,” “1×,” and “2×” usually refer to the provider’s billing multiplier, not a speed tier. If the provider charges actual data usage multiplied by this factor, using 10 GB on a 0.5× server deducts 5 GB from your allowance, while a 2× server deducts 20 GB. Check the provider’s terms to see whether uploads and downloads are combined, when the multiplier applies, and whether speed limits also apply.
| Example multiplier | Data transferred | Allowance deducted |
|---|---|---|
| 0.5× | 10 GB | 5 GB |
| 1× | 10 GB | 10 GB |
| 2× | 10 GB | 20 GB |
For video and large downloads, consider a low-multiplier server if it can sustain the throughput you need. For calls, interactive tasks, and remote desktops, address lag, disconnects, and upload performance first; consider the multiplier afterward. A higher multiplier may reflect different route costs, but it does not guarantee better service. Test every option under the same conditions.
4. Check the actual exit location and route
A location label usually describes the exit point, but the ingress, relay, and exit may be in different places. A geographically closer server isn’t necessarily faster: ISP peering, cross-border routing, and congestion all affect performance. Choose based on how your local network performs with the actual destination, not on a country or city name as a rating of route quality.
- Everyday browsing: Try nearby locations first, then compare how quickly the target site’s first screen loads and how responsive several pages feel—not just the test URL.
- Location-specific content: Check the actual exit IP location and how the target service identifies it. IP lookup results are only a guide and don’t guarantee that the service will accept the exit.
- Remote work: Prioritize routes that comply with your organization’s access policies and connect reliably to work servers. The work server’s location may matter more than yours.
- Backup route: Prefer a different ingress or route group. A different location label may still share the same failing ingress, making it an unreliable backup.
Routing rules can directly affect test results. If a direct-connection rule applies when your browser visits a site, the speed you see does not reflect the active server. In v2rayN, check “Settings” → “Routing settings” and review the rule order; use the logs to confirm whether traffic went through the proxy outbound. Don’t route all traffic through the proxy indefinitely just to test one site. Restore your original routing rules afterward.
5. Check VLESS, VMess, and Trojan compatibility first
Protocol names alone don’t determine which server is fastest. VLESS authentication and transport security are separate layers. REALITY is an optional security mechanism that can be used with VLESS, not a requirement. VMess is common in existing subscriptions, while Trojan typically relies on TLS. Actual performance depends on the route, server load, transport, and whether the client settings match.
v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Don’t assume they support exactly the same combinations just because both can import a particular share link. For desktop v2rayN, check the core actually in use and review the logs. For configurations that use REALITY or a specific flow, confirm that the current core supports them; changing the protocol name alone won’t “convert” a configuration.
VLESS + REALITY example
- Transport
- TCP, as specified in the subscription
- Security layer
- REALITY
- Flow
xtls-rprx-vision, only if required by the server- Server port
- 443 is a common example, not a fixed value
The public key, shortId, serverName, and other fields must match the server. This card is a field reference, not a ready-to-connect configuration.
VMess + WS + TLS example
- Transport
- WebSocket
- Security layer
- TLS
- Path
/wsis an example; use the value in your subscription- Server port
- 443 is a common example, not a fixed value
Host, TLS serverName, and path each serve a different purpose and cannot substitute for one another. Whether the connection passes through a relay depends on the deployment; the WS label alone doesn’t tell you.
Trojan also requires the correct password, server address, port, and TLS serverName. If you see a certificate or handshake error, check the subscription and device clock. Don’t treat disabling certificate verification as a standard fix. Keeping the provider’s settings after importing a configuration makes test results more reproducible than randomly changing the port or transport.
6. Pick a primary and backup for browsing, video, and work
One server doesn’t have to handle every task. Choose a primary for your most common use, then keep another tested, working candidate as a backup. The recommendations below are a suggested order for initial screening, not an endorsement of any provider or route.
Primary for browsing: prioritize consistency
RecommendedReal connection tests succeed consistently, frequently used sites load reliably, and the multiplier is acceptable. If two routes have similar speeds, keep the one that performs more consistently across repeated tests rather than the one with a one-off lowest latency.
Best for: web browsing, research, and everyday light use
Video candidate: prioritize sustained throughput
Play content on the target platform and check for buffering and consistent playback, then weigh the cost using the traffic multiplier. A high initial speed followed by repeated buffering isn’t suitable for long viewing sessions.
Best for: long videos, courses, and large downloads
Work backup: prioritize stable sessions
Use an actual meeting or remote connection to check uploads, reconnections, and session stability. Some meeting apps rely on UDP; loading a webpage doesn’t prove that related traffic works. Check the app, how the client handles its traffic, and server support.
Best for: online meetings, remote desktops, and work system access
Don’t switch servers casually during a remote meeting. A change of exit may trigger a new login, interrupt the session, or violate access policies. Test a backup connection before relying on it, and follow your organization’s rules for proxy use and network access.
7. Common mistakes and what to do
Why does video still buffer when latency is lowest?
Play the actual content on the same server and check for ongoing buffering, then retest with another candidate. A real connection test measures a short request, not bandwidth or the route to the streaming platform. Also check whether you’ve used up your allowance or hit a speed limit.
Everything times out. Do I need to buy another subscription?
First, confirm that your local network works in a browser. Then update the subscription, check the device clock, and review the client logs. If multiple servers time out only for the same test target, check whether that target is reachable. Don’t assume every profile is invalid before you know the cause.
Why does the same server work on my computer but fail on Android?
Compare when the subscription was last updated on each device, protocol settings, and core support. On Android, check that the system VPN is connected, the target app isn’t excluded, and no other VPN is using the connection. Also confirm both devices are on the same network before comparing results.
Why is more data deducted when the server is labeled low-multiplier?
Check the provider’s dashboard for multiplier rules, how usage is measured, and when the figures were last updated. Then confirm the active server and routing. Client-reported traffic and the provider’s billable allowance aren’t the same metric, so a single reading in the app isn’t a bill.
You can narrow the final choice down to four notes: the network and time of each test, whether requests completed consistently, how the actual destination performed, and whether the multiplier suits your needs. Repeat the tests after a subscription update or a change in network conditions. Knowing why a server was chosen is more useful than memorizing a location or protocol that’s supposedly “always fastest.”