First rule out servers that are incompatible with your client or can’t reach the services you need. Then narrow your options by multiplier, evening reliability, and intended use. This guide is for users who have imported a subscription but aren’t sure which server to choose. You’ll learn how to estimate billed traffic, distinguish entry and exit locations, and build a short list with a reliable everyday option and a backup route.
Choose in this order: usability before speed rankings
Prioritize servers that handle your actual tasks, fit your budget, and stay reliable when you use them. The lowest latency in the list is only a reference, not a final ranking. A server with a fast handshake may still time out when connecting to a specific site; one with slightly higher latency may deliver more consistent speeds over a long download.
A subscription provides server addresses, ports, authentication details, protocols, and transport settings. Clients such as v2rayN import and manage these configurations, while the core establishes the connection. Labels like “high speed,” “dedicated route,” or location names usually come from the subscription provider—they aren’t measurements made by the client. Treat labels as clues, then verify performance by visiting the services you actually use.
- First: Can it connect? The configuration is complete, the current core supports the protocol, and the target site opens through the server.
- Second: Can it handle the task? For calls, check consistency; for browsing, responsiveness; for downloads, sustained throughput; for region-specific services, the detected exit location.
- Third: What does it cost? Check the multiplier, remaining traffic, speed limits, and concurrency restrictions before committing to regular use.
- Fourth: Is the backup independent? Keep a backup with a different entry point or route, rather than two names for the same server.
Traffic multipliers: calculate billed usage before comparing speed
A server multiplier is generally a billing rule set by the subscription provider, not a VMess, VLESS, or Trojan protocol setting. If the rule is “actual traffic multiplied by the multiplier,” transferring 5 GB through a 2× server uses 10 GB of billed traffic. A higher multiplier doesn’t mean faster speeds, and a lower one doesn’t mean a worse route.
These figures are examples, not actual bills from any subscription provider. Providers may count uploads and downloads together, or use different units, settlement delays, or time-based multipliers. The amount deducted from your account may not match a downloaded file’s size exactly; uploads, retries, and speed tests also use traffic. Check the provider’s terms and your account records.
For large downloads, consider servers with low multipliers and steady throughput. For a short meeting, a slightly higher multiplier may be worthwhile if the connection is more consistent. If a low-multiplier server needs frequent retries, the traffic saved may not be worth the time lost.
Location labels: distinguish entry points, exits, and destinations
A server’s listed location usually refers to its exit, but that doesn’t guarantee the connection enters the network there. Your client first connects to an entry server; traffic may be relayed before exiting toward the destination site. The entry point affects the first leg of the route from your network, while the exit determines the IP location the destination sees. They may be in different places.
| Location | Main impact | How to check |
|---|---|---|
| Your local network | ISP routing, wireless interference, and access-network congestion | Use the same device and network, and avoid downloading at the same time |
| Connection entry point | Connection setup time and quality of the first network leg | Check the server address and the provider’s route details |
| Proxy exit | The IP address and location seen by the destination site | Check the exit through the proxy, then verify it on the destination site |
| Destination service | Distance from the exit to the service and server load | Open a site you use regularly or perform the task you need |
Shorter geographic distance can help reduce latency, but it’s only one factor. ISP routing, peering between networks, and evening congestion can all change the outcome. Don’t rank servers by map distance alone or assume one location is always fastest. For browsing, start by testing a few nearby exits; for region-specific services, first meet the location requirement, then compare responsiveness and reliability.
- An IP lookup site may report a different location from the database used by your destination service.
- A site’s language, account region, or cached content doesn’t tell you where your current proxy exit is located.
- An exit in the right location doesn’t guarantee access to every service; test the service’s policies for shared IP addresses directly.
Route types: understand direct, relayed, and dedicated routes
Route labels describe how a connection is organized, not a universal quality rating. A direct route usually connects your network straight to a remote entry point. A relayed route adds a forwarding hop. Products labeled “dedicated route” may use different kinds of long-distance transport. Check the provider’s documentation for entry and exit points, shared bandwidth, and congestion policies.
Direct-route option
The path is more direct and easier to understand. It can work well when the public route from your network to the remote entry point is good; poor peering can also mean slow connections or timeouts.
Best for: downloads when the public route is good and a low multiplier is a priority
Tested relay option
RecommendedA strong first choice for everyday use—provided it has passed tests on your usual network and during the evening. A relay may improve access to the entry point, but the extra hop and shared bandwidth can also add overhead.
Best for: everyday use where responsive, reliable performance matters and tests beat the direct route
Option labeled as a dedicated route
Check the coverage, speed limits, and multiplier before deciding whether it’s worth using. The label alone doesn’t prove end-to-end dedicated bandwidth or rule out problems with your local Wi-Fi or the destination service.
Best for: sustained tasks like calls, when test results justify the higher cost
The recommendation is for a “tested option,” not every relay route. If a server tests well in the morning but times out repeatedly at night, it’s not a good fit for your main usage hours. Ideally, a backup should use a different entry point or transport route. Switching only the location label on the same route may not avoid a shared point of failure.
Protocols: prioritize compatibility and complete settings
VMess, VLESS, and Trojan are protocols; TCP and WebSocket are transport settings; TLS and REALITY involve connection-security settings. There’s no single answer to which protocol is “faster.” Server load, route, transport, and the destination service often matter more than the protocol name.
| Protocol | Settings to check | What to consider |
|---|---|---|
| VMess | UUID, encryption settings, transport, and TLS parameters | Keep the combination provided by the subscription; authentication requires an accurate system clock |
| VLESS | UUID, transport, security settings, and flow if required | The protocol itself doesn’t encrypt the payload; the security layer must match and be supported by the core |
| Trojan | Password, server port, TLS, and server name | Usually relies on TLS; port 443 alone doesn’t mean the configuration is correct |
The cards below illustrate how to read configuration fields; they aren’t ready-to-use servers. The example domain and path are for explaining the settings only. Port 443 is common, but use the port from your subscription. Changing the server name, WebSocket path, or flow can make a working server fail to connect.
VMess＋WebSocket＋TLS
- Server
example.com, example address- Port
- 443, example value
- Transport
- WebSocket
- Path
/ws-demo, example value- Security layer
- TLS; check the server name and certificate
WebSocket doesn’t necessarily mean traffic goes through a CDN; relaying depends on the actual deployment.
VLESS＋TCP＋REALITY
- Server
example.com, example address- Port
- 443, example value
- Transport
- TCP
- Security layer
- REALITY; check the public key, server name, and shortId
- Flow
xtls-rprx-vision, only if required by the server
This combination requires an Xray core that supports the relevant features. Don’t add or remove subscription fields yourself.
When using v2rayN on desktop, check which core the server actually uses. On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. For servers using REALITY or specific Xray features, don’t assume another client can connect just because it can import the link. Successful import only means the client read the configuration; it doesn’t mean the core supports every field.
Testing workflow: shortlist a few and compare under the same conditions
Start with three candidates; there’s no need to run bandwidth tests on every server in your subscription. The steps below refer to common menus in the v2rayN desktop interface; button locations and labels may vary by version. Before testing, make sure the selected server is active and the proxy mode is correct, so you don’t mistake a direct connection for server performance.
-
Update the subscription
In the main window, open “Subscription Group” → “Subscription Group Settings” and check the address for the group you want. Then use the “Subscription Group” menu to select “Update all subscriptions (without proxy)” or “Update all subscriptions (through proxy).” Choose based on whether the subscription URL is reachable through your current connection. Don’t keep retrying after a failure.
-
Narrow your options
Keep three servers that match your target location and acceptable multiplier. Select a candidate, right-click, and choose “Test server real connection latency.” Use the same test URL for every server. The results help rule out obvious timeouts; don’t pick your main server based on a single ranking.
-
Verify real-world access
Right-click the selected server and choose “Set as active server.” Under System Proxy, select “Automatically configure system proxy,” then open the target site in a browser that follows the system proxy and check the exit location. A site opening in your browser doesn’t mean other apps use the system proxy too.
-
Check sustained performance
Run the same tasks on the remaining candidates: load a web page five times, try a call for about 10 minutes, and observe downloads briefly. Record timeouts, sustained speeds, and stuttering—not just the lowest latency.
-
Test again in the evening
Retest during your main usage window, such as 8–10 p.m. Keep the device, network, test destination, and proxy mode the same to choose a primary and backup. Retest after switching to mobile data; don’t assume the desktop network’s rankings still apply.
If every server fails, first check your local network, system clock, subscription status, and core logs instead of changing protocols one by one. If only one site fails, check the exit, routing rules, and the site’s status. DNS and routing rules can send requests along different paths. Before testing, see the DNS setup guide and subscription configuration guide.
Match servers to tasks: separate everyday use from high-traffic jobs
One server doesn’t have to handle everything. Choosing separately for interactive tasks and high-volume transfers reduces the need for one server to offer low latency, a low multiplier, and high throughput all at once. Test by switching manually before setting up routing rules. If the rules get complicated too soon, it’s harder to tell whether the server is unreliable or the traffic isn’t using it.
A practical setup: reliable everyday server plus low-cost downloads
Browsing and calls
- Prioritize access to the destination service and a stable connection.
- Use the server with the fewest evening timeouts as your primary.
- Check the exit before a call and avoid switching servers mid-call.
- Choose a backup with a different entry point or transport route.
Downloads and bulk transfers
- Check the multiplier, remaining traffic, and speed limits first.
- Compare sustained throughput, not short-lived peaks.
- Avoid saturating your local bandwidth and disrupting calls.
- Switch back to your everyday server when high-volume tasks are done.
You can use different servers from the same subscription for these tasks; check your account rules to see whether they share a traffic allowance.
A short record is all you need: server name, multiplier, exit location, performance during your usual hours, suitable tasks, and backup. Names or addresses may change after a subscription update, so recheck old notes. Even if desktop and Android use the same subscription, test them separately because their networks and app proxy settings may differ.
- Web browsing: Check successful loads and responsiveness first, then compare small latency differences.
- Calls: Check sustained performance and whether the app actually uses the proxy; a bandwidth test can’t replace a real call.
- Large downloads: Check sustained speed and the multiplier. Don’t run long, unnecessary tests on high-multiplier servers.
- Region-specific access: First verify the exit location detected by the destination service, then compare routes and protocols.
Choosing a server is about narrowing the options and testing them for your needs—not finding a name that always ranks first. Compatibility determines whether it connects; the route and time of day shape performance; the multiplier determines cost. Judge these separately and your subscription list becomes easier to manage.