This guide is for anyone comparing multiple VMess and VLESS nodes and unsure which test result matters. Use ping to assess the underlying network path, real connection latency to see how quickly a proxy request completes, and download speed to estimate sustained throughput. Choose nodes by combining all three metrics for the task at hand—not by picking the smallest number in one column.
The Three Tests Measure Different Parts of the Path
How to read it
Ping, real connection latency, and download speed often appear together in node lists, but they operate at different layers. Ping typically sends an ICMP Echo request and measures only the network round trip between your device and the server address. It does not start a V2Ray or Xray proxy session, or verify VMess and VLESS authentication, the TLS handshake, the transport path, or the proxy exit.
How to read it
Real connection latency makes the client send an actual proxy request through the selected node. In a typical v2rayN 7.x workflow, the client starts the core, reads the node configuration, establishes a TCP or other transport connection, completes protocol authentication, and accesses a test URL. The resulting milliseconds are therefore closer to the wait time before the first request when opening a web page.
How to read it
A download test continuously receives data after the connection is established. Besides round-trip latency, it is affected by the server's outbound bandwidth, network congestion, TCP congestion control, packet loss and retransmissions, your local network, and the test file size. One node may have 180 ms of real connection latency yet reach 150 Mbps, while another with only 80 ms may be limited to 12 Mbps by its outbound capacity.
| Test method | What it primarily measures | Uses the proxy protocol | What it can answer |
|---|---|---|---|
| ICMP ping | Network round trip from your device to the server address | No | Is the basic path reachable, and is jitter significant? |
| Real connection latency | Connection setup, handshake, authentication, and proxy request | Yes | How long does the first web request take? |
| Download speed test | Sustained throughput after the connection is established | Yes | How fast are large files and video transfers? |
Why Low Ping Can Still Mean a Slow Node
How to read it
The most common mistake is sorting nodes by ping from lowest to highest and choosing the first one. Suppose a server has an ICMP round-trip time of 24 ms. That only means its server address is close to your current network. A proxy request may still pass through TLS, WebSocket, a relay entrance, or a different exit route, so the path to the actual destination may differ completely from the ICMP path.
How to read it
Some networks rate-limit or deprioritize ICMP, while some servers do not answer it at all. A ping timeout does not mean a VMess or VLESS port cannot connect. Conversely, a stable ICMP response does not confirm that the subscribed port, UUID, transport path, Server Name, or Reality parameters are correct. Only a real connection test covers these configuration details.
How to read it
Low ping also says nothing about speed loss caused by packet loss. Sustained downloads depend on a continuous stream of packets; even 1% to 3% packet loss can trigger retransmissions and shrink the congestion window. A small ICMP sample may look like 30 ms, yet throughput can periodically fall from 80 Mbps to 15 Mbps, making the first screen load quickly while images and video load slowly.
Bottom line: prioritize real connection results when ranking nodes
For web browsing, messaging, or frequent short-lived connections, first remove nodes that time out on real connection tests. Then compare jitter and download speed among nodes with similar latency. The lowest ICMP value alone is not enough to make the final choice.
What Real Connection Latency Actually Includes
How to read it
Real connection latency is not a single network round-trip figure; it is the total of several stages. A node identified by a domain must first complete DNS resolution, then establish a connection to the server port. With TLS or Reality, the corresponding handshake follows. The core then authenticates with VMess or VLESS and requests the test resource through the proxy exit. A retry at any stage can substantially increase the final result.
How to read it
Different transport combinations also have different fixed overheads. VLESS and VMess are proxy protocols, while TCP and WebSocket are transport settings; TLS and Reality provide their respective handshake and connection characteristics. Do not infer speed from the protocol name alone. The actual result depends on server load, path quality, configuration compatibility, and the time of testing.
VLESS + TCP + Reality
- Primary overhead
- TCP and Reality handshake
- Authentication stage
- VLESS user ID verification
- What to watch
- Three consecutive real connection results
- Warning sign
- A timeout or a jump of more than 100 ms
After importing a subscription, preserve the relationship between the server name, port, Flow, Server Name, public key, and short ID.
VMess + WebSocket + TLS
- Primary overhead
- TCP, TLS, and WebSocket connection setup
- Authentication stage
- VMess user information verification
- What to watch
- Difference between the first and later results
- Warning sign
- Incorrect path or failed TLS handshake
The domain, port, Host, path, and TLS parameters must match as a set. An error in any one of them can appear as a real connection timeout.
How to read it
The first test can sometimes be slower than later tests because it may include DNS lookup, core startup, and connection warm-up. A more reliable method is to test each candidate node three times, disregard obvious first-run overhead, and compare the median. For example, with results of 210, 126, and 132 ms, about 132 ms is more representative than recording 210 ms.
How to Test in v2rayN and Android Clients
How to read it
Desktop clients are well suited to comparing nodes in batches. Import the subscription and update the group, then make sure the local network is stable before running a real connection test. Do not download large files or install system updates during testing, or competition for local bandwidth will distort the results. If the test target itself is unstable, repeated results will fluctuate as well.
- In the v2rayN 7.x main window, select candidate servers from the same subscription group. Start with 5 to 10 nodes to avoid interference from too much concurrency.
- Open the “Servers” menu and choose “Test Server Real Connection Latency.” In some minor versions, the same test is available from the server list’s right-click menu.
- Wait for the latency column to update. Remove or temporarily ignore nodes marked as timed out or failed, then test the three lowest results twice more.
- Go to “Settings” → “Parameter Settings” and check the real connection test URL and timeout. The URL should return a small response with a stable HTTP status, so file download time is not mixed into the latency.
- Select a candidate node and set it as the active server. Enable the system proxy, then perform a final check by browsing and downloading with your usual browser and tasks.
How to read it
The common local SOCKS listening port in v2rayN is 10808; some configurations use 10809 for the HTTP entry point. Use the local listening settings under “Settings” → “Parameter Settings” as the source of truth. These ports only let local applications connect to the proxy; they are not the remote node’s server port. Changing a local port will not reduce the remote node’s latency.
How to read it
On Android, v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Both can run latency tests from the node list, but menu names and test implementations may change between versions. When a mobile connection switches between Wi-Fi and cellular data, existing connections may stop working. Restart the active configuration and test again after switching networks instead of reusing the old result.
- Close other tasks that continuously consume bandwidth before testing, keep the screen awake, and prevent the system from pausing background network activity.
- Test the same node at least three times and record the median. Results of 20 ms, 180 ms, and 24 ms indicate one clear jitter spike.
- When comparing clients, use the same network, node, and time window. Do not directly compare results from home broadband with results from a mobile network.
- If the desktop client succeeds while the Android client times out, first confirm that both subscriptions are updated to the same version, then check handshake and DNS details in the core logs.
How to Translate Download Speed into Real-World Performance
How to read it
Download tests measure how much data moves per unit of time. Speed-test tools commonly use Mbps, or megabits per second, while browser download panels often use MB/s, or megabytes per second. Divide by 8 to convert: 80 Mbps is theoretically about 10 MB/s, and 100 Mbps about 12.5 MB/s. Protocol overhead, retransmissions, and disk writes make the actual figure slightly lower.
How to read it
Short tests can mistake connection warm-up and brief bursts for sustained capacity. For node comparisons, run the test for at least 20 to 30 seconds and watch both the average and minimum speed. If a node reaches 160 Mbps for its first 3 seconds but then settles at 45 Mbps, it is effectively a 45 Mbps node; a momentary peak does not represent long downloads.
| Use case | Priority metrics | How to judge it |
|---|---|---|
| Web browsing and instant requests | Real connection latency and jitter | A low median over three tests with no timeouts |
| HD video | Sustained speed and minimum speed | Watch the 30-second curve, not just the peak |
| Large file transfers | Average throughput, packet loss, and stability | No periodic drops to zero during a long transfer |
| Remote interaction | Real connection latency, jitter, and packet loss | A stable 120 ms is usually better than repeated swings between 50 and 300 ms |
How to read it
You also need to distinguish node bandwidth from local access bandwidth. If your local broadband tops out at 100 Mbps and multiple nodes all measure 92 to 95 Mbps, the bottleneck is probably your local line, so those results cannot reveal the nodes’ maximum outbound capacity. If a direct test reaches 500 Mbps while the proxy remains at 40 Mbps over time, investigate the server’s outbound capacity, congestion, or node-level throttling.
Bottom line: judge throughput by the stable range, not a single peak
Run the speed test for 30 seconds and record the average over the final 20 seconds. A node averaging 82 Mbps with a 74 Mbps minimum is better for sustained downloads and video playback than one peaking at 180 Mbps but repeatedly dropping to 8 Mbps later.
A Repeatable Node Selection Process
How to read it
The goal is not to find the node with the lowest single number, but to build a repeatable selection process. Confirm that the configuration works first, narrow the field according to your use case, and finish by validating with real tasks. This avoids misjudgments caused by short-term server load, test-target fluctuations, or local network contention.
- Round one—check reachability: Run a real connection test and remove nodes with authentication failures, handshake failures, or persistent timeouts. Keep nodes whose ping times out if the real connection succeeds.
- Round two—check responsiveness: Test the remaining nodes three times and compare the median and maximum deviation. When medians differ by less than 20 ms, there is no need to switch repeatedly just to chase a smaller number.
- Round three—check throughput: Run a 30-second download test on the top three candidates. Record the average Mbps, minimum Mbps, and whether playback or transfer pauses midway.
- Round four—check real tasks: Open commonly used websites, play video at your usual quality, or run an actual download, and observe the result for at least 5 minutes.
- Round five—retest at different times: Test once during weekday peak hours and once during an off-peak period. If a node drops noticeably only at night, choose based on when you use it rather than relying on daytime results.
How to read it
A practical record might look like this: Node A has a 96 ms median real connection latency, a 62 Mbps 30-second average, and a 55 Mbps minimum; Node B has a 148 ms median, a 118 Mbps average, and a 103 Mbps minimum. Choose A for web browsing and B for large downloads. The “fastest node” depends on the task—there is no universal winner outside a specific use case.
Common Speed-Test Problems and Fixes
Ping times out, but the node connects normally?
How to read it
The server or an intermediate network may not respond to ICMP. Rely on the real connection test and an actual proxy request, and check whether three tests are stable. Do not delete a node solely because ping times out.
The first real connection test is 500 ms, but later ones are only 120 ms?
How to read it
The first result may include DNS lookup, core startup, and connection warm-up. Test three times and use the median. If the first result is abnormal every round, check the DNS settings and core logs.
Latency is only 70 ms—why is download speed below 2 MB/s?
How to read it
70 ms only means the request responds quickly. Check the server’s outbound capacity, local bandwidth, evening congestion, and packet loss, then run a sustained download test for at least 30 seconds. 2 MB/s is approximately 16 Mbps.
Why does the same node produce different results in v2rayN and v2rayNG?
How to read it
First confirm that both clients use the same subscription entry, network, and testing window. Then check the test URL, DNS, core version, and transport parameters. Results from different test targets cannot be compared directly.
Why do all nodes slow down after a batch speed test?
How to read it
Concurrent tests may saturate local connections or create a temporary load on the servers. Narrow the candidates to 5 to 10 nodes, stop other download tasks, wait 30 seconds, and retest in batches.
How to read it
Keep this simple rule in mind: use ping to observe the basic path, real connection latency to confirm responsiveness across the complete proxy chain, and download testing to measure sustained transfer capacity. The three results complement one another; none can summarize node quality on its own. Results are comparable only when you use the same network, test target, time window, and duration.