TCPing checks whether a TCP connection can be established to a node’s entry point. Real connection latency checks whether the proxy route can reach a specified test target. Download speed tests measure sustained throughput. For v2rayN, v2rayNG, and v2flyNG users, this guide covers what each test measures, where to find it, how to record results, and how to troubleshoot—then lays out a practical workflow: check connectivity, compare response times, and test throughput last.
What each speed test measures
The millisecond values in a client’s server list are comparable only when the same test method is used. A successful TCP connection does not mean VMess or VLESS authentication succeeded. A quick response from a test page does not mean large files will transfer quickly. Check which test the menu item runs before comparing the results.
TCPing: Check the entry point
TCPing attempts a TCP connection to the node’s address and port, usually measuring how long it takes to establish. Unlike the ICMP packets used by system ping, it does not fully verify the proxy protocol, account settings, or node exit route.
Use it to: Rule out configurations whose entry-point ports cannot be reached and narrow down the candidates for further testing.
Real connection latency: Check a proxy request
RecommendedThe client uses the tested configuration and core to send a request to a specified target. The time may include connecting to the node, the proxy handshake, target name resolution, and the target’s response. Exactly what gets timed depends on the client, so this value is not simply network round-trip time.
Use it to: Check nodes for everyday web browsing and confirm that the protocol settings and request route work.
Download speed: Check sustained throughput
The client downloads test data through the selected configuration and calculates speed from the data transferred and elapsed time. Results depend on the download source, network congestion, server limits, test duration, and device performance.
Use it to: Compare large-file transfer performance across a small number of working nodes.
For example, if a node uses TCP port 443, a successful TCPing only means a connection to that address on port 443 could be established at that moment. Even with an incorrect UUID or mismatched WebSocket path, the entry point may still return a very low latency value. For configurations that do not use TCP transport, a failed TCPing alone does not prove the whole configuration is unusable.
Running speed tests in v2rayN and Android clients
Update your subscription first, then test a small number of configurations. Menu wording may vary between versions and interfaces; the steps below describe common Chinese-language interfaces. Look for the corresponding actions, such as “Tcping,” “Real Connection Latency,” or “Speed.” Not every client offers the same set of tests.
- v2rayN: Select configurations. Open the server list and hold Ctrl while selecting 3–5 nodes. Right-click and run “Test server latency (Tcping)” first, then check the results. Run “Test server real connection latency” on the same nodes and wait for the whole test to finish.
- v2rayN: Compare speeds. Keep 2–3 candidates that passed the real connection test, then right-click and run “Test server speed.” Avoid other bandwidth-heavy tasks during the test, and don’t run download tests on hundreds of nodes at once.
- v2rayN: Keep test settings consistent. Open “Settings” → “Parameter settings” and check the latency test address, download test address, and timeout options available in your version. If an option isn’t available, note the version’s default behavior; there’s no need to change the node protocol just to find a setting.
- v2rayNG: Test real connections in bulk. Open the menu in the top-right corner of the configuration list and select “Test real connection for all configurations.” To check the current node, select the configuration, start the service, grant Android’s VPN permission, and then tap the connection status area at the bottom to test the active connection.
- v2flyNG: Use the options available in your version. Look for the connection test in the configuration list menu and note which test it runs. Make sure the configuration is supported by its V2Fly core. For VLESS + REALITY configurations that rely on Xray features, use a client and core that support them.
Compare latency and variation under the same conditions
The figures below are hypothetical examples to explain how to compare results, not rankings from real nodes. Assume node A is tested five times on the same device, Wi-Fi network, and test target. TCPing results are 31, 34, 35, 37, and 52 ms; real connection results are 168, 175, 182, 194, and 620 ms.
Sort the five results from lowest to highest; the third value is the median. It’s a better indicator of a typical result in this small sample than the single lowest reading, but five measurements aren’t enough to describe long-term stability. The 620 ms result suggests a significant spike in this round. Test again rather than concluding that the node is consistently unstable.
| Metric | Node A | Node B | How to interpret |
|---|---|---|---|
| TCPing median | 35 ms | 68 ms | Compares entry-point connection time only |
| Real connection median | 182 ms | 146 ms | B responded faster to this test target |
| Successful real connection tests | 5 / 5 | 5 / 5 | All tests in this round completed |
| Average download speed | 8 MB/s | 5 MB/s | A had higher throughput to this download source |
Takeaway: Keep both candidates for different tasks
In this hypothetical example, try node B first for web browsing and node A for large file transfers. Test each with the sites you actually use, then retest during your usual hours. Don’t automatically make the node with the lowest entry-point latency your first choice for everything.
Record timeouts separately—for example, “4 successful, 1 timed out.” Don’t count a timeout as 0 ms or hide failures by averaging only successful tests. An application-level timeout may occur during name resolution, the handshake, or the target’s response; it cannot be directly converted into an underlying network packet-loss rate.
Download speed units, test duration, and data usage
Internet plans are usually advertised in Mbps, while clients often show MB/s or MiB/s. Using decimal units, 8 MB/s is about 64 Mbps; 8 MiB/s is about 67.1 Mbps. Check the units before comparing tools—a matching number doesn’t mean matching speeds.
- Use the same test source. The same node can produce very different results with different download sources. Source concurrency limits, cached content, and the route from the node’s exit to the source all affect throughput.
- Use the same test duration. If the tool allows it, measure for 10–15 seconds and record both the average and how the speed holds up in the second half. A peak at startup can reflect a brief cache burst or temporary bandwidth spike, not sustained speed.
- Estimate data usage. At a sustained 8 MB/s, a 15-second test transfers about 120 MB of content per node. Testing five nodes in a row uses about 600 MB, plus any protocol overhead.
- Limit concurrency. Testing one node at a time makes it easier to compare individual performance. Simultaneous downloads compete for your local access bandwidth, so the results reflect shared bandwidth under contention.
Low latency but web pages won’t load: Troubleshoot by failure point
Save the logs from the failed attempt before changing anything, then change one setting and retry. Changing DNS, routing mode, transport protocol, and test target all at once makes it hard to tell what fixed—or caused—the problem. Logs may contain server addresses, account identifiers, or subscription details; redact those fields before sharing.
TCPing is only 30 ms, but real connection tests keep timing out. Why?
Open the node’s edit screen and compare its address, port, UUID, transport type, and security settings with the provider’s details. For WebSocket, check the path and Host; for TLS, check the server name. A reachable entry point doesn’t mean these settings are correct. Don’t disable certificate verification to hide a configuration error.
The real connection test passed, so why won’t my browser load anything?
First confirm that the tested node is the one currently active. On desktop, check that the system proxy or TUN is enabled as expected and that the browser isn’t using a separate proxy. On Android, confirm the VPN service is running and that per-app rules haven’t excluded the app you’re testing. Then visit the actual target and check the logs for outbound and error details.
Every node times out. Has my subscription stopped working?
First check that your local network works, then verify that the core starts normally and review the logs for errors. If every node fails only against the same test target, try another known-good target from the speed test options under “Settings” → “Parameter settings.” Test target problems and account issues need to be checked separately.
Speed tests are fast, but downloads crawl at night. Should I change protocols?
Retest in the evening with the same download source and test duration, and pause other downloads. If several nodes slow down at once, check your local network and shared bandwidth. If only one node slows down, compare it with the others. Switching between VMess and VLESS won’t automatically fix a congested exit route or server-side throttling.
If only some domains fail, check DNS and routing as well. A test tool may create a separate test outbound for each candidate configuration, while browser traffic still follows the current routing rules. The two may not take exactly the same path. See the routing and split tunneling guide and the DNS settings guide to check where the request is actually going.
Build a repeatable node selection workflow
Separate initial screening from routine retesting. The goal of initial screening is to find a small number of working configurations; routine retesting confirms they’re still suitable during the times you actually use them. Don’t repeatedly run high-traffic tests on your entire subscription just to chase a one-millisecond improvement.
Test plan: Initial screening and routine retesting
After importing for the first time
- Update the subscription and check that configuration fields are complete.
- Use TCPing to screen TCP entry points where applicable.
- Select 3–5 candidates and run five real connection tests on each.
- Run a short download test, one node at a time, on two of them.
Before everyday use
- Keep the device, network, and test target consistent.
- Record successful test counts, medians, and significant variations.
- Retest the same nodes during your usual evening hours.
- Open the actual sites or files you need to confirm they work.
Confirm that requests succeed before comparing response times. Add a download test only when you need to measure sustained transfers.
Record the test time, network connection, client, core, test type, and target. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core; also note the core selected in v2rayN. When comparing protocols or cores, changes to the node exit, target, or test time mean you can’t attribute every difference to the core.
- Check the success rate first. A node that frequently fails is not a good primary choice, even if it occasionally reports low latency.
- Then compare response times and variation. Use multiple real connection tests to choose candidates that suit the destinations you actually access.
- Finally, compare throughput. Test sustained speed based on your download needs, and keep a verified backup configuration.