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

The Three Tests Measure Different Parts of the Route

Seeing 40 ms, 120 ms, and 80 Mbit/s in a node list is not contradictory: each number describes a different task. Ping usually sends ICMP packets to the server address and records the round-trip time. Real connection latency uses the client to establish a proxy connection through a VMess or VLESS node, then reaches the test target. A download test continuously transfers data to measure available throughput.

ICMP ping has the narrowest scope. It shows the basic round-trip time and packet loss between your network and the target address, but it does not verify that the node port is open or perform TLS, WebSocket, gRPC, Reality, or proxy-protocol handshakes. Even with a 38 ms ping, the first web request may exceed 150 ms after connecting to TCP 443, completing TLS negotiation, and establishing a VLESS channel.

Real connection latency is closer to the wait you experience when opening a web page. Clients such as v2rayN typically start a local proxy, request a test address through the selected node, and measure the time needed to establish the connection and receive a response. The result may include the local SOCKS inbound, core processing, proxy-protocol handshake, server-side outbound connection, target-site response, and some DNS resolution, so it better reflects whether the node is genuinely usable.

Why Is the Ping Low but Web Pages Still Slow?

The most common reason is that ping skips the proxy setup process. Suppose the server address has a 45 ms ICMP round trip: establishing TCP requires at least one more round trip; TLS adds a negotiation phase; WebSocket requires an HTTP upgrade; only then can the proxy core open an outbound connection to the target site. Every step can add waiting time.

A second reason is that ping and the web request target different destinations. Ping measures the route from your client to the node entry point, while opening a web page also includes the route from the node to the target site. A node may be physically close to you while its server takes a detour to the target, resulting in high real connection latency. Conversely, a node with slightly higher entry ping may load pages and downloads more smoothly if its server-side exit is stable.

A third reason is that ICMP handling may differ from TCP and UDP traffic policies. A server may rate-limit ICMP responses or ignore them entirely while port 443 or another node port continues to work normally. An ICMP timeout only means that this ping received no response; it does not by itself prove that the VMess or VLESS configuration is broken.

• The VMess and VLESS protocol names do not determine latency on their own. Server location, transport layer, congestion, and exit routing are usually more important.
• WebSocket, gRPC, and plain TCP use different handshake flows, so do not rank transports based on a single test result.
• When split routing is enabled, confirm that the test address actually goes through the current node; otherwise you may be measuring a direct connection.

How to Read Real Connection Latency and Download Speed Together

Real connection latency answers “How long until the response starts?” Download speed answers “Once connected, how much data can be transferred per second?” Browsing short pages, making API requests, and interactive use depend more on the former; downloading large files and loading high-bitrate content depend more on the latter. One node may complete a request in 110 ms but sustain only 3 MiB/s, while another takes 180 ms for the first byte yet holds a steady 12 MiB/s.

Here is a sample recorded on the same computer, wired network, and test file. Other downloads were stopped beforehand. The v2rayN local SOCKS port was 10808 and the HTTP port was 10809. Real connection latency was tested 3 times and reported as the median; download speed was averaged over 30 seconds after the connection stabilized.

In this set, proxy download speed reached roughly 90% of the direct-connection baseline, indicating good bandwidth utilization. Real connection latency was 67 ms higher than ping, reflecting the combined cost of the proxy handshake and the route from the node to the test target. You cannot attribute all 67 ms to one protocol: target-site response time, DNS cache state, and connection reuse also affect the result.

Keep units consistent when converting. Clients and browsers often show download speed in MiB/s, while network bandwidth is usually measured in Mbit/s. A rough conversion multiplies by 8, but MiB and MB are defined differently. 11.5 MiB/s is about 96.5 Mbit/s, so do not compare 11.5 directly with “100 Mbit/s.”

Recommended Test Order: Check the Environment, Then Filter Nodes

The order matters more than clicking the speed test repeatedly. If the subscription is updating, the browser is downloading, or system-proxy modes are changing during testing, the numbers are not comparable. On desktop, open v2rayN first and check the local listening ports under “Settings” → “Parameter Settings,” then verify the current system-proxy and routing modes.

1. Establish a direct-connection baseline. Temporarily stop proxy traffic and record the direct speed for the same file and the response time of an ordinary web page. If the direct connection itself keeps fluctuating, fix the local network first.
2. Verify the subscription configuration. After updating the subscription, confirm that the node address, port, VMess or VLESS protocol, transport, and TLS parameters were loaded completely.
3. Run a ping screen. Look for clearly high latency or continuous packet loss. If a node does not respond to ICMP, keep it for now and continue with a real connection test.
4. Run a real connection test. In v2rayN, select a candidate server and use the context menu to choose “Test Server Real Connection Latency.” Test each node 3 times. Discard the first result if its cache state differs, then compare the last two or use the median of all three.
5. Open the target web page manually. Switch to the candidate node, establish a fresh connection, and visit the site you actually plan to use. Confirm that routing rules have not sent the test traffic directly.
6. Test downloads last. Compare throughput across 2 to 3 candidates using the same HTTPS file, duration, and single-connection conditions.
7. Retest at different times. Record one round during the day and another at night. If speed drops from 10 MiB/s to 2 MiB/s at night while the direct connection remains stable, node load or the cross-network route deserves closer attention.

When testing split routing, watch for existing connections. After rules change, the browser may keep reusing an established connection, so the new rules may not appear immediately. Close the relevant page and wait for the connection to be released before testing again. If needed, restart the client core and check the logs to confirm whether the target domain matched a proxy outbound or a direct outbound.

Common Misreadings and Troubleshooting Answers

Latency lists are useful for narrowing the field, not for replacing real-world use. A single test may encounter cached DNS results, a temporarily busy server, or rate limiting at the test target. Reliable conclusions require the same environment, repeated tests, and validation against the actual target.

Choose by task: for web browsing and remote interaction, favor a node with stable real connection latency and low variation across repeated tests. For large-file tasks, favor a node whose sustained speed is close to the direct baseline. If both are unstable, troubleshoot the local network and split-routing rules before judging the subscription nodes.