Choose a server by checking, in order, whether it can establish a proxy connection, reach your target service, stay reliable during your usual hours, and offer reasonable traffic costs. This guide is for users who have imported a subscription but aren’t sure which server to pick. Use the same test conditions to find a primary and a backup instead of sorting by the lowest latency alone.
TCPing, real proxy latency, and download speed are different tests
In short: use TCPing to screen server endpoints, a real connection test to check the proxy route, and a download test to measure throughput. Each answers a different question. A TCP connection to a server address doesn’t prove that your account works, the protocol settings match, or your target website is reachable through that server.
| Test | What it measures | What it can’t tell you |
|---|---|---|
| TCPing | Time for a TCP connection from your device to the server’s listening port | Whether proxy authentication succeeds, the exit works, or pages load quickly |
| Real proxy latency | Time to request a specified test URL through the server | Whether every website is reachable or sustained download bandwidth is sufficient |
| Download speed test | Throughput while retrieving test data through the proxy | Whether the same speed holds in the evening or across other destinations |
| Real-world use test | Whether a target page opens, a video plays, or an application session connects | Whether services in other regions are available or the connection is stable at all times |
Real proxy latency depends on the test URL, DNS, the TLS handshake, connection reuse, and the client implementation. To compare results, use the same test URL and network. Don’t compare a result from a phone on mobile data directly with one from a computer on a wired connection. TCPing is not ICMP Ping, and a system that blocks ICMP replies can still allow TCPing.
Test servers under consistent conditions in v2rayN
Start with a small shortlist, then test each candidate repeatedly. Don’t run download tests on an entire subscription: concurrent tests compete for local bandwidth and can consume substantial subscription traffic. The steps below use common Chinese menu labels in v2rayN. Labels and locations may differ between versions, so follow the menus shown in your interface.
-
Set consistent test conditions
Open “Settings” → “Parameter settings” and check the available options, such as the test URL and timeout. If there’s a “Speed test” section, note its settings there. Stop active downloads, then keep the URL and timeout unchanged for all subsequent tests.
-
Screen server endpoints
Select candidate rows in the main server list, right-click, and choose “Test server latency (Tcping).” Set aside entries that consistently time out, but keep endpoints that are reachable until you’ve confirmed their real connection results.
-
Test the proxy route
Right-click the same set of rows and choose “Test server real connection latency.” Record successes and failures. Test each candidate three times to check for consistent results; don’t rank servers by a single unusually low reading.
-
Check the actual exit
Select a server and press Enter to make it active. From the system tray, choose “System Proxy” → “Set system proxy automatically” so apps that follow the system proxy can connect. Check the routing mode and confirm that requests to your target are actually sent through the selected proxy.
-
Test the services you use
Open a service you use regularly, then run “Test server download speed” from the context menu for a few shortlisted servers. Test again during your usual evening hours. Keep one primary server and one backup on a different route.
The system proxy doesn’t route traffic for every application. Some apps ignore it; client routing rules may also send destinations directly. If your exit doesn’t change after switching servers, check the app’s proxy settings and routing logs first. Don’t rate a server by page load speed until you’ve confirmed the traffic path.
On Android, use the connection test provided in the server list of v2rayNG or v2flyNG; desktop menu steps don’t apply to Android. When comparing devices, make sure they use the same network and that no other VPN connection is changing the route.
How traffic multipliers work: check the billing rules, then calculate usage
A traffic multiplier is usually a billing rule set by the subscription provider, not a VLESS, VMess, or Trojan protocol field. The “multiplier” shown in a client may come from a server remark and could be outdated. For actual charges, check the provider’s current terms and your account dashboard.
These are calculation examples, not real subscription plan figures. Suppose the provider adds upload and download traffic, then applies the server multiplier: 0.2 GiB uploaded plus 0.8 GiB downloaded on a 2× server would count as 2 GiB. If the plan uses decimal GB or bills uploads and downloads differently, recalculate using its units and rules.
- Check what’s counted: Are both uploads and downloads billed? Are there separate rules for specific routes?
- Then check when the multiplier applies: Does it vary by time of day, and does the server remark match your account details?
- Finally, account for testing: Download tests transfer data too. Several rounds of speed tests can use more traffic than loading a few web pages.
A lower multiplier doesn’t mean more bandwidth, and a higher multiplier doesn’t guarantee a stable connection. The multiplier only describes billing. For interactive browsing, focus on connection success and response time; for large downloads, consider both throughput and your remaining quota. The file size shown by a browser may also differ from the provider’s traffic total because of retries, background requests, and protocol overhead.
How to choose a server region: distinguish the entry, exit, and target service
A region label is a starting point, not a complete description of the network route. A server labeled with one region may have an entry point elsewhere and use an intermediary route to reach its exit. Nearby locations can mean lower latency, but peering, cross-border links, congestion, and detours can all affect the result.
| Use case | What to check first | How to choose |
|---|---|---|
| Browsing and remote interaction | Repeated real connection results and initial page load | Among servers that work for your needs, favor the route with less variation |
| Services restricted to a specific region | Exit IP location, account region, and access rules | Confirm the service works first, then compare latency |
| Video and large downloads | Sustained throughput, buffering, and multiplier | Test during your usual hours, not just at a brief peak |
| Backup connection | Whether the entry point and upstream route are independent | Avoid backups that are merely different labels for the same route |
The region in a server remark isn’t necessarily the region a website detects. Sites may consider exit IP databases, account region, payment details, and session history. Even if an IP lookup page shows the expected region, that doesn’t replace checking access on the target service itself.
VLESS, VMess, and Trojan: choose based on server settings and core support
A protocol name alone doesn’t determine speed. The actual route also depends on the transport, TLS or REALITY, the server’s network, exit bandwidth, and server load. If you already have a subscription, first make sure the client fully supports the node’s settings. Changing a protocol name by hand won’t convert an existing server to another protocol.
VLESS + REALITY example
- Protocol
- VLESS
- Transport
- TCP
- Security layer
- REALITY
- Flow
xtls-rprx-vision, only if required by the server- Key parameters
- UUID, service name, public key, short ID
This is an example of a parameter combination. REALITY requires an Xray core that supports it and matching settings; don’t apply it to a standard TLS server.
VMess + WS + TLS example
- Protocol
- VMess
- Transport
- WebSocket
- Security layer
- TLS
- Path
/ws, example path only- Key parameters
- UUID, Host, path, TLS server name
The path and Host must match the server settings. Using WebSocket doesn’t necessarily mean traffic goes through a CDN, nor does it automatically improve stability.
- VLESS: Suitable when you have matching VLESS settings. VLESS doesn’t encrypt payloads on its own and is typically used with a security layer such as TLS or REALITY. Don’t assume that “lightweight” means lower network latency.
- VMess: Suitable when the server provides VMess and the client can import all its settings. Authentication depends on system time. If authentication fails, enable automatic time synchronization first, then check the UUID and transport settings.
- Trojan: Common configurations use password authentication with TLS. Check the password, TLS server name, and certificate validation. TCP 443 is a common server port, but it isn’t mandatory.
What v2rayN supports depends on the selected core and version. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. These core families don’t have identical features. In particular, don’t assume a REALITY server will work if you import it as a standard VLESS server. If you see unknown fields, startup failures, or an unsupported transport warning, check core compatibility instead of repeatedly running speed tests.
Once a server connects successfully, compare its performance with the same real-world task. If two servers use different protocols, such as VLESS and Trojan, but also have different entry points, exits, and upstream routes, the results only compare those complete routes. They don’t show that one protocol is generally faster.
FAQ: low latency, timeouts, and unchanged exits
Why does video keep buffering when latency is low?
First, confirm that video requests actually go through the proxy, then run a download test on the server at the same time. A quick response to a short request doesn’t guarantee enough sustained bandwidth. If it works during the day but buffers in the evening, record results for both time periods and compare with a server on a different upstream route.
TCPing succeeds, but real connection tests keep timing out. Should I switch regions?
Don’t switch regions yet. Check the system time and account status, then review the v2rayN logs for authentication, TLS, DNS, or timeout errors. Compare the port, server name, and transport path against your subscription. If every server fails only with the same test URL, retry with another working test URL.
Why does a website still see the same exit after I switch servers?
Make sure the new server is active, then check whether the app uses the system proxy and whether routing rules send the destination directly. Have the app establish a new connection before checking the exit; existing long-lived connections may temporarily keep using the old route. You don’t need to re-import the entire subscription right away.
Can I sort by latency and always use the top server?
Sorting only narrows down the candidates. Run three real connection tests for each of the top few servers, try your actual destination, and check the multiplier. If the top server occasionally times out while another connects consistently and meets your needs, use the latter as your primary.
Keep a record: make your choice easy to verify
You don’t need to repeat a full evaluation every day, but keep a brief record. Note the network, time, test method, and real-world results. This makes it easier to tell whether a problem comes from your local network, upstream congestion, or a change in the target service’s access policy.
- Test conditions: Date and time, broadband or mobile network, client, and selected core.
- Connection results: Three real connection tests using the same URL. Record timeouts too, not just successful results.
- Usage costs: Current multiplier, billing unit, and whether uploads and downloads are counted together.
- Service checks: Whether your usual sites are reachable, the exit region meets your needs, and sustained transfers remain stable.
- Primary and backup: Use the primary for everyday traffic. Choose a backup with a different entry point or upstream route, and check periodically that it still connects.
Keep the same order: first confirm compatible settings and a successful proxy connection, then verify that your target service works, and finally weigh stability, latency, throughput, and the multiplier. This gives you a clear basis for your choice and helps pinpoint what to check when something goes wrong.