V2Ray Latency Tests Explained: TCPing, Real Connection Latency & Download Speed

What the three V2Ray speed tests actually measure

v2rayN is a desktop GUI client, while v2rayNG is an Android client that uses the Xray core. The client runs the test, but the connection also depends on the core, node configuration, and target website. Menu labels, timing boundaries, and timeout thresholds can vary by version. Compare results within the same column; don’t use numbers from different clients to rank nodes directly.

“Recommended” means real connection latency is the best starting point for routine node selection—not that it replaces every other test. Video streaming depends more on sustained throughput and consistency; interactive tasks depend more on response time. Real apps may also use different routes from the test request.

Why TCPing can be fast while a real connection still times out

TCPing isn’t the same as a traditional ICMP ping. If a node uses TCP port 443, a successful TCPing usually means only that your device could establish a TCP connection to that address and port. The port might lead to a proxy server, a forwarding service, or another listener. You need to complete the protocol exchange to confirm the configuration works.

1. Check the server port. Test the port listed in your subscription, not a port such as 443 based on assumption. If the port changed but your subscription hasn’t been updated, results from the old port aren’t useful.
2. Check the protocol and security settings. Incorrect VLESS user IDs, TLS server names, or REALITY public keys and short IDs may not become apparent until after the TCP connection is established.
3. Check transport settings. If the WebSocket path or HTTP host doesn’t match the server configuration, the underlying port may accept connections while subsequent proxy requests fail.
4. Make sure the test method applies. A transport that primarily uses UDP can’t be verified just by probing a TCP port. A failed TCPing doesn’t mean every type of proxy transport is down.

TCPing also isn’t a packet-loss test. Five successful connection attempts only show that those five probes succeeded; they don’t prove the route has zero packet loss. When retesting, record both failures and the distribution of successful results.

What real connection latency measures—and why the numbers vary

A real connection test uses the proxy configuration to access a test URL. For an HTTPS target, a request may involve local or remote DNS, connecting to the node, proxy authentication, the target’s TLS handshake, and waiting for a response. Which steps are included depends on the client and whether it reuses a connection or has a cached DNS result.

So this isn’t the “pure network round-trip time between the node and the user,” and it’s not the time it takes to load a complete web page. A typical small-response test page returns very little data; real pages also request scripts, images, and other domains, so the browsing experience can differ.

• Use a fixed test target. Use the same URL when comparing nodes. If the test address changes region, CDN, or response behavior, the results no longer reflect node differences alone.
• Check that the response is expected. Some probes check the status code or response content. Redirects, verification pages, and rate limits on the target site can all cause a test to fail.
• Keep both the first and later results. The first connection may take longer; DNS caching, session resumption, or connection reuse can speed up subsequent attempts. Don’t keep only the fastest result.
• Check the test route. A real connection test is intended to use the selected node, but probe settings and DNS handling can vary by version. Check the logs; opening the test page directly in a browser isn’t a substitute for testing through the proxy.

How to convert download speeds between MB/s and Mbps

Latency is measured in milliseconds, while throughput is usually shown in MB/s or Mbps. There’s no direct conversion between them. A node with 180 ms latency can sustain 12 MB/s, while one at 60 ms may deliver only 2 MB/s. The first may not suit low-latency interactions, and the second may not be ideal for large downloads.

The figures below are unit-conversion examples, not measurements from this site or a promise about any route. Using decimal units, 1 byte equals 8 bits. If the interface explicitly reports MiB/s, calculate using binary units instead.

A connection rated at 100 Mbps theoretically corresponds to 12.5 MB/s. In practice, protocol overhead and network fluctuations reduce the result. The test server—not the node—may also be the bottleneck. Don’t compare single-connection and multi-connection speed tests as if they were the same.

• Pause background downloads, system updates, and cloud sync to avoid sharing local bandwidth.
• Test candidate nodes one at a time; don’t run multiple download tests that compete for bandwidth.
• Check your data allowance before testing. Long tests use real data, so take extra care on Android over a mobile connection.
• Look at the sustained speed, not just the initial peak. Then verify performance with the service you actually plan to use.

How to retest in v2rayN and v2rayNG

First note the client and core versions, then review the test settings. In v2rayN, look under Settings → Parameter Settings for the speed-test options available in your version, and check the test address and timeout. Menu sections vary by version. Don’t keep changing these settings just to get a lower number.

For example, five real connection results might be 142, 149, 151, 158, and 410 ms. The median is 151 ms, but the 410 ms spike is still worth noting. If two of the five attempts time out, don’t average only the three that succeeded and call the connection stable. After switching subscription nodes, confirm that the active node actually changed; otherwise, your browser might still be reusing a connection to the previous node.

Speed test passes but web pages won’t load: Trace the route

The client’s built-in test and your browser’s connection are separate paths that need to be checked independently. A built-in test may use a dedicated test route, while the browser also relies on the system proxy, app-specific proxy settings, or TUN routing. System proxy settings determine how traffic enters the client; routing rules determine which exit it uses.

1. Check the local proxy. For example, if the configured HTTP proxy is 127.0.0.1:10809, the app must use that actual listening address. Port 10809 is only an example, not a default for every version. Don’t enter a SOCKS port as an HTTP port.
2. Check the routing rules. A test address going through the proxy doesn’t mean your app’s domain does too. Check whether the domain matches a direct-connection rule, and whether the target app is excluded by per-app settings on Android.
3. Check DNS. Both the node’s server address and the app’s domain need to be resolved. Compare DNS errors and connection targets in the logs; a domain resolving in your browser doesn’t rule out every DNS issue.
4. Check the remote server and target. Reaching a small-response test site doesn’t guarantee access to every website. If only one service fails, check its regional or exit-node restrictions and the specific error message.

Change one setting at a time while troubleshooting, and save the results before and after. Resetting the node, routing, DNS, and system proxy all at once may restore access temporarily, but it makes the cause hard to identify.

Common questions about latency and speed tests