Choose a server by first confirming it can access the services you need, then comparing peak-hour stability, real-connection latency, and traffic costs. This guide is for users who have imported a subscription and need to pick a primary server from several options. Use TCPing to rule out basic connectivity issues, test real connections against the same target, then compare exit locations, traffic multipliers, and protocol settings. Keep one primary server and one backup.
1. TCPing vs. real-connection latency: what each test measures
The millisecond figure in a server list may not represent the same kind of test across clients. TCPing typically measures how long it takes to establish a TCP connection from your device to a server address and port. It does not confirm successful proxy authentication or that the server can reach a website. A reachable port and an inaccessible webpage are not contradictory.
Real-connection latency is usually measured by sending a request through the server to a specified test address. It can include the proxy handshake, the connection to the target site, and its response. The exact timing depends on the client and core implementation, so compare results only in the same client, against the same test address, and within a similar time window. This is closer to web browsing, but it is not a download-speed test and does not predict performance on every site.
| Test type | What it can tell you | What it cannot tell you |
|---|---|---|
| TCPing | Whether the TCP port at the server endpoint is reachable and how quickly the connection is established | Whether your account is valid, the proxy exit works, or the target website is accessible |
| Real-connection latency | Whether a specified target can be reached through the proxy, and roughly how long it takes to respond | Sustained download bandwidth, compatibility with every service, or long-term connection stability |
| Download speed test | Throughput to a specified target during the test window | Video-call jitter, eligibility for region-specific services, or performance during peak hours |
2. Test servers in v2rayN under consistent conditions
In the v2rayN main window, select a candidate server and use the context-menu option labeled “Real connection latency” or, in some versions, “Test server real connection latency.” For a basic port check, choose the option containing “Tcping.” Labels may vary slightly across desktop releases. Compare like with like—don't rank results from the two test types together.
- Keep the shortlist small. Start with 3–5 servers that meet your location and traffic-multiplier requirements. Pause system updates, cloud sync, and other downloads, and stay on the same network connection.
- Use the same test target. Look under Settings → Parameter settings for speed-test options. If your version offers a “Real connection test address,” use the same address for every candidate and don't change it halfway through.
- Run 3 rounds. Record each result and the number of timeouts. For example, if the results are 82, 88, and 230 ms, don't record only the best result (82 ms); note the spread as well.
- Set the active server. Right-click your preferred candidate and select “Set as active server.” Confirm that the system proxy or your current traffic-routing mode is enabled, then visit the website you actually plan to use.
- Check the logs. Look for connection failures, authentication errors, and TLS handshake errors in the log panel. When testing in a browser, make sure the relevant requests are actually routed through the proxy rather than bypassing it under a direct-connection rule.
The results 82, 88, and 230 ms above are examples of how to record test results, not measurements for any particular location. Compare the median, timeout count, and worst result. A server that is occasionally fast but frequently fails is usually a poor choice for everyday use.
These figures are practical screening suggestions, not performance benchmarks. On Android, v2rayNG offers options such as “Test all configurations' real connection” from the menu in the top-right corner of the main screen. After testing, select a candidate, connect, and verify that your apps work. Record results separately for each network: rankings on home broadband may not apply to mobile data.
3. Traffic multipliers: lower usage isn't the same as lower latency
Providers typically use traffic multipliers to calculate data usage. Labels like “0.5x,” “1x,” and “2x” in a client’s server list are informational; actual usage depends on the provider's rules and usage dashboard. A higher multiplier does not automatically mean lower latency. It may reflect line costs, bandwidth resources, or the provider's pricing model.
| Traffic multiplier | Base traffic used | Traffic charged at the multiplier |
|---|---|---|
| 0.5× | 1 GiB | 0.5 GiB |
| 1× | 1 GiB | 1 GiB |
| 2× | 1 GiB | 2 GiB |
The table uses the simplified formula “base traffic × multiplier.” Some providers count both upload and download traffic; protocol overhead, unit conversions, and reporting delays can also affect dashboard figures. So downloading a file labeled 1 GiB won't necessarily add exactly 1 GiB to your base usage.
- Video and large downloads: Prioritize stable throughput, then check the multiplier. If performance meets your needs, there's no reason to pay for a higher usage charge just to chase peak speed-test results.
- Web browsing and light office work: These usually use little data. Consistent response times and fewer timeouts matter more than finding the absolute lowest multiplier.
- Speed-test data usage: Speed tests transfer real data. Don't repeatedly run full-bandwidth tests on dozens of servers. Narrow the list with latency tests first.
4. Choosing a server location: entry point, exit point, and service restrictions
A location in a server's name doesn't mean the entire route is in that location. The entry point is where your device connects to the network; the exit point is where the public IP address seen by the destination website is located. Traffic may also be relayed in between. A shorter geographic distance can reduce propagation delay, but ISP peering, detours, and congestion can change the final ranking.
If a service requires a specific region, verify access on the service itself. IP geolocation databases may be out of date, and services such as streaming platforms may also consider your account region, payment details, and whether they detect proxy use. A server name or a single IP lookup can't guarantee access.
Nearby exit, verified during peak hours
RecommendedStart with candidates that appear to have shorter network paths. Check real-connection latency and test the sites you use. Keep a server with few peak-hour timeouts and consistent responsiveness as your primary.
Best for: everyday browsing, interactive work, and services without a specific region requirement
Exit in the region required by the service
Meet the service's regional requirements first, then compare response times and throughput. Test sign-in, playback, and continued use—not just whether the homepage loads.
Best for: content and account services with specific regional requirements
Backup exit on a different network path
Ideally, your backup should use a different entry point or upstream provider from your primary. Servers with different names may still share the same route, so check the provider's documentation.
Best for: switching during peak-hour congestion or staying connected during maintenance on your primary route
5. VLESS, VMess, and Trojan: check the full configuration for compatibility
A protocol name describes only part of a configuration. The transport, TLS or REALITY settings, security parameters, server deployment, and route quality all affect performance. “VLESS is always faster than VMess” is not a reliable way to choose a server; even servers using the same protocol can perform very differently on different routes.
| Protocol | Settings to check | What to consider |
|---|---|---|
| VLESS | UUID, transport, and security type. For REALITY, also check parameters such as the public key, shortId, and serverName. | VLESS does not provide transport encryption by itself, so check the complete security configuration. The flow setting must match the server. |
| VMess | UUID, encryption settings, and transport. If TLS is enabled, check the server name. | Check your device clock and the server parameters. Don't mistake an authentication failure for network congestion. |
| Trojan | Password, server address, port, TLS server name, and transport settings | Common deployments rely on TLS. If certificate validation fails, check the server name, certificate, and system clock. |
A server using port 443 is not automatically faster, and the port alone doesn't indicate whether a server is secure. Don't enable “Allow insecure” just to silence an error. First verify the server name in your subscription, your system clock, and the server's certificate configuration.
Configuration guide: choose a client core for your existing server
VLESS + REALITY server
- On desktop, confirm that v2rayN is using an Xray core that supports this configuration.
- On Android, you can use v2rayNG with an Xray core; keep the client up to date.
- Keep all subscription parameters intact. Don't manually replace REALITY with TLS as the security type.
Existing VMess or Trojan server
- Keep the protocol, transport, and security settings provided by the server, then test the route.
- v2flyNG uses the V2Fly core. Check support for specific settings against the relevant version.
- If import reports an unsupported field, check core compatibility first rather than changing the protocol blindly.
Prioritize a complete configuration and a compatible core before comparing routes. Don't change client settings just to switch protocols.
6. Low latency but poor performance? Troubleshoot by symptom
The final step in choosing a server is testing it in real use—not just sorting the speed-test results. Use the same browser to visit familiar sites and try a file download or video playback. If you need video calls, check whether long-lived connections drop. Real-time services also depend on UDP support, app behavior, and routing rules; a basic HTTPS test can't cover all of that.
TCPing is only 30 ms, but why does the real-connection test keep timing out?
A 30 ms result only means the connection to the entry port is fast. Test the same target through another working server, then check the logs for authentication, TLS, and DNS errors. Verify the UUID or password, security type, transport settings, and system clock.
Why is the server with the lowest latency so slow to download?
A quick response to a short request doesn't mean there's enough sustained bandwidth. Test the same download target on only the two or three shortlisted routes. Disable parallel downloads, record the sustained rate rather than the peak, and repeat the test during evening peak hours.
It works during the day but keeps buffering at night. Should I switch protocols?
Keep the existing configuration and try backup servers on different routes using the same target and network connection. If performance drops only during peak hours, look for bandwidth limits or route congestion. Changing the protocol name won't fix congestion on a shared upstream.
It works on Android, but the same website won't open on my computer. Is the server broken?
First check that both devices are on the same network and using the same server. On the computer, confirm the active server and system proxy settings, then check for direct-connection rules or a separate browser proxy. Also verify that both clients' cores support the configuration.
Final checklist
- One primary: Works with the services you need, stays reliable during both regular and peak hours, and has an acceptable traffic multiplier.
- One backup: Uses a different route if possible, and has been connected and tested—not chosen solely by the latency shown in the list.
- Keep a record: Note the server alias, test date, network connection, all three results, and your experience. Hide subscription URLs and access credentials before taking screenshots.
- Retest when conditions change: Compare again after switching broadband, mobile networks, or subscription routes. Don't treat an old ranking as a permanent result.
A reliable server-selection process follows a consistent order: service access → peak-hour stability → response time and throughput → traffic cost → backup route. Protocol and location help narrow the choices, but the actual connection is what counts.