Already imported a subscription but not sure which server to use? First confirm the connection works in v2rayN on desktop or v2rayNG on Android. Then compare latency across multiple tests, peak-hour reliability, traffic multipliers, and exit locations. Protocols help you check compatibility, but don't determine speed on their own. Use the method below to choose a primary server and a backup with a different entry point.
1. Latency, speed, and real-world reliability
The millisecond figure in a server list reflects just one type of test. TCP latency mainly measures how long it takes to connect to the server port. A real-connection test typically includes the proxy handshake and a request to a test address. Results from different clients or test addresses aren't directly comparable. A server showing 40 ms won't necessarily load every website in 40 ms.
| Metric | What it measures | What it doesn't tell you |
|---|---|---|
| TCP latency | How easily a connection can be established to the server address and port | Whether proxy authentication succeeds or the destination website is reachable |
| Real-connection latency | Time to reach a specified test address through the server | Sustained transfer speed or performance across all websites |
| Download speed | Sustained throughput to the speed-test server | Peak-hour load or performance to servers in other regions |
| Real-world usage test | Signing in to a website, streaming video, or transferring files | How it performs on other ISPs or at other times |
For example, Server A tests at 65 ms but times out twice in five attempts. Server B stays between 110 and 130 ms and succeeds every time. For everyday browsing, Server B is usually the better choice. These figures illustrate how to compare servers; they aren't results from a real-world ranking. For video or large file transfers, also test sustained throughput instead of sorting by latency alone.
2. Run a repeatable test with v2rayN
These steps use the common v2rayN 7.x interface on Windows. Menu labels may vary between minor releases, but the process is the same: update the subscription, test servers in batches, set an active server, and check the destination website. Note the installed version under Help → About so you can reproduce the same test conditions later.
-
Update the subscription
In the main window, open Subscription Group and select Update current subscription (without proxy). If your current network can't reach the subscription URL, use the option to update through the proxy. After updating, confirm that servers appear in the group; don't add the same subscription repeatedly.
-
Test latency in batches
Select the servers you're considering, right-click, and choose Test server real connection latency. Wait for each round to finish before repeating it. Don't compare the TCP test column with the real-connection test column as if they measured the same thing.
-
Activate a candidate
Select a candidate server, right-click, and choose Set as active server. Test one candidate connection at a time and make sure the core starts successfully. If a test fails, check the logs for connection timeouts or authentication errors.
-
Test real-world access
To route browser traffic through the system proxy, select Automatically configure system proxy under System Proxy at the bottom of the main window. Open the website you actually use, confirm the routing rules send it through the proxy, then check loading, sign-in, and playback.
-
Keep a primary and a backup
Record each server's original name, group, traffic multiplier, and test time. Retest the next day under the same conditions. If a subscription update changes a server's name, verify it using the updated details rather than relying on its previous position in the list.
With v2rayNG on Android, update the subscription first, select a server, start the connection, and run a connection test. v2rayNG uses the Xray core; v2flyNG uses the V2Fly core. Successfully importing a subscription doesn't mean every server feature is supported. If a protocol isn't compatible, check the client and core capabilities before deciding the server is down.
These figures are a suggested test plan, not client defaults. For five rounds, record the number of successful tests and the median of successful results. For example, with results of 88, 92, 95, and 100 ms plus one timeout, record “4/5 successful, 93.5 ms median”—don't count the timeout as 0 ms. With a small sample, the success rate is only a useful signal; verify performance in real-world use too.
3. Traffic multipliers: weigh speed against your data allowance
A “0.5×,” “1×,” or “2×” in a server name usually indicates the provider's data-usage multiplier, not a speed multiplier. A 2× server isn't guaranteed to be twice as fast as a 1× server. Check the provider's dashboard for the multiplier, which traffic directions are billed, and how the plan defines a GB. Local usage shown in the client may not match the amount deducted by the provider.
| Multiplier | Billable base traffic | Estimated quota deducted | What to consider |
|---|---|---|---|
| 0.5× | 10 GB | 5 GB | Useful for data-heavy tasks, but check speed limits and reliability too |
| 1× | 10 GB | 10 GB | Makes everyday usage costs easier to estimate |
| 2× | 10 GB | 20 GB | Confirm there's a specific location or route feature you actually need |
The table assumes the provider counts exactly 10 GB of base traffic as billable. With 100 GB left on your plan, using a 2× server continuously would use up the allowance after about 50 GB of base traffic. Speed tests also consume data. First rule out obvious problems with latency tests, then run speed tests on a small number of candidates to keep usage in check.
- Browsing and messaging: Prioritize reliability and responsiveness. There's little reason to pay a higher multiplier for peak speeds you rarely need.
- Video and downloads: Check sustained speed, the multiplier, and your remaining data allowance—not just the peak shown by a quick speed test.
- No multiplier listed: Check the provider's documentation or account dashboard. Don't assume an unmarked server uses the default 1× rate.
4. Choosing a location: exit region doesn't equal connection quality
A server's listed region usually identifies its exit location or service region. It doesn't confirm the entry point, physical server location, or route between them. A connection may reach one entry point before being routed to an exit in another region. So a geographically closer server isn't necessarily faster, and two servers in the same region may use entirely different ISP routes.
Choosing a server: assess everyday use and region-specific needs separately
Everyday browsing and work
- Start with nearby regions, then rank servers by results on your local ISP.
- Focus on success rates, page responsiveness, and connection recovery during evening peak hours.
- Choose a backup with a different entry point where possible to reduce the risk of a shared outage.
Region-specific services
- First meet the service's location requirements, then compare latency and traffic multipliers.
- After connecting, check the exit IP's location and confirm the service works as expected.
- Keep the exit location consistent where possible; frequent changes can trigger account security checks.
Location may determine whether you can access a service, but test connection quality on your own device and network at the times you use it.
Terms like “dedicated route,” “transit,” and “native IP” are provider claims, not substitutes for testing. IP geolocation databases may disagree, and platforms may also consider your account region, payment details, and IP reputation. A server in a particular region may open a website without meeting all of that site's requirements.
5. VMess, VLESS, and REALITY: check the settings and core first
VMess and VLESS are proxy protocols; REALITY is a security transport, not a speed tier on the same level. Common combinations include VMess + WebSocket + TLS and VLESS + REALITY. Protocol names alone can't predict bandwidth. Network congestion, server load, and the route to the destination website usually matter more directly.
VLESS + REALITY example
- Proxy protocol
- VLESS
- Transport
- TCP, labeled RAW in some interfaces
- Security layer
- REALITY
- Flow
- xtls-rprx-vision when Vision is enabled on the server
- Key parameters
- The public key, shortId, and serverName must match the server configuration
Works with an Xray core that supports these features. Keep the subscription parameters as provided; don't invent a Flow value.
VMess + WS + TLS example
- Proxy protocol
- VMess
- Transport
- WebSocket
- Security layer
- TLS
- Key parameters
- UUID, WebSocket path, Host, serverName
- Example port
- 443; use the port specified by the server configuration
WebSocket doesn't necessarily mean the connection uses a CDN. Host and serverName aren't interchangeable.
These cards show common combinations, not complete configurations you can paste in as-is. Port 443 doesn't guarantee a particular protocol or faster performance. If a subscription fails after import, first check that the core supports the combination, your system clock is correct, and all transport and security parameters are present.
6. Choosing a primary and backup—and avoiding common pitfalls
You don't need a complicated scoring system. First rule out servers that can't establish a real connection. Then check destination and location requirements, compare reliability during your usual hours, and choose a suitably fast server with an acceptable multiplier. A primary and backup should minimize shared points of failure, not just have different names.
- Primary server: Passes repeated tests during your usual hours, works with the services you need, and has a multiplier that fits your data budget.
- Backup server: Also verified with real-world access; choose a different entry point or route group if possible.
- When to switch: Switch after repeated failed requests, persistent video buffering, or an unavailable service. Don't keep changing servers over a single latency fluctuation.
- Keep test records: Note the date, network, server name, results from five rounds, multiplier, and real-world checks. Retest after route changes.
Why won't a website load even though latency is low?
First check whether the reading is TCP latency or real-connection latency. Then check the active server, system proxy, and routing rules to make sure the browser request is actually going through that server. If only certain domains fail, check DNS, restrictions on the destination service, and the exit IP's status. A single millisecond figure doesn't prove the whole connection is working.
Why does video keep buffering even when a speed test is fast?
The speed-test server and video server may be on different networks, and the route to each may differ. Test sustained playback and seeking on the actual video service, then repeat during evening peak hours. If download speed is shown in MB/s, multiply by 8 to convert to Mb/s—for example, 5 MB/s is about 40 Mb/s. Don't compare the two units directly.
All servers in the subscription time out. Should I change each protocol one by one?
First check for shared causes: an expired subscription, an exhausted plan, a disconnected local network, a core that failed to start, or an incorrect system clock. If every server fails at once, these common factors are more likely. Don't change protocols, ports, or security settings in bulk; settings that don't match the server will only make troubleshooting harder.