To check whether a webpage loads, start with a real request sent through the proxy. To see how fast a large file downloads, measure sustained throughput. ICMP ping and TCP handshakes cover only part of the path. This guide is for users comparing results in v2rayN or v2rayNG. It explains what each test includes, what timeouts mean, and how to make a fair comparison using the same target, network, and repeated samples.
What each test actually measures
Latency is the time it takes to complete an action; speed is the amount of data transferred per unit of time. The millisecond figure in a client’s server list isn’t an inherent property of a node. Change the test target, DNS result, or connection reuse state, and the result may change. Before comparing numbers, check what the test button actually does—not just the column labeled “latency.”
| Test | What it mainly measures | What it can’t confirm on its own |
|---|---|---|
| ICMP ping | ICMP echo round-trip time to the target host | Whether the proxy port is available or protocol authentication succeeds |
| TCP handshake | Time to establish a TCP connection to a specified IP address and port | Whether TLS, VMess, or VLESS is configured correctly |
| Real connection latency | Time for a request to a test URL through the proxy; exact timing depends on the implementation | Whether every website is reachable or sustained download speeds are high |
| Download speed test | Effective throughput while receiving data over the specified route | Whether the first response arrives quickly or interactive use feels responsive |
For example, a node might complete a TCP handshake in 45 ms, while a real connection request takes 260 ms. That’s not a contradiction. The latter may also include the proxy protocol handshake, a connection from the server to the target site, the site’s TLS handshake, and time waiting for a response. The measurements end at different points, so subtracting one from the other doesn’t give you the “encryption overhead.”
ICMP ping and TCP handshakes: only part of the path
The system ping command usually sends ICMP echo requests. Setting an HTTP or SOCKS proxy doesn’t automatically route them through that proxy. Pinging a node’s domain mainly checks whether your local network can reach the IP address it resolves to. If the domain points to an intermediate server, the result reflects that entry point—not the full path from the final exit to the target website.
- Ping times out, but the proxy works: The host or a device along the route may not respond to ICMP. Test the actual service port, then send a request through the proxy.
- Ping is low, but webpages are slow: A nearby entry point doesn’t guarantee a fast relay route, plenty of exit bandwidth, or a quick response from the target site.
- TCP handshake succeeds, but the real connection fails: A service is responding on the port, but the UUID, TLS server name, transport path, or protocol parameters may still be wrong.
Test the actual port in the node configuration. If the node uses port 443, test port 443 at that address; don’t substitute port 80 on the same host. TCP probes are even less informative when the configuration uses a non-TCP transport. Even when the remote port is correct, a completed handshake confirms only TCP connectivity—not that the application accepts the proxy configuration.
Real connection latency: request a specific URL through the proxy
A real connection test typically has the client route a request to an HTTP or HTTPS test URL through the node. This is closer to loading a webpage than simply checking a port, but the start and end points of the timer depend on the client and core implementation. Some stop timing at the response headers; connection reuse can also affect the result. Results from different clients aren’t necessarily measured on the same basis.
For an HTTPS target, the process may involve two TLS connections for different purposes: one securing the node’s own transport, and another for the client’s HTTPS connection to the target website. VMess and VLESS are proxy protocols; check the node configuration to see whether TLS is used and which transport is configured. The protocol name alone won’t tell you how long the test takes.
Choose a small, reliable HTTPS endpoint with a predictable status code as your test URL. A timeout doesn’t always mean the node is unusable: the target site may reject a particular exit, DNS resolution may fail, or the test implementation may not accept the status returned. Verify with a separate target, then check the logs for connection, TLS, and response errors.
Parameters for comparing real connection tests
- Target protocol
- HTTPS; record the full URL
- Target port
- Usually 443; use the port in the URL
- Number of runs
- Test the same node 5 times in a row
- Record
- Median, failures, and test time
These are suggested controls for a comparison—not client defaults.
Parameters for comparing download tests
- Test resource
- A large file at a fixed URL or a continuous data response
- Number of connections
- Test one connection first, then test multiple connections separately
- Test duration
- About 20 seconds per run; record the stable period
- Network conditions
- Use the same network connection and pause other downloads
Speed tests use data. Check your remaining allowance first on a mobile network.
Download speed: throughput and milliseconds measure different things
Download speed depends on your local connection, node limits, exit congestion, target server limits, and TCP congestion control. Low latency helps with connection setup and interactive use, but doesn’t guarantee ample bandwidth. A high-latency route can still deliver high throughput once the connection is stable. The first few seconds may be spent setting up the connection and growing the congestion window, so don’t judge a test by its brief peak speed.
The lowercase b in Mbps means bits; the uppercase B in MB/s means bytes. 100 Mbps divided by 8 is 12.5 MB/s. That’s a theoretical conversion before protocol and network overhead—not a speed an app can be expected to sustain. MiB/s is a different unit, so keep the original units when recording results.
- Single-connection test: Better reflects a typical download, but is more affected by per-connection limits and round-trip latency.
- Multiple-connection test: More likely to use all available bandwidth, but may hide poor single-connection performance. Don’t rank it directly against a single-connection result.
- Webpages get noticeably slower during the test: The connection may be saturated and queues may be building up. Stop the test and measure latency again to compare idle and loaded latency.
Comparing v2rayN and v2rayNG under the same conditions
Client menus can change between versions and interface updates. In desktop v2rayN, select a node in the server list, then look for “Test server real connection latency” in the right-click menu. Before testing multiple nodes, try one and check the target URL and logs. In v2rayNG for Android, look for “Test real connection for all configurations” in the top-right menu. If the wording differs in your version, choose the real connection test—not a TCP test, which doesn’t make a full request.
- Record your setup: Note the client version, core version, network connection, and time. Tests over Wi-Fi and a mobile network aren’t a like-for-like comparison.
- Use the same test target: Check the URL in the test address settings available in your version. If you can’t find the setting, at least use the same client and test function for both runs.
- Remove competing traffic: Pause sync, system updates, and other downloads. Test nodes one at a time to avoid competing for local bandwidth or server resources.
- Repeat tests and keep failures: Run each node’s test 5 times. Don’t record a timeout as 0 ms or simply delete it from your results.
- Verify with real apps: Select a node, visit a website you actually use, then test a file download separately. A client’s built-in test may use a separate temporary inbound connection, which may not match the system proxy or per-app proxy route.
For a manual check, if your local setup has an HTTP-capable mixed inbound listening on port 10808, you can explicitly route a command-line request through it. This port is only an example; use the client’s current listening port. If you only have a SOCKS inbound, you can’t use HTTP proxy options as-is. The command below requests this site’s HTTPS page to check the route; it isn’t a standardized speed-test target.
curl --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --output /dev/null --silent --show-error --write-out "HTTP=%{http_code} TTFB=%{time_starttransfer}s TOTAL=%{time_total}s\n" https://v2ray-best.com/This syntax works in Linux or macOS terminals. On Windows, use curl.exe and replace /dev/null with NUL. TTFB is the cumulative time from the start of the request until the first byte arrives; TOTAL is the time until the request finishes. These timing boundaries may differ from the client’s real connection test. And the time to connect to a local proxy port is not the TCP latency to the remote node.
How to read latency results
Check the success rate first, then the median, and finally the variability. Here’s an example to explain the numbers; it isn’t a measurement of any node. Five tests to the same target return 180, 190, 185, and 920 ms, plus one timeout. The median of the successful samples is 187.5 ms, but the result must also include 4 successes and 1 failure. Reporting only “about 188 ms” would hide an availability problem.
| Result pattern | Likely causes | Next step |
|---|---|---|
| Fast TCP, real connection times out | Protocol settings, target site, DNS, or exit connection issue | Try a different test target and check the core logs |
| Stable real connection, slow download | Bandwidth, single-connection limits, or target resource limits | Use the same resource and compare one connection with multiple connections |
| Fast when idle, high latency during downloads | Saturated bandwidth or queues building up on the route | Pause downloads and test again; then try limiting the download rate |
| Test succeeds, but an app can’t open a site | The app isn’t using the proxy, uses different routing, or faces a site-specific restriction | Check the app’s proxy entry point and actual outbound logs |
Keep the same conditions when testing at different times, too. Evening congestion can make a bigger difference than the gap between two nodes tested in the morning. For video or large downloads, prioritize a reliable success rate and enough sustained throughput. For browsing and remote interaction, focus more on request latency and consistency. No single number covers every use case.
FAQ: low latency, timeouts, and routing
Ping fails. Should I keep testing?
Yes. First check the actual service port in the node configuration, then run a real connection test. If it succeeds, the lack of an ICMP response hasn’t prevented the proxy request. Next, check real webpages and downloads; there’s no need to change protocol settings just to get a ping response.
Real connection latency is only 100 ms. Why do webpages still take seconds to load?
The test may request just one small resource, while a webpage can load many domains and assets. Stop downloads, then use the browser’s Network panel in developer tools to find slow requests. Next, check the route and DNS resolution for the affected domain. A fast test URL doesn’t represent every domain a page loads.
v2rayNG test succeeds, but a specific app isn’t using the proxy?
Check that the system has granted VPN connection permission. In v2rayNG Settings, open the per-app proxy options and confirm whether selected apps are being proxied or bypassed. Save your changes, restart the service if prompted, then reopen the app and check the connection logs. A successful built-in test doesn’t verify the app’s route.
Latency changed after updating the subscription. Did the update reset routing?
First check whether the node address, port, or transport settings changed with the subscription, then confirm which node is selected. Subscription updates mainly refresh server configurations and usually don’t rewrite local routing rules. Even with the same node name, DNS resolution, exit load, and test time can all affect results.
Use a consistent order when choosing a node: confirm that proxy requests succeed, compare repeated latency samples and failures, measure sustained throughput, then test the apps you actually use. ICMP and TCP tests help narrow down issues; real connection tests check the request path; download tests measure bandwidth. Keeping those boundaries in mind explains why the numbers differ.