TCPing checks the TCP handshake to the server port, real connection latency measures an actual request sent through the node, and a download test measures sustained throughput. For everyday browsing, first check that real connection requests succeed consistently; compare download speeds when transferring large files. This guide covers the steps in v2rayN and v2rayNG, plus how to troubleshoot low latency with pages that won't load.
What each test actually measures
Latency is the time from starting an operation to getting a result, not a fixed property of a connection. The test entry point, destination, and whether a connection is reused can all affect the result. Comparing millisecond values from different client interfaces may mean comparing different operations.
TCPing
Opens a TCP connection to the node server's address and port, mainly measuring the handshake time for that network segment. A successful handshake does not confirm proxy protocol authentication or access to the destination website.
Best for: Quickly ruling out nodes with unreachable ports or unusually slow handshakes
Real connection latency
RecommendedThe client sends a request to a test address through the node. This covers more steps, including establishing the proxy connection and making the destination request, but still depends on the test address and timeout settings.
Best for: Choosing a node for everyday browsing by first confirming that requests complete
Download speed test
Downloads a test file over time to measure how much data arrives. Results also depend on the file server, device performance, and other transfers running at the same time.
Best for: Comparing nodes for large downloads and sustained transfers
TCPing is not a universal latency test for every transport. If a node uses a non-TCP entry point, the handshake time to a TCP port cannot stand in for the node's actual connection time. A real connection test also represents just one request to the current test address: the result can change as the destination's DNS, routing, or response time changes.
Takeaway: Know what you're measuring before comparing results
Compare real connection latency only in the same client, to the same test address, and around the same time. Use TCPing as a reachability check, not as proof that a webpage will load.
Why is TCPing low but the page won't load?
For example, a TCPing result of 40 ms only means the TCP handshake to the server port was fast at that moment. The node's VMess or VLESS settings may still differ from the server's; even after the proxy connects, destination DNS resolution, routing rules, or the destination server itself can fail. If a page won't load, first determine whether the test-address request failed or only one particular website is affected.
These sample figures illustrate different units; they are not performance guarantees for any node. 40 ms and 240 ms are not contradictory: the first ends with the server-port handshake, while the second also involves the client, proxy route, and test destination. 5.8 MB/s is a transfer rate and cannot be converted into a webpage's time to first byte; 10808 is a local listening port, not a test result.
- First check whether the real connection test succeeds. If it fails, open the client logs and distinguish a connection timeout from an authentication error or a destination request error.
- Make sure the currently active node is the one you just tested, and check that the system proxy or app proxy points to the current client.
- Check whether routing rules send the destination domain through the proxy. A domain can fail at different points on direct and proxied routes.
- If only certain websites fail, check that domain's DNS results and the destination site's status. Don't replace an entire subscription based on a single TCPing result.
How to compare nodes in v2rayN and v2rayNG
Update the subscription and keep test conditions consistent. Stay on the same network if possible, and pause bandwidth-heavy downloads. Test each candidate group with the same test address and timeout settings. Menu labels can vary between versions, so follow the options shown in your current client.
Recommended approach: Check availability first, then test sustained transfers
Desktop: v2rayN
- Select the same group of nodes in the server list and run TCPing first to rule out unreachable ports.
- Then use the list's “Test server real connection latency” option and note both the success rate and latency in milliseconds.
- Set each candidate as the active node in turn, then verify it with an actual webpage request.
Android: v2rayNG
- Run a connection test or real connection test for candidate nodes in the configuration list, and note any failure messages.
- After enabling the selected configuration, make sure the system VPN connection is active.
- Visit a familiar page on the same network, then run download tests for nodes intended for heavier transfers.
Record results separately for each device. Don't directly rank milliseconds measured on a wired desktop network against those measured on an Android mobile network.
In v2rayN, the real connection test is usually labeled directly in the server list actions. In v2rayNG, the test entry and batch-test labels can change between versions; if you don't see the same wording, check the connection test options in the configuration list menu. In both clients, pay attention to the test address: a slow response can make every node appear slower.
Test each candidate node three times, with a short interval between runs, and record successes and the approximate range. For example, node A might return 180, 195, and 188 ms, while node B returns 90 ms, a timeout, and 310 ms. Looking only at B's best result misses a failure and substantial variation. For everyday browsing, favor nodes that complete requests consistently.
Takeaway: Consistent successful requests matter more than the lowest one-off latency
First rule out nodes that repeatedly time out on real connection tests, then compare latency among the stable candidates. Use download tests to make the final ranking only when sustained downloads are your main use case.
How to read download tests and when to run them again
Download speed and latency answer different questions. One route may transfer data faster over time even when real connection latency is similar; another may load small pages faster even when download speeds are close. For a useful download test, make sure the file is large enough and the transfer runs long enough. Don't judge the whole route by the initial speed spike.
| What you see | Check first | Next step |
|---|---|---|
| Low TCPing, real connection times out | Protocol settings, node logs, test address | Fix the failed request before comparing nodes |
| Stable real connection, slow download | Test file source, concurrent downloads, network congestion | Retest with the same file at different times |
| Fast download, slow webpages | Destination response, domain resolution, routing rules | Test familiar sites individually; don't use throughput as a substitute for response time |
The test address itself can affect the result. If the file server limits speed, the test measures the combination of the node and that file server—not the node's maximum capacity. Likewise, if routing rules send the test address directly, the download figure won't represent traffic through the proxy. Before testing, make sure traffic is actually going through the active node.
- When retesting, keep the network type, destination, and file size consistent, and note the time of each test.
- Track MB/s and Mbps separately. As a rough decimal conversion, 1 MB/s is about 8 Mbps.
- Don't switch nodes before a download test finishes; the previous connection may continue using bandwidth.
How to interpret common results
If several nodes show low latency, first check which ones actually completed requests, then verify them with websites you use regularly. A single result is only a snapshot. Network changes, server load, and destination-site conditions can all change the ranking on the next test.
TCPing is 30 ms, but the real connection test times out?
Check the current node's address, port, and protocol settings, then review the client logs. A reachable TCP port rules out only some network issues; it doesn't confirm that a VMess or VLESS proxy request succeeded.
The real connection test succeeds, so why won't the browser load pages?
Make sure the browser is actually using the system proxy or the correct manual proxy port. Then check the routing rules for the destination domain; a successful test address doesn't mean every domain uses the same route.
Why do v2rayN and v2rayNG show very different latency?
First confirm both clients are using the same node, test address, and network type. Then check their core and routing settings. If the conditions differ, don't compare device results by milliseconds alone.
Why is the download test fast in the first second, then slower?
Record the average speed over the full transfer, then retest with the same file at a different time. The initial spike may be affected by caching or temporarily available bandwidth, so don't use it alone to choose a node.
Should I always choose the node with the lowest latency?
For everyday browsing, rule out nodes with failed or highly variable requests first, then compare real connection latency among the stable candidates. For large transfers, also run download tests and base your choice on results from the times you actually use the connection.
Choose a node based on how you'll use it: for browsing, check that requests complete consistently; for sustained transfers, compare speeds over time; and for diagnosing entry-point issues, start with TCPing. Keeping the test time, network type, and failure messages is more useful for troubleshooting later than saving only the lowest latency figure.