First make sure a node can reach the services you need. Then compare latency consistency, sustained speed, and traffic cost. This guide is for users who have imported a subscription but aren’t sure which node to choose. Use repeated tests on the same network to shortlist a primary node, check location and protocol compatibility, and keep a backup on a different route. A single best-case latency result is only a starting point.
Latency tests: know what you’re measuring
A node typically includes a server address, port, credentials, protocol, and transport settings. Its subscription name is only a label, not proof of performance. Two entries both labeled “low latency” may use different gateways or relay routes—or point to the same server.
TCP latency mainly measures how long it takes to connect to the server’s port; it doesn’t represent the full time for a request through the proxy. A real connection latency test usually sends a request to a test URL through the proxy, and is also affected by the handshake, DNS, test site, and server egress. Don’t rank these two types of results together. If you change the test URL, run the test again.
- In the v2rayN main window, select a candidate server, right-click, and choose the TCP latency or real connection latency test. Wording may vary by version; use the test type shown in the menu.
- Compare only results from the same test type. Keep three candidates for now, and don’t run downloads or batch speed tests at the same time.
- Repeat the tests on the same network and note the median and number of timeouts. Then open the sites you actually use and check both the initial load and subsequent visits.
- Test once during the day on a weekday and again in the evening. A node that performs well only during off-peak hours may not be a reliable all-day choice.
These figures are testing suggestions, not results measured by this site. For example, if one node returns 58, 60, 61, 63, and 65 ms across five tests, while another returns 35, 39, 180, and 260 ms plus one timeout, start by trying the first for everyday browsing. Its median is 61 ms; despite the second node’s lower best result, its performance is clearly inconsistent. Don’t judge by the best result alone.
Speed and multipliers: calculate bandwidth and traffic cost separately
Latency affects how long short requests feel; sustained throughput affects large downloads and video buffering. A low-latency node can get congested in the evening, while a higher-latency node may have more egress bandwidth available. Test with the same resource, tool, and observation period. A peak from a multithreaded speed test doesn’t necessarily reflect playback or a single-connection download.
| Metric | Example | How to interpret it |
|---|---|---|
| Sustained download speed | 5 MB/s | About 40 Mbps; note the difference between bytes and bits |
| Target video bitrate | 20 Mbps | Leave some headroom rather than matching the bitrate exactly |
| Node traffic multiplier | 0.5×、1×、2× | Check how the provider calculates usage for uploads, downloads, and rounding |
| Billing calculation | 10 GB × 2 = 20 GB | Applies only when charges are calculated by multiplying data transferred by the multiplier |
A multiplier is not a speed tier. A 2× node isn’t twice as fast, and a 0.5× node isn’t necessarily slower. It’s usually a provider-defined factor for deducting data allowance and may depend on route costs, time of day, or plan. If both uploads and downloads count, file uploads, cloud sync, and speed tests also use your allowance. Check the provider’s billing terms for the exact details.
Node locations: ingress and egress aren’t the same
A location in the node label may refer to the egress location—or simply be the provider’s route category. A relayed connection may first reach an ingress server, then access the destination from another region. Low latency from your location to the ingress doesn’t mean the destination sees an egress server nearby. Geographic distance is one clue; ISP peering and routing detours also affect performance.
- Everyday browsing: Choose a route that’s stable on your current network. There’s no need to switch just for a location label.
- Region-restricted services: Check availability using the service’s own location detection. A node label or a single IP database isn’t enough.
- Account access: Keep your usual egress location consistent where possible. Frequent sign-ins from different regions may trigger extra verification.
- Downloads and video: Compare real-world speeds to the same resource. A route that works well with one site may not work as well with others.
Before checking egress, make sure the app is actually using the proxy. The v2rayN system proxy affects apps that follow that setting, while routing controls outbound selection after traffic reaches the core. Your browser may use the proxy while another app connects directly. Keep routing mode unchanged during testing; otherwise, “the location didn’t change after switching nodes” may simply mean the request matched a direct-connection rule.
Protocols: check parameter compatibility and core support first
VMess, VLESS, and Trojan are connection protocols, not quality ratings. First check which protocol the server supports and whether the client recognizes all the required parameters. Subscription fields such as network transport, TLS, server name, and path must also match. Changing the protocol label to VLESS won’t improve a connection by itself.
Node compatible with the full subscription settings
RecommendedKeep the protocol, port, transport, and security settings provided by the service, then test real-world access. If a VMess or Trojan node is already working reliably, there’s no need to replace it just because the name seems dated.
Best for: Everyday use and importing a subscription for the first time
VLESS with REALITY
REALITY is a security-related transport feature, not a standalone node protocol. This common setup usually requires the Xray core and matching the server name, public key, shortId, and other parameters provided by the server.
Best for: Setups where the server explicitly provides this combination and the client core supports its parameters
VMess with an existing transport setup
Check the transport type, path, Host, and TLS settings. With v2flyNG, verify the subscription against the capabilities of its V2Fly core; don’t assume every Xray extension is supported.
Best for: Existing VMess services and setups that need to keep their current configuration
On desktop, check the core currently used by v2rayN and review its logs. On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Being able to import an entry in the GUI doesn’t mean the underlying core accepts every parameter. If a transport or field isn’t supported, check the client and core versions, then ask the provider for a compatible configuration instead of blindly removing or changing security settings.
Choose by use case: stability for browsing, sustained speed for video, and route quality for gaming
Your primary node doesn’t need to rank first in every metric. Browsing depends more on reliable page loads, video on sustained throughput, and gaming on UDP support, packet loss, and latency to the game server. Comparing performance in the apps you actually use is more useful than relying on an overall ranking in a speed test.
Assign roles to candidates: everyday use and sustained transfers
Everyday browsing and work
- Choose a node with consistent results across repeated tests and few or no timeouts.
- Keep your usual egress region consistent and make sure you can sign in to your target sites.
- If performance is similar, choose the candidate with the lower traffic multiplier.
Video and large downloads
- Check sustained speed for at least 60 seconds, then verify with a longer real-world playback test.
- Also check for evening congestion, changes in buffering, and your plan’s remaining allowance.
- Keep a backup on a different route; don’t rely on an alias that uses the same egress.
Bottom line: prioritize stability for your primary node and sustained throughput for heavier use. Choose a backup that’s less likely to share the same ingress or egress failure point.
Test UDP separately for gaming
The system HTTP proxy usually doesn’t handle a game’s UDP traffic. Even if a browser can load pages and TCP latency is low, the game may still connect directly. Check how the client handles traffic, app routing, node UDP support, and the route to the game server. If you use the v2rayN TUN feature, also check that the current core and permissions meet the requirements.
- Record latency, packet loss, and login behavior when connecting directly to the game server to establish a baseline.
- Enable a traffic-capture method that suits the game, then check the logs or connection list to confirm game requests are appearing.
- Play for 10 minutes on the same game server and watch for latency spikes, disconnects, and voice chat issues.
- If performance doesn’t improve, restore the original settings. A better browser speed test doesn’t prove the game is using that node—or that it will be faster.
Troubleshooting: timeouts, unchanged locations, and nodes that stop working
Latency is only 40 ms. Why are pages still slow?
First check whether you measured TCP latency or real connection latency. Then select the node and open the target site without changing routing settings. Check DNS, handshake time, and sustained download performance. If only one site is slow, compare routes to that site before blaming the node as a whole.
All node tests time out. Is the entire subscription broken?
First confirm your local network works by connecting directly. Then check that the test URL is reachable, the client’s clock is correct, and the core logs show no errors. If the logs indicate that a local port is already in use, check the local listening port under “Settings” → “Parameter Settings.” For example, if the configured port is 10808, the app must use that port and the correct proxy type; don’t just copy settings from another device.
I switched to a node in another region, but the site still shows the old location. Why?
First check whether the site request matched a direct-connection rule, then confirm that the browser is using the client proxy. Once you’ve verified that egress has changed, start a new session and check again. Account region, location history, and delays in IP database updates can all affect what the site displays. Don’t rely on the node name to determine its egress location.
The node worked yesterday but not today. Should I delete and re-add it?
First update the existing subscription and check whether the provider changed the address, port, or plan status. Then test a backup node. If the same node only slows down in the evening, congestion is a likely cause. If the handshake keeps failing, check the time, parameters, and core support. Repeatedly deleting and re-adding a node won’t fix a server-side issue and may erase custom labels.
Keep a brief record of the test date, network, node label, latency test type, median, timeouts, multiplier, and intended use. Test again after changing networks or subscription routes rather than reusing last month’s rankings. The goal is to find a stable combination for your current setup, not to chase the lowest number in the list indefinitely.