This guide is for users with dozens of subscription nodes who are unsure which one to choose. First confirm that a node connects, then compare real connection latency and sustained throughput, and finally consider region, multiplier, and protocol for the task at hand. Node names are clues, not a substitute for testing on the same network.
Read Node Names First: Regions, Routes, and Multipliers Explained
Subscription node names usually combine a region, city or data-center abbreviation, route label, traffic multiplier, and protocol hint. For example, “HK-BGP-01｜1x｜VLESS” may indicate a Hong Kong node, route number 01, 1x traffic billing, and a VLESS configuration. “JP-02｜0.8x｜VMess” may indicate Japan, 0.8x billing, and a VMess configuration. Naming conventions are set by each subscription provider, so the same abbreviation may mean different things across subscriptions.
A region generally describes the proxy exit or server location; it does not mean data travels in a straight line from your location to that node. The actual route is also affected by your ISP, international gateways, evening congestion, and return routing. Nearby regions often offer lower latency, but physical proximity does not guarantee a better route: a distant route with fewer detours may be more stable than a congested nearby one.
Labels such as “BGP,” “transit,” and “dedicated line” are provider-side descriptions. Labels alone cannot verify the actual route, so judge them alongside real connection latency, stability at different times, and download speed. Node numbers do not indicate a performance ranking: “01” is usually just an identifier, not proof that it outperforms “08.”
A multiplier is the rate at which traffic is deducted from your account. Transferring 1 GB through a 1x node usually deducts 1 GB; through a 2x node, 2 GB; and through a 0.5x node, about 0.5 GB. A multiplier has no fixed relationship with speed. A 2x node may have a better route, or it may simply belong to a different pricing tier. Check your subscription account for the exact billing rules, and remember that speed tests also consume traffic.
- Region label:Use it to narrow the field, such as starting with nearby regions for an initial latency check.
- Route label:Use it as a selection clue, not as a direct performance verdict.
- Traffic multiplier:It determines account usage, so check it carefully before downloading large files.
- Protocol label:Cross-check it against the node type recognized by your client.
How to Read Latency: Do Not Simply Pick the Smallest Number
The most common mistake when choosing a node is activating the one with the lowest latency immediately. A basic network probe only shows reachability and round-trip time; it may not include the full proxy handshake, encryption, and transfer process. Some servers restrict probe requests, so a list may show a timeout even though a proxy connection can still be established. Conversely, very low probe latency does not guarantee that the proxy works in practice.
Real connection latency in v2rayN is better suited to the first round of screening. It attempts to establish an actual connection through the node, so the result includes proxy-handshake and target-connection time. On the same computer and network, three tests might return 74, 81, and 79 ms—an average of about 78 ms with little variation. Another node might return 88, 240, and 126 ms. Although its best result is similar, the jitter is much worse, making buffering more likely during video playback and real-time interaction.
Real connection latency
RecommendedIncludes the proxy handshake and target connection, making it a more direct way to weed out dead nodes. Run three consecutive tests and consider both the average and the variation.
Best for: initial screening, web browsing, and real-time interaction
Basic network latency
Fast and inexpensive to test, but the result can be affected by the server’s response policy and cannot prove that the proxy path works by itself.
Best for: a quick reachability check
Actual download speed test
Shows sustained throughput, but consumes subscription traffic and is also affected by test-source limits, disk performance, and local bandwidth.
Best for: video, large downloads, and bandwidth verification
Latency and speed measure different things. An 80 ms node may sustain only 3 MB/s, while a 140 ms node may reach 12 MB/s. Web pages involve many small requests, so latency, jitter, and connection success rate usually matter most. Large downloads depend more on sustained throughput, while video needs both sufficient throughput and stability. Do not record only the peak; watch the average speed for at least 30 to 60 seconds.
Bottom line: Keep low-jitter nodes instead of chasing a one-off minimum
A node that records 80–95 ms across three real-connection tests is usually more predictable than one that hits 55 ms once but exceeds 200 ms twice. Eliminate timeouts and high-variation nodes first, then test the remaining candidates with real browsing or downloads.
Run a Repeatable Node-Screening Pass in v2rayN
The steps below use the menu labels from v2rayN 7.12.3. Minor releases may move items around, but the workflow remains the same: update the subscription, keep the test environment consistent, run real connection tests, retest candidates, and confirm the system proxy. Before testing, pause bandwidth-heavy sync, video, and download tasks so local network load does not distort the results.
-
Update the subscription
Open “Subscription groups” on the main screen and choose “Update all subscriptions” so you are not testing nodes that have been removed or whose settings have changed.
-
Keep the environment consistent
Stay on the same network connection, pause background downloads, and open “Settings” → “Parameter settings” → “Core type” to confirm the active core. Do not switch cores during a single comparison.
-
Screen the nodes
Select candidate nodes from the same region, then use the node-testing menu to run “Test server real connection latency.” Remove entries with repeated timeouts, connection failures, or clearly abnormal latency first.
-
Retest the finalists
Test each of the remaining 3–5 nodes three times, about 10 seconds apart. Record the average latency and highest value instead of ranking nodes by a single result.
-
Confirm the proxy
Set a candidate as the active server, enable the system proxy, and visit sites you use regularly. If the local SOCKS listening port is set to 10808, also make sure no other program is using it.
If every node times out at once, first check whether the subscription updated successfully, whether the system clock is accurate, whether the core started normally, and whether the local port is conflicting. Do not keep switching regions at this stage: when everything fails, the cause is usually local configuration, subscription status, or current network conditions—not one particular node.
Choose Nodes by Task: Browsing, Video, Downloads, and Temporary Use
For everyday web browsing and chat, prioritize real connection latency, jitter, and connection success rate. If three candidates measure 72 ms, 96 ms, and 128 ms, and the first two connect reliably, start with the 72 ms node. If it fails every few minutes, switch to the stable 96 ms node. A difference of a few dozen milliseconds is rarely worth frequent disconnects.
Video playback needs sustained throughput above the actual bitrate, with some headroom. If a given quality requires an average of 15 Mbps and the node sustains only 17 Mbps, any fluctuation can trigger buffering; a sustained 30 Mbps or more leaves much more room. Focus on stable speed rather than momentary peaks, and avoid repeated large speed tests on high-multiplier nodes.
For large downloads, compare average speed, multiplier, and remaining traffic. In this example, node A has 78 ms real connection latency, an average download speed of 8.6 MB/s, and a 2x multiplier; node B has 132 ms latency, 7.9 MB/s, and a 1x multiplier. For a 20 GB download, A’s speed advantage is limited, but it may deduct about 40 GB from the account. When traffic is tight, B is often the better choice.
- Everyday browsing:Prioritize low latency, low jitter, and a high connection success rate; consider the multiplier second.
- Video playback:First confirm that sustained throughput covers the target bitrate, then compare latency and the multiplier.
- Large downloads:Focus on average speed, download size, multiplier, and remaining allowance.
- Temporary access:As long as the target service responds normally, there is no need to switch nodes repeatedly over a few milliseconds.
- Long-term backup:Keep 2–3 working nodes across different regions or route numbers so a single change does not disrupt your access.
The region also affects the exit location seen by the target service. If a task requires a specific exit region, satisfy that requirement first, then compare routes within that region. Without a regional requirement, testing nearby regions is usually more efficient. The target website’s own server location matters too: the best node for a service hosted in Asia may differ from the best node for one hosted in North America.
Bottom line: Maintain primary, download, and backup tiers
Choose a low-jitter route for your primary node, balance throughput and multiplier for downloads, and keep backup nodes in different regions or under different route numbers. Retaining one or two candidates per tier is faster than choosing again from dozens of nodes every time.
How to Evaluate Protocols: VMess, VLESS, Trojan, and Shadowsocks
When a subscription includes several protocols, do not rank their speeds by name alone. VMess, VLESS, Trojan, and Shadowsocks use different authentication and transport methods, but the latency and throughput you actually experience are usually influenced more by server load, international routing, transport-layer settings, and your local network. Two nodes using the same protocol can differ by several times in speed, while high-quality nodes using different protocols may perform similarly.
VLESS is often paired with transport configurations provided by the Xray core. It does not encrypt content by itself; actual security and connection behavior depend on the complete configuration. VMess includes its own authentication and encryption mechanisms and remains common in existing subscriptions. Trojan connections typically use TLS, while Shadowsocks uses the encryption method specified in its configuration. Let the subscription import the full parameters instead of guessing transport settings from the node name.
When using v2rayN on desktop, confirm that the selected core supports the protocols and transport settings delivered by the subscription. The Android v2rayNG uses the Xray core, while v2flyNG uses the v2fly core; some newer configurations in the same subscription may behave differently depending on core support. If a node connects in one client but repeatedly fails in another, check core capabilities and imported parameters before declaring the server unavailable.
Why Is the Lowest-Latency Node Sometimes Slower?
Latency measures the time for one connection round trip, not available bandwidth. Run an actual 30- to 60-second download through each candidate and compare average speed and variation. If the test file is large, also pay attention to the node multiplier.
Does a Node Labeled 2x Always Mean Higher Speed?
Not necessarily. 2x indicates the traffic deduction rate, not a speed guarantee. Test 1x and 2x nodes with the same source, then calculate the actual traffic cost based on the download size.
What If Every Real Connection Latency Test Times Out?
Start by updating all subscriptions, then check the core logs for port conflicts or startup failures. Confirm that the system clock is correct and check whether another program is using the local SOCKS port 10808.
Is It Normal for the Same Node to Be Fast During the Day and Slow at Night?
International routing and server load can change throughout the day. Test three times during both daytime and evening. If evening latency consistently exceeds twice the daytime figure or connections keep dropping, demote the node to backup status.
Which Protocol Should I Choose First?
First confirm that the client core fully supports the configuration, then rank candidates by real connection latency, stability, and throughput. Treat the protocol name as a compatibility requirement, not a standalone speed ranking.
Node selection is not a one-time task. Subscription-server load and network routes change, so yesterday’s best node may be congested today. A safer approach is to keep a set of candidates, rerun a real connection latency test when problems appear, and switch to a previously verified backup instead of immediately changing many client settings.
The final decision can be reduced to four steps: confirm that the node completes a real connection, check latency variation across repeated tests, verify throughput for browsing, video, or downloads, and then calculate whether the multiplier and region meet your needs. The protocol determines whether the current core can process the configuration correctly; route quality and measured results determine the experience.