TCPing is useful for checking whether a server port is reachable; proxy response time tests the full proxy path; and download tests measure sustained throughput. If you’ve imported nodes but aren’t sure which result to sort by, start by understanding what each test covers. Then compare nodes using the same target and network, with repeated measurements, and find out why a node can show low latency yet fail to load web pages.
1. Each Test Measures a Different Part of the Connection
v2rayNG uses the Xray core to handle proxy connections, but TCPing in the node list usually only attempts a TCP connection to the configured server address and port. It is not an ICMP ping and does not authenticate with VMess or VLESS. If the server address is a domain name, it must be resolved first; whether DNS lookup time is included in the displayed result depends on the implementation. So don’t treat the number as a pure network round-trip time.
TCPing: Server Port Reachability
Checks whether your phone can establish a TCP connection to the node’s port. If a node uses TCP port 443 and the result is 45 ms, that only tells you the port responded quickly. It does not confirm that the UUID, TLS serverName, or Reality settings are correct.
Best for: Quickly checking multiple nodes and confirming that their addresses and ports are reachable.
Proxy Response Time: Requesting a Test URL Through the Proxy
RecommendedThe client sends a request to a test URL through the selected configuration. Timing may include the proxy handshake, target domain lookup, TLS connection, and HTTP response. This is closer to loading a web page than a port check, but the result applies only to that test target.
Best for: Checking that a configuration works and choosing a node for everyday browsing.
Download Speed: Sustained Throughput
Data is downloaded continuously through the proxy, and the amount received per unit of time is measured. Results depend on node throttling, congestion, the target server’s bandwidth, and test duration; they cannot be inferred from a single latency test.
Best for: Video streaming, large downloads, and checking throughput during peak evening hours.
Start with proxy response time, but don’t automatically choose the node with the lowest millisecond reading. The test URL and the sites you actually use may be in different regions. A node may reach the test site quickly but take a less direct route to a site you need. For traffic that mainly uses UDP, TCPing and a standard HTTPS download also cannot verify UDP forwarding.
2. Test Nodes in a Consistent Order in v2rayNG
Keep your existing configuration unchanged while testing. Don’t modify routing, DNS, or transport settings midway through a comparison. Menu labels can vary slightly between v2rayNG versions; the steps below refer to the common TCPing and real-connection test options. If you can’t find an exact label, look for the equivalent function. A connection test at the bottom of the list may test only the active connection, not every node.
- Pause other network activity. Stop app updates, cloud sync, and video downloads. Use the same Wi-Fi network or mobile data connection throughout, and note the time and connection type. Don’t switch networks between test rounds.
- Check ports in bulk. Tap “⋮” in the top-right corner of the main screen and select “TCPing all configurations” or the equivalent TCPing option. Mark the nodes that fail and keep the ones that pass; don’t delete configurations yet.
- Check proxy connections in bulk. From the same menu, select “Test real connection for all configurations” or the equivalent option. If your version has a “Test URL” or “Connection test URL” setting, note the current value and keep it unchanged during the comparison.
- Recheck the active connection. Select a candidate node, tap the connect button in the bottom-right corner, and approve the Android VPN permission prompt. If the interface provides a connection test at the bottom of the screen, run it to confirm that the active configuration can still complete a request.
- Test throughput only for shortlisted nodes. Use a browser confirmed to be routing through the proxy to visit the same speed test page, or download the same test file from a server with enough bandwidth. Test one node at a time so they don’t compete for your local bandwidth.
Bulk real-connection tests and tests of the active connection may run differently, especially if the client starts a temporary test core. Record whether each result came from a “bulk test” or an “active connection test,” and don’t combine readings from different test methods in one sample set.
3. Use Repeat Measurements to Compare Latency and Throughput
The readings below are illustrative examples, not measurements taken by this site or a speed guarantee for any service. Assume all three nodes use the same test URL, download file, and network connection; each node’s real-connection test runs three times, and download speed is averaged over the stable portion of the transfer.
| Candidate node | TCPing | Three real-connection readings | Average download speed | Assessment |
|---|---|---|---|---|
| A | 38 ms | 310 / 920 / 460 ms | 1.2 MB/s | Fast port response, but full requests vary significantly |
| B | 82 ms | 205 / 218 / 211 ms | 8.0 MB/s | Consistent requests; a good primary candidate |
| C | 65 ms | Timed out all three times | Not tested | Troubleshoot the configuration first; exclude from throughput comparisons |
Node A has the lowest TCPing result, but its median across three full requests is 460 ms. Node B’s median is 211 ms, and its three readings are close together. B is the more sensible choice to try first. Three measurements are enough for a quick screening, not for calculating a reliable packet loss rate—and a single timeout does not prove packet loss.
MB/s and Mbps differ by a factor of eight, while MiB/s uses a different byte measure. A speed test showing 64 Mbps and a download manager showing about 8 MB/s are usually consistent. A 15-second test averaging 8 MB/s uses about 120 MB of data, so keep mobile data limits in mind before running multiple tests.
Bottom line: Exclude repeated failures first, then compare median response time and stable download speed
Don’t choose A as your primary node just because it shows 38 ms. First investigate why C failed, then try A and B for a round of real-world use. If B remains stable, keep it as the primary node and use A as a backup.
4. Why Does TCPing Look Good While the Real-Connection Test Times Out?
A reachable port only confirms that the first part of the connection works. Proxy authentication failures, incorrect transport settings, or an unreachable test site from the node can all occur after the TCP connection is established. Check the following in order to avoid mistaking a configuration problem for insufficient server bandwidth.
“TCPing is only 40 ms. Why does the real-connection test keep timing out?”
Open the node’s edit screen and check the address, port, UUID, and transport settings. For VLESS + Reality, also verify the public key, shortId, and serverName; for WebSocket, check the path and Host. Then look for connection or handshake errors in “Logs” on the main screen. Don’t try to hide the problem by disabling certificate verification.
“The real-connection result is -1. Does that mean latency is too high?”
A negative value usually indicates a failure, not negative latency; check the message shown by your version. Retest the same node, then look in the logs for DNS resolution failures, connection timeouts, or TLS errors. If all nodes fail at once, check the test URL, local network, and system time first.
“The real-connection test looks good, but one website loads very slowly. Why?”
Use the same browser to test two different destinations and see whether the problem affects only one site. Then check whether that domain’s traffic is routed through the proxy and whether DNS returns a suitable address. A real-connection test checks only its test URL; it cannot confirm that every site resolves correctly or uses a good exit route.
“The download is fast for the first second, then keeps slowing down. Why?”
Run the test for at least 15 seconds and assess the stable portion, not the peak. Pause other transfers and retry the same file. If the speed still keeps dropping, compare another node. A short burst of bandwidth, server-side throttling, or congestion can all cause this pattern; one test round isn’t enough to identify the cause.
For configurations that mainly use UDP, a failed TCPing test alone does not mean the node is broken: the same address and port may not offer a TCP service at all. Check the node’s transport type first, then use a real-connection test supported by the client or verify it with your actual workload.
5. Choose Nodes Differently for Browsing and Downloads
Web pages usually involve many small requests, so connection setup time, DNS lookup time, and jitter matter more. Large downloads depend more on sustained throughput. Don’t use one “lowest latency first” ranking for every task, and don’t assume speed based on the protocol name alone.
Suggested Approach: Set Primary and Backup Nodes for Your Needs
Web browsing, messaging, and API requests
- First, confirm that the real-connection test succeeds three times in a row.
- Compare the median and check whether the highest reading is a clear outlier.
- Open the sites you use most and check both initial load time and subsequent requests.
- Keep a backup node with a different exit route in case a destination has problems.
Video streaming and large downloads
- Run a real-connection test first, then test sustained downloads.
- Compare average speed using the same file and test duration.
- Retest during your usual evening hours rather than relying only on off-peak results.
- Check for buffering or disconnections, not just peak speed.
Choose your primary node for the tasks you actually do and keep a backup for availability. Retest after switching networks instead of relying on an old ranking.
You can use the same testing order with the desktop client v2rayN, but test targets, concurrency, timeout thresholds, and timing boundaries may differ between clients. A 200 ms reading on a phone and 150 ms on a computer don’t necessarily mean the node used by the computer is faster. Standardize test conditions before comparing results.
6. Keep Speed Test Records You Can Review Later
A screenshot of a single green latency value won’t help explain why performance changed after switching networks. Your notes don’t need to be complicated, but should include the connection, time, test method, and target. The checklist below is enough for routine reviews and can help identify evening congestion or problems with a specific test target.
- Environment: Note whether you used Wi-Fi or mobile data, the date and time, and whether the phone was charging or had battery-saving restrictions enabled.
- Client: Record the actual version number from “About” and note whether you used v2rayNG or v2rayN. Establish a new baseline after upgrading.
- Test conditions: Record the test URL, download target, duration per run, and any changes to per-app proxy or routing mode.
- Results: Record TCPing, all three raw real-connection readings, the number of failures, and download speed during the stable portion. Use the same units throughout.
- Real-world checks: Note whether your usual websites load and videos play continuously before deciding to make a node your primary.
Use the same selection order every time: screen ports → verify the real connection → repeat measurements → test downloads if needed → check real-world use. This avoids unnecessary bulk downloads and helps distinguish configuration failures, test target issues, and insufficient throughput.
Install the Client and Make Your First Connection
Choose v2rayNG or v2rayN for your operating system. On first use, import a configuration and connect, then test your nodes in the order described in this guide.