For users comparing V2Ray node quality, this guide breaks down ICMP ping, real connection latency, and download testing, with practical guidance for gaming, web browsing, video, and large-file transfers. You’ll learn whether a low latency number really means a faster connection and how to retest unreliable nodes consistently.
These three numbers measure different parts of the route
Seeing 35 ms, 118 ms, and 76 Mbps in the node list at the same time is not contradictory. Milliseconds measure the time required for a round trip or request, while Mbps measures how much data moves per unit of time. The first two describe waiting time; the last describes sustained throughput. Their units and uses are different.
ICMP ping normally sends an echo request directly from the operating system to the server address. Once the packet reaches the server’s network interface and receives a reply, the test is complete. It reflects the basic round-trip time and packet loss between your network and the server address, but usually does not pass through VMess, VLESS, transport encapsulation, the TLS handshake, or the proxy exit.
ICMP ping
Measures the basic network round trip between your device and the server address. It is quick and useful for an initial check of geographic distance, route detours, and obvious packet loss.
Best for: quickly filtering out high-latency or unresponsive addresses
Real connection latency
RecommendedThe client core, node protocol, and proxy exit are used to request a target, making this closer to the wait you experience when opening a web page.
Best for: choosing nodes for everyday interaction and web browsing
Download speed test
Data is transferred continuously for a set period, and throughput is calculated from the total bytes transferred and elapsed time. Results are usually shown in Mbps or MB/s.
Best for: video playback, large downloads, and sustained transfers
Real connection latency covers a longer route than ping. With v2rayN and the Xray core, for example, a request passes through the local proxy listener, the node protocol handshake, a TCP or other transport connection, optional TLS negotiation, and then the server’s exit to the test address. The target’s response time, DNS resolution, and exit route all affect the result.
Download testing measures sustained transfer capacity further along the route. It depends not only on round-trip time, but also on server throttling, exit bandwidth, your local broadband connection, cross-network congestion, TCP congestion control, and the source of the test file. A node can have 160 ms latency while sustaining 100 Mbps, or just 45 ms latency yet reach only 8 Mbps during a continuous download.
Bottom line: check real connection latency first when choosing a node
For quickly opening web pages or making frequent short requests, prioritize nodes with stable real connection latency and a low failure rate. Give sustained download speed higher priority only for video and large-file use cases.
Why ping can be low while real connection latency is high
The most common reason is that the two tests end at different points. Ping stops when the server address replies to ICMP, while a real connection test still has to reach an external target from the server. A good route into the server does not guarantee an equally smooth route from the server’s exit to the test target.
Protocol handshakes also add fixed overhead. Establishing TCP usually takes one round trip, and the initial TLS negotiation requires additional data exchanges. If a node uses WebSocket and TLS, a real connection test has more steps than a simple ICMP echo. The processing cost of VLESS or VMess is usually not the main bottleneck; cross-region round trips, TLS, and exit congestion are more likely to widen the gap.
The figures above come from an illustrative set of records collected on the same network: Windows 11 24H2, v2rayN 7.12.5, and Xray-core 25.6.8, with a local mixed proxy port of 10808. 78 Mbps is about 9.75 MB/s, although browsers and download tools may show different figures because of sampling intervals and protocol overhead. These numbers illustrate the relationship between units, not node performance.
| Symptom | Common causes | What to check |
|---|---|---|
| Low ping, high real connection latency | Exit route detour, slow TLS handshake, or a slow response from the test target | Change the test target and run three consecutive real connection tests |
| High ping, but downloads remain fast | Long distance with a stable route and sufficient available bandwidth | Watch sustained download speed and variation for at least 30 seconds |
| Ping does not respond, but the proxy works | The server or upstream network does not respond to ICMP | Use a real connection test; do not delete the node based on a timeout alone |
| Low real connection latency, but web pages are still slow | Local routing rules, DNS, or congestion at the target site | Check the system proxy, routing rules, and core logs |
How to run a comparable node test
Comparability matters more than a single number. Do not test one node in the morning and compare it with another during the evening peak. Keep the device, access network, client version, core, test target, and time window consistent, and pause bandwidth-heavy sync or download tasks.
In v2rayN 7.x, select the nodes you want to compare, then choose “Server” → “Test server real connection latency.” To check basic network status, choose “Server” → “Test server latency.” Menu labels may vary slightly between minor releases, but distinguish “Latency” from “Real connection latency” rather than treating the two columns as the same metric.
- In “Settings” → “Parameter settings,” first confirm that the local listening port is not in conflict, and note which core type is currently in use.
- Choose three to five candidate nodes and run three rounds of real connection latency tests, leaving about 10 seconds between rounds.
- Ignore an anomalous spike in the first round if it may be caused by a cold DNS cache or the initial TLS negotiation, and record the median of the final two rounds.
- Connect through the two nodes with the lowest median latency, then download the same test file continuously for 30 to 60 seconds on each.
- Repeat the test during the evening peak. If both latency and speed deteriorate noticeably, factor time-of-day congestion into your decision.
Recommended approach: measure interactive latency and sustained throughput separately
Web browsing and instant requests
- Focus on the median real connection latency
- Record timeouts and result variation
- Compare nodes using the same protocol and transport
Video and large files
- Run the speed test continuously for at least 30 seconds
- Watch both the minimum and average speed
- Retest during the hours you actually use the connection
Use real connection latency to narrow the candidates first, then use sustained download speed to choose the final node. This reduces the risk of being misled by a temporary speed-test spike.
Keep the routing mode fixed throughout testing. If the browser’s download address is classified as a direct connection by the rules, you will measure local broadband speed rather than node throughput. Check the core logs in v2rayN to confirm that the request matched a proxy outbound, or temporarily use global proxy mode for comparison before restoring your usual split-routing settings.
How to read averages, jitter, and packet loss together
Looking only at the lowest value can lead you to choose a node that was merely fast by chance. One result at 48 ms does not mean later requests will remain at 48 ms. If the sequence is 48, 51, 236, 55, and 420 ms, the average is pulled upward by the spikes while the median stays near 55 ms. The median describes typical behavior; the maximum and spread indicate the risk of stuttering.
Interactive applications are sensitive to jitter. Web pages load through multiple connections and requests, so occasional jumps into the hundreds of milliseconds can leave some resources waiting. Video buffering absorbs part of this variation and therefore relies more on sustained throughput; real-time voice and remote operations care more about stable latency and packet loss.
- Median: Sorts multiple results and takes the middle value, making it useful for representing a node’s typical latency during the current period.
- Jitter: Measures changes between consecutive results. When most results differ by no more than 15 ms, the connection is usually more stable than one that repeatedly jumps between 40 and 300 ms.
- Packet loss: Losing one of 10 pings means 10% packet loss. Even with low average latency, noticeable loss triggers retransmissions and reduces real-world speed.
- Timeout rate: Repeated timeouts in real connection tests indicate failures in the complete proxy route, which is more meaningful than a single unusually low successful result.
Bottom line: record the median and failure count
Test every candidate for at least three rounds. If two nodes differ by only 10 ms in median latency but one times out twice, prefer the node with no timeouts and less variation.
ICMP packet loss cannot be equated directly with packet loss on proxy traffic. Some networks deprioritize or restrict ICMP replies while TCP traffic continues normally. If ping shows loss but the real connection is stable, continue checking downloads and actual access instead of judging by ICMP alone.
Which metric matters most for different use cases
Web browsing, search, and API requests consist of many short connections or transactions, so waiting time dominates. Reducing real connection latency from 300 ms to 100 ms is usually more noticeable than increasing download speed from 80 Mbps to 100 Mbps. For these scenarios, eliminate nodes with timeouts first, then compare median real connection latency.
HD video and large-file transfers depend more on stable throughput. As long as latency is not high enough to cause frequent timeouts, a node with 180 ms latency and 80 Mbps may be better for sustained downloads than one with 60 ms and 12 Mbps. Remember that 8 Mbps is theoretically about 1 MB/s, while 80 Mbps is about 10 MB/s; actual speeds will be slightly lower because of protocol overhead.
- Everyday web browsing: Prioritize real connection latency, then check variation and timeout rate.
- Remote terminals: Prioritize stable latency; sustained bandwidth needs are usually low.
- Video playback: Prioritize sustained download speed, while also watching the minimum speed during the evening peak.
- Large-file transfers: Prioritize average throughput and extend the test to at least 60 seconds.
- Bulk subscription screening: Use ping for a quick first pass, then run real connection tests on the candidate nodes.
Keep node protocols comparable as well. A VLESS node and a VMess node may be in different regions and use different transports and exits, so the difference cannot be attributed simply to the protocol name. The protocol defines connection format and capabilities; actual latency is still driven mainly by physical distance, carrier routing, congestion, and server load.
v2rayNG test results are likewise affected by the Android device’s current network. Wireless signal changes, mobile-network handoffs, and background downloads can all alter the results. Desktop v2rayN and Android v2rayNG should be tested separately even with the same subscription; do not apply millisecond figures from one device directly to the other.
Common latency testing questions
Does a ping timeout mean the node has stopped working?
Not necessarily. In v2rayN, first run “Server” → “Test server real connection latency.” If the real connection returns a result and web pages open normally, the server or an intermediate network probably just does not respond to ICMP.
Why is the first real connection test always slower?
The first test may include DNS lookup, core startup, the initial TCP connection, and the first TLS negotiation. Run three rounds and check the median; do not keep only the lowest value or rank nodes based solely on the first result.
Why is the download speed still only 2 MB/s when latency is just 40 ms?
40 ms only indicates a fast request round trip. 2 MB/s is about 16 Mbps, and the bottleneck may be server throttling, exit bandwidth, cross-network congestion, or the test source. Downloading the same file through another node is the way to confirm whether the bottleneck follows the node.
Do I need to enable the system proxy during a speed test?
When you use v2rayN’s built-in real connection test, the client runs the test through the selected node. When testing with a browser or download tool, confirm that the system proxy is enabled and use the core logs to verify that the request actually entered the proxy outbound.
Which number should I sort by after updating a subscription?
Run real connection latency tests in bulk first, remove or disable configurations that repeatedly time out, then run sustained download tests on the low-latency candidates. For everyday web use, choose based on stable real connection latency; for large files, choose based on actual throughput.
The final decision should reflect the route you actually use. Ping is a quick diagnostic, real connection latency measures the wait for a complete proxied request, and download testing measures sustained transfer capacity. They answer three different questions—“How far is the basic network path?”, “How long does a proxied request take?”, and “How much data can it transfer over time?”—and none can replace the others.