Latency Tests Explained

One node might show a 38 ms ping, 112 ms real connection latency, and download speeds of 92 Mbps; another might have an 80 ms ping yet load web pages faster. The tests are not failing—they measure different paths. Results only become meaningful when you know what traffic each test sends and which protocol stages it passes through.

What the three tests actually measure

ICMP ping sends an echo request to the target address and records the round-trip time. It usually travels only across your local network, the carrier route, and the destination host. It does not perform VMess or VLESS authentication or establish a WebSocket, gRPC, TLS, or REALITY session. Because servers may limit ICMP responses, a ping timeout does not prove that the proxy port is unavailable.

A real connection latency test sends an actual request through the client's current outbound configuration. It includes at least a TCP connection to the server port; with TLS, it also includes the secure handshake, and with protocols such as VMess and VLESS, proxy session establishment. Some clients then request a specified HTTP test URL and report the time until the response headers or first data arrives.

A download speed test keeps the connection open while transferring a sufficiently large amount of data. It measures how many bytes can be delivered per unit of time, mainly reflecting link bandwidth, server egress capacity, congestion control, concurrent connections, and file size. A node can take longer to respond initially yet sustain high throughput once connected.

• To check whether the route is reachable: use ping and record the average, maximum, and packet-loss rate.
• To check web responsiveness: use a real connection latency test and run at least 3 consecutive tests.
• To check sustained transfer capacity: use a download speed test lasting at least 10 seconds.

Why the three results often disagree

The first reason is that the targets differ. The address measured by ping may be the server's IP, while the real connection test accesses an external HTTP site and the download test connects to yet another speed-test server. The latter two also include the route from the proxy server to the test target. When the targets differ, the numbers cannot be ranked directly in a single list.

The second reason is protocol overhead. ICMP packets are small and contain no application-layer handshake. VLESS over TCP with REALITY and VMess over WebSocket with TLS perform different numbers of round trips. If the physical round-trip time is 60 ms, one additional serial handshake can add nearly another round trip; a cache miss during DNS resolution adds more waiting.

The third reason is that networks may treat different traffic differently. Some hosts prioritize normal application connections while limiting ICMP; the reverse can also happen when the path to the proxy port is congested. Brief wireless interference can trigger retransmissions, sending one real connection test from 90 ms to 300 ms before the next returns to normal.

Build a repeatable latency testing method

Node comparisons require controlled variables. After a subscription update, the same region may contain different servers, transport protocols, and entry ports. If one side uses VLESS over TCP and the other uses VMess over WebSocket, the results combine route and protocol differences, making the true bottleneck impossible to identify.

1. Keep the local environment consistent. Close bandwidth-heavy downloads and prefer a wired connection; if Wi-Fi is the only option, keep the device position and frequency band unchanged.
2. Keep the test targets consistent. Use the same HTTP target for every real connection test in a round, and the same file and duration for every download test.
3. Take multiple samples. Test each node at least 5 times, discard the first result because DNS and connection warm-up may affect it, then review the median.
4. Record jitter and failures. Do not record only the lowest value. Results of 112, 118, 109, 460, and 115 ms show a clear spike, indicating lower stability than a node that consistently stays between 130 and 145 ms.
5. Retest at different times. Run one round around midday and another in the evening. Cross-region routes may lose bandwidth during peak hours, so a single morning result cannot represent the whole day.

On Windows, use ping -n 20 server-address to collect 20 ICMP results; on macOS and Linux, use ping -c 20 server-address. Recording the average round-trip time and packet-loss rate is enough—do not treat command-line ping as a proxy protocol test.

Node A
ICMP：38 / 40 / 39 / 41 / 38 ms
Real connection: 112 / 118 / 109 / 121 / 115 ms
15-second download: 89 / 92 / 90 Mbps

Node B
ICMP：61 / 63 / 60 / 62 / 61 ms
Real connection: 84 / 87 / 86 / 85 / 89 ms
15-second download: 54 / 57 / 55 Mbps

In this controlled sample, node A is better for sustained downloads, while node B is better for web browsing, terminal sessions, and frequent short requests. Sorting only by ping would select A; sorting only by download speed would also select A. For interactive use, however, B's real connection latency is about 27 ms lower, leading to a completely different choice.

How to test in v2rayN, v2rayNG, and v2flyNG

Menu names may change between releases, but the test entry can be identified by the type of traffic it generates. In v2rayN 7.x, select a configuration in the server list, then choose “Server” → “Test server real connection latency.” This uses the current configuration to establish an actual connection; it is not the basic ping or TCP probe shown in the list.

On Android, v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. After updating the subscription and selecting a node, open latency testing from the top-right menu. For batch tests, confirm that the test measures a real connection rather than only checking the server port. Connect once before testing so the local VPN takeover, DNS, and routing rules match everyday use.

If you are testing manually through a local proxy, first confirm the local listening port in v2rayN under “Settings” → “Parameter settings.” The common mixed proxy port is 10808, but after making changes, use the value in the current configuration. The test tool must explicitly use this proxy port; otherwise, the request may connect directly to the target and will not measure the node's real connection.

• After updating a subscription, first check whether the node address, port, protocol, or transport has changed.
• Do not switch the system proxy, TUN mode, or Wi-Fi network during batch testing.
• If every result is negative, times out, or stays fixed at the same value, first check whether the test address is reachable.
• When the log shows a connection refusal, check the server port first instead of continuing to use download speed as a diagnostic.

How to choose nodes and protocols using these metrics

For everyday browsing and interactive requests, choose a node with low real connection latency and little variation across consecutive tests. If two routes measure 95 ms and 110 ms, a 15 ms gap is usually less important than stability. If the first produces a 500 ms spike once every five tests while the second stays between 105 and 120 ms, the second is the better primary node.

Downloads, video buffering, and large-file synchronization depend more on sustained throughput. Compare the average speed over a 10- to 30-second interval and watch for mid-test slowdowns. A node that briefly shows 150 Mbps before settling at 35 Mbps has effective capacity close to 35 Mbps, not the peak number.

VMess

Includes authentication and encryption processing and is commonly combined with transports such as TCP, WebSocket, and TLS. Latency depends on the complete combination, not the protocol name alone.

VLESS

A lightweight authentication protocol commonly combined with TLS, REALITY, TCP, or gRPC. Handshake count, server distance, and egress quality all affect real connection latency.

TUN

Takes over traffic through a virtual network interface. Once enabled, test requests also pass through system routing and DNS settings, making the result closer to an everyday full-tunnel environment.

Routing rules

Choose a direct or proxy egress based on the domain, IP, or process. If the speed-test target is routed directly, the client's displayed data does not represent the proxy node.

When comparing VMess and VLESS, use the same server, entry network, and broadly similar transport conditions whenever possible. If the VLESS node is in a nearby region while the VMess node uses a much longer route, the latency difference mainly reflects physical distance. Choose a protocol based on server support, transport security, and client compatibility—not a single lowest-latency result.

Common latency testing questions

When results look abnormal, first distinguish between “the test did not use the proxy” and “the proxy used a different path.” The former usually involves the local port, system proxy, or routing rules; the latter requires checking DNS, server egress, and the test target. The questions below cover the most common operational mistakes.

Use each metric for its intended purpose: ICMP ping checks the basic route, real connection latency measures response across the complete proxy path, and download speed evaluates sustained transfer capacity. Once the test target, routing mode, and local network are consistent, the three values no longer contradict one another—they describe different aspects of the same node path.