How to Read V2Ray Latency Tests: ICMP Ping vs. Real Connection Latency vs. Download Speed

The three tests measure different parts of the path

If a node list shows 35 ms, 126 ms, and 78 MB/s, those figures cannot be compared directly. Milliseconds measure the time for an interaction, while MB/s or Mbps measures how much data moves per unit of time. Even when both are shown in milliseconds, ICMP Ping and real connection latency pass through different protocol stacks.

ICMP Ping usually sends an echo request directly from your device to the node server’s address, mainly measuring network-layer round-trip time and packet loss. It does not complete the VMess, VLESS, Trojan, or Shadowsocks proxy handshake, nor does it verify whether the user ID, port, transport settings, and encryption settings in the node configuration work.

Real connection latency starts the client with the current configuration and establishes an actual connection to the target through the local proxy entry point. This includes DNS resolution, a TCP or other transport connection to the server, the proxy protocol handshake, and waiting for the test target to respond. A download test continues transferring a larger payload and calculates throughput from the data size and elapsed time.

A low ICMP Ping only indicates a relatively short basic network path

Ping is determined by the network path from your device to the server IP. In general, a server in the same region will have lower latency than one across continents, but carrier routing, evening congestion, and detours through intermediate networks can change the result. A nearby node may still show higher latency because of route inefficiencies.

For example, suppose the same computer sends 20 consecutive requests. Node A averages 38 ms with 0% packet loss, while node B averages 31 ms with 15% packet loss. Looking only at the average makes B seem faster, but 15% packet loss causes retransmissions and waiting, so page loads and proxy handshakes are usually less stable. In this case, keep the loss-free node A first.

Some servers limit or ignore ICMP requests, so a Ping timeout does not necessarily mean the proxy port is unusable. Conversely, a server replying to Ping does not mean the subscribed port is listening, much less that the UUID, transport path, or TLS domain matches the configuration. If Ping times out but real connection latency returns a value, trust the real connection result.

• Average latency shows overall round-trip time but can hide individual spikes.
• Minimum latency is close to the route’s ideal condition and does not represent sustained everyday performance.
• Maximum latency and the spread between results help reveal network jitter.
• Packet loss deserves attention before a 5–10 ms difference in average latency.
• Corporate or public networks may filter ICMP outright without affecting permitted TCP connections.

Real connection latency is the best way to confirm whether a node works

Real connection latency includes an entire application-layer process that Ping does not. With common TCP transport, the client must resolve the address, connect to the server port, complete the proxy handshake required by the node configuration, and then reach the test target through the proxy. WebSocket, TLS, or other transport combinations add their own handshake steps.

For that reason, real connection latency being higher than ICMP latency is normal. If Ping is 40 ms and the full test returns 105 ms, that alone does not indicate a faulty node. The extra time may come from TCP connection setup, TLS negotiation, proxy protocol processing, the target site’s response, or a queued client test.

In v2rayN, select one or more nodes, then choose “Server” → “Test Server Real Connection Latency.” Some interface versions also offer the same action in the node’s context menu. When the test finishes, successful results are shown in milliseconds. For timeouts or failures, check the logs to determine whether the node is unavailable, the target cannot be reached, or the wait time was insufficient.

1. Update the subscription first so you do not test an old configuration that the server has already removed.
2. Select the candidate nodes in the node list, then choose “Server” → “Test Server Real Connection Latency.”
3. Set timed-out nodes aside temporarily, then compare latency and stability among those with results.
4. Set a candidate as the active server, enable the system proxy, and open several pages in real use.
5. If the first result looks abnormal, test twice more 30 seconds apart to avoid misjudging a one-off network spike.

If every node shows a real connection timeout at the same time, check the local setup before assuming the entire subscription has failed. Open “Settings” → “Parameters” → “Basic Settings” and make sure the local listening port is not conflicting with another program. A common setup uses 10808 as the local SOCKS entry point; older split configurations may also use 10809 as the HTTP entry point. Always follow the value shown in the current interface.

Download tests measure throughput, not how quickly a web page opens

A download test measures sustained data-transfer capacity. It usually downloads a payload through the current proxy, then divides the transferred bytes by the elapsed time. Results are also affected by local access bandwidth, Wi-Fi quality, the node’s exit capacity, route congestion, limits on the test target, and the client’s concurrency strategy.

Mbps and MB/s cannot be compared as if the numbers were equivalent. Network bandwidth is commonly expressed in Mbps, while file-download interfaces often use MB/s. The theoretical conversion is 8 Mbps ≈ 1 MB/s. An 80 Mbps result corresponds to a theoretical maximum of about 10 MB/s, but protocol overhead, retransmissions, and disk writes make the actual file speed somewhat lower.

A high-bandwidth node does not necessarily have the lowest interactive latency. For example, node A may have 85 ms real connection latency and 42 Mbps download speed, while node B has 145 ms and 160 Mbps. A may feel snappier for everyday browsing, while B is better for high-bitrate video or large-file transfers. Choose based on the task instead of collapsing all three figures into one simplistic ranking.

In v2rayN, select the candidate nodes and choose “Server” → “Test Server Download Speed.” Download tests consume real subscription traffic, so they are not suitable for frequent runs across the entire node list. First narrow the list to two or three candidates with real connection latency, then run one download test on each; that is usually enough to decide.

Test in a fixed order for comparable results

The most common speed-test problem is not a faulty tool but constantly changing test conditions. Testing node A in the morning and node B at night, or using wired networking for one test and Wi-Fi for another, makes the difference impossible to attribute to the node alone. Keep the device, access network, test target, and time window as consistent as possible.

Run three real connection tests for each candidate, 10–30 seconds apart, and record the median instead of taking only the lowest value. For example, with results of 92 ms, 108 ms, and 246 ms, the median is 108 ms. The 246 ms result signals a clear spike and should remain part of the assessment rather than being deleted to display a more flattering number.

1. Stop large-file downloads, cloud synchronization, and system updates currently in progress.
2. Update the subscription on the same network, then select nodes in the regions and with the routing factors you need.
3. Run real connection latency first, excluding configurations with repeated timeouts or proxy handshake failures.
4. Repeat the test three times for the remaining nodes and compare the median and maximum values.
5. Run download tests only for the final two or three candidates.
6. After setting one as the active server, open the websites you actually use and confirm that the system proxy is active.

Node A: real connection 92 / 108 / 246 ms, download 68 Mbps
Node B: real connection 124 / 128 / 131 ms, download 82 Mbps
Node C: real connection timeout / timeout / 310 ms, not selected for now

Browsing priority: node B; slightly higher latency but less variation
Download priority: node B; higher sustained bandwidth as well
Keep observing: node A; check whether 246 ms recurs during the evening peak

To confirm that browser traffic is actually going through the proxy, set the active server in v2rayN, enable the system proxy, and visit a trusted IP information page. Compare the outbound address before and after enabling it. If the address does not change, check the system proxy status and the browser’s own proxy settings first; do not substitute another speed test for verifying the traffic path.

How to handle common abnormal results

When the same node produces noticeably different results within a short period, check the local network, node load, and test target. Do not delete a node after one timeout, and do not lock it in for long-term use because of one unusually low latency result. Repeated results are more informative than a single peak.

Routing rules can also affect whether test results match actual browsing. The test target may use the proxy under the current rules, while a particular domain may be set to connect directly—or the reverse. If the speed test looks normal but one site behaves differently, check which routing rule matched and review the core logs instead of repeatedly running download tests.

The final decision comes down to three steps: use Ping to understand basic network reachability and packet loss, real connection latency to confirm the configuration works and compare interactive response, and download speed to check sustained bandwidth. None replaces the others, and no single figure fully describes node quality.