For users who have imported a subscription but aren’t sure which node to choose. Check the multiplier and exit region first, then compare connection performance on the same network and against the same test target. Finally, test the apps you use every day. The lowest latency doesn’t always mean the fastest downloads, nearby regions don’t guarantee shorter routes, and a protocol name alone says nothing about connection quality.
Reading node names: region, route, and multiplier
Subscription services are often called “proxies” or “VPN providers” and supply a set of server configurations. v2rayN, v2rayNG, and v2flyNG load those configurations and establish connections; they don’t provide nodes themselves. Node names are labels set by the service provider. Terms like “high speed” or “dedicated line” don’t make the client change how it connects.
When comparing nodes, separate the name into three kinds of information: the exit region required by your target service, the traffic multiplier used for billing, and the provider’s description of the entry point and route. The first two determine suitability and cost. Verify the third against the provider’s documentation and real-world connection performance.
| Common label | Usually means | What to verify |
|---|---|---|
| Hong Kong, Japan, US | The exit region claimed by the provider | The target website may identify the exit IP as being in a different region |
| 0.5×、1×、2× | The factor applied to traffic deducted from your account | Whether rates vary by time of day and how upload and download traffic are counted |
| Direct, relayed | The client connects directly to the server, or traffic is forwarded through an entry server first | Entry server location, cross-border route, and performance at peak times |
| Dedicated line, IEPL, IPLC | The provider’s description of the route type | The label alone doesn’t prove bandwidth, congestion levels, or availability |
| Streaming, residential IP | A label describing the intended use or IP address type | The specific service, account region, and current access results |
Don’t assume the server’s location is the same as its exit region. A relay entry point may be nearby while the actual exit is elsewhere. Some websites also use different IP geolocation databases. If you need a specific region, check which location the target website detects after connecting instead of relying on the node name.
Testing latency: use consistent conditions, then check your apps
There are at least three common types of tests. ICMP ping measures how the server responds to probe packets. A TCP test checks whether a connection can be made to a specific port. A real-connection test sends a request to a specified target through the proxy. Each tests a different part of the connection, so their results shouldn’t be ranked together. If a server blocks ICMP, a ping timeout doesn’t mean the proxy is unavailable.
A real-connection test more closely reflects everyday browsing, but results still depend on the test URL, DNS, TLS handshake, and connection reuse. A fast response from one test target doesn’t mean every website will be fast. To compare nodes, use the same client, network, test URL, and method, and repeat the test during the hours you normally use the service.
-
Use the same network
Stick to the same Wi-Fi or mobile network, and pause downloads and video playback. Don’t change DNS, routing rules, or nodes during a test, or you won’t know what caused the difference.
-
Update the subscription
In v2rayNG, tap ⋮ in the upper-right corner of the main screen, then tap Update subscription and wait for it to finish. Make sure the subscription is still active before testing the listed configurations, so an expired server isn’t mistaken for a connection-quality problem.
-
Test the connection
In v2rayNG, tap ⋮ in the upper-right corner of the main screen, then tap Test all configurations (real connection). Menu labels may vary by version. Choose a real-connection test, and don’t mix TCP test results into the same comparison.
-
Repeat and record
Run the same test on each shortlisted configuration, repeating it three times. Record the number of successful tests and the median result. One unusually low reading isn’t enough to establish reliability; repeated timeouts warrant further troubleshooting.
-
Test your actual use cases
Select a candidate configuration and start the connection. The first time, approve Android’s VPN connection request. Open your usual websites, play a video, or connect to the service you need, and check for loading failures or regional restrictions.
Traffic multipliers: calculate the cost before comparing speed
A traffic multiplier usually indicates how much traffic is charged against your account, not a speed multiplier. 2× doesn’t mean twice the speed, and 0.5× doesn’t mean half the speed. If the provider uses the same basis for both figures, estimate the account deduction as: billable traffic used × multiplier.
These are arithmetic examples, not measured results. Assume the provider counts 1 GB of billable traffic and applies no other billing rules. The account deductions at three multipliers would be as follows. This 1 GB isn’t the same as the file size shown by a browser, and no assumptions about other counting rules are included.
- Upload and download: Some providers count both directions. Cloud uploads and video calls may also use your allowance.
- Units: GB and GiB aren’t the same, and the client, operating system, and account dashboard may show different figures.
- Extra traffic: Handshakes, retransmissions, and protocol overhead can make network usage higher than the final file size.
- Reporting delay: Dashboards may update in batches. A temporary lack of deducted traffic doesn’t mean the connection is unmetered.
Set a budget before choosing. For example, if you expect to use 40 GB per month at a 1× rate, using only 2× nodes would deduct about 80 GB. Use higher-multiplier nodes only when they actually improve the service you need. Before downloading large files, check the current multiplier—this matters more than chasing the lowest latency.
Choosing a region: prioritize the exit location you need; use distance as a guide
Geographic distance affects signal travel time, but the full route also includes your local carrier, entry point, relay, and exit. A congested route to a nearby region can be slower than one to a farther region. For everyday browsing, choose a stable connection from the available regions. If a service requires a specific region, meet that requirement first, then compare latency.
Choosing a region: everyday use vs. a required exit location
Everyday browsing and remote work
- Compare real-connection success rates during the hours you usually connect.
- Check initial page loads, meeting reconnections, and upload performance.
- Keep a backup connection with a different entry point or route.
Region-restricted services and account access
- First check which regions the target service allows and what conditions apply.
- After connecting, confirm the exit location the service actually detects.
- Avoid switching regions repeatedly in a short time; keep your access environment relatively consistent.
Meet the service’s regional requirements first. Then compare reliability, latency, and multiplier among suitable candidates; don’t sort by map distance alone.
Video playback also depends on content licensing, account region, and the reputation of the exit IP. A node label can’t guarantee ongoing access. Online games and voice services also require UDP forwarding and the app to be routed through the proxy. A website loading correctly doesn’t prove these services will work.
Protocol types: configuration compatibility matters more than the name
VMess and VLESS are proxy protocols; WebSocket and TCP describe transport methods; TLS and REALITY relate to connection security. These are different dimensions, not alternatives in the same category. VMess provides authentication and data encryption at the protocol layer. VLESS doesn’t encrypt content on its own and is typically used with a security configuration such as TLS or REALITY.
Use these checklists to review two types of configuration; they aren’t ready-to-use configurations or a performance ranking. Use the subscription provided by your service for the address, port, user ID, and security parameters. Port 443 is common, but the port number alone doesn’t prove that TLS is enabled.
VLESS + REALITY
- Protocol
- VLESS
- Security type
- REALITY
- Server identity
- Check the public key and serverName
- Additional parameters
- Set shortId, fingerprint, and flow as specified in the subscription
Not all VLESS configurations use the same flow. Don’t copy parameters from another node or change ordinary TLS to REALITY yourself.
VMess + WS + TLS
- Protocol
- VMess
- Transport
- WebSocket
- Security type
- TLS: verify the server name and certificate
- Transport parameters
- Use the Host and path specified in the subscription
Using WebSocket doesn’t necessarily mean the connection goes through a CDN. An incorrect path, Host, or server name can prevent a reachable server from establishing a proxy connection.
- Desktop: The protocols supported by v2rayN depend on the current core and version. Importing a configuration successfully doesn’t guarantee that a connection will work.
- Android: v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Their support for extended features isn’t identical.
- Security settings: Don’t disable certificate verification just to clear an error. First check the server name, system time, and subscription settings.
- Privacy: Keep subscription URLs, user IDs, and full share links private. Hide sensitive details before posting screenshots.
The same protocol can run on a congested route or one with plenty of bandwidth. Saying “switch to VLESS and it’ll be faster” ignores important factors. First make sure the client can apply the configuration correctly, then compare nodes using the same real-world task.
Making the final choice: primary, backup, and troubleshooting
You don’t need a long list of nodes ranked by a single latency test. A more useful approach is to choose a primary and a backup, and note each one’s multiplier and exit region. Two nodes with different names may share the same entry point and fail together. Their names alone don’t prove they’re independent.
- Rule out unsuitable options first: Expired subscriptions, insufficient balance, incompatible regions, and unsupported configurations shouldn’t be included in speed comparisons.
- Choose a primary connection next: Focus on connection success rates during your usual hours and real app performance, while keeping the multiplier and data allowance in mind.
- Keep a backup: Prefer a configuration with a different entry point or route. Ask the provider if needed; simply choosing a different region label isn’t enough.
- Record your results: Note the network, time, test method, success rate, multiplier, and app performance. Retest when your network conditions change.
Follow this order when choosing a node: availability → required region → app reliability → traffic cost → latency and throughput. This keeps a good-looking speed-test result from becoming your only criterion and makes it easier to decide what to check when something goes wrong. If you’re still unsure about the basic setup, start with the Getting Started guide, then compare nodes on the same network.