Use TCPing to check the node’s entry point, real connection latency to verify the proxy route, and a download test to assess sustained throughput. This guide is for anyone seeing low latency but unable to load pages, or fast test results but sluggish everyday browsing. Compare results on the same network, to the same target, over several rounds—not just by picking the lowest number in the list.
1. What Each Test Measures: These Numbers Aren’t Interchangeable
Check the test name before comparing results. TCPing usually attempts a TCP connection to the node server’s port and measures how long it takes to connect; it is not traditional ICMP ping. Latency is measured in milliseconds (ms), and lower is generally better. Download tests commonly show MB/s, or megabytes per second, where higher is generally better.
Real connection latency measures an actual request sent through the node to a test URL. The timing can vary by client version, core, and test URL, including where the timer starts and stops. It may include proxy negotiation, the connection to the destination, the TLS handshake, and some wait time for a response, so it is not simply the server’s network round-trip time.
TCPing: Check the Entry Port
It answers one question: can this device connect to that address and port? It does not verify authentication for proxy protocols such as VMess or VLESS, or prove that the node can reach a website.
Best for: Quickly ruling out configurations that cannot reach the entry point, and checking the address, port, and local network.
Real Connection Latency: Check Whether the Proxy Works
RecommendedThe client uses the configuration to establish a proxy route, then requests a test URL. This is closer to loading a web page than a simple port check, but success only confirms that the test destination is reachable.
Best for: Choosing a node for everyday browsing and checking that its protocol settings and proxy exit work.
Download Speed Test: Check Sustained Throughput
The test continuously downloads data through the node. Results depend on your local bandwidth, node load, exit route, and download server; they do not directly predict how quickly web pages will load.
Best for: Streaming, large downloads, and comparing sustained throughput under the same conditions.
2. TCPing Is Low but Websites Won’t Load: Troubleshoot the Route Step by Step
Don’t keep switching protocols just yet. A successful TCPing only means the TCP connection to the entry port was established. If the node uses a reverse proxy or relay server, the test may stop at that entry point; proxy authentication, server forwarding, and the destination website remain untested.
| What you see | Check first | What to try next |
|---|---|---|
| TCPing succeeds, but the real connection test fails | Protocol settings, authentication, transport, and security | Check the address, port, and user ID in your subscription, along with TLS, SNI, and the transport path. A reachable entry point does not mean the configuration is correct. |
| The real connection test succeeds, but some domains fail | DNS, routing, and destination restrictions | Compare the routes for the test domain and the failing domain. Check whether failed requests are bypassing the proxy. |
| The client test succeeds, but the browser can’t connect | System proxy settings or app coverage | Make sure the browser uses the client’s local listening port. On Android, confirm the VPN is connected and the target app is included in the proxy scope. |
| Switching networks fixes the problem | Current network and route to the entry point | Record Wi-Fi and mobile network results separately; don’t rank results from different networks together. |
TLS is an encryption protocol that protects connections. SNI is the hostname sent during the TLS handshake to identify the destination. Even if the entry port is reachable, a mismatched SNI, certificate validation setting, WebSocket path, or REALITY parameter can cause a later handshake failure. Recheck your subscription settings first; don’t try to hide the problem by disabling certificate verification.
3. How to Test Real Connection Latency: Use One Target and Repeat
Choose a test URL and keep it fixed while testing candidate configurations. The test URL is the destination the client uses to check connectivity—not the node server address. Websites differ in hosting region, response behavior, and access policies, so results from different targets or days aren’t directly comparable.
- Check the test settings. In v2rayN, open Settings → Parameter Settings and look for options related to the latency test URL and download test URL. Field names vary by version. Note the current values, and don’t keep changing them just to chase a lower result.
- Run the tests separately. Select a configuration in the v2rayN list, open the right-click menu, and run the tests labeled “Tcping” and “Real Connection Latency” separately. Don’t run batch tests while downloading large files.
- Choose an available test on Android. Open the top-right menu in the v2rayNG main list and look for an option such as “Test Real Connection for All Configurations.” Some versions require the service to be running first. Menu names vary by version; a successful test does not mean every app is routed through the proxy.
- Run at least three rounds. Wait about 10 seconds after each round before starting the next. Keep each round’s success or failure status, and use the median of successful results—not just the lowest value.
- Try an actual website, too. Select the configuration, connect, and open a site you use regularly. If the test URL works but the site doesn’t, check that site’s DNS, routing, and access restrictions.
These figures are practical suggestions, not measured node results. Three rounds can help with quick screening but can’t prove long-term stability. For meetings or extended transfers, keep monitoring during actual use. Batch tests may saturate your network or device; if results look abnormal, retest configurations one at a time.
Bottom line: Rule out repeat failures, then compare successful results
Don’t let one unusually fast result hide failures in other rounds. First keep configurations that pass repeatedly and can reach your actual destinations, then compare their typical latency and variation.
4. How to Read Download Test Results: Bandwidth, Units, and Test Costs
Run download tests only on a small number of configurations that passed the real connection test. Throughput—the amount of data transferred per unit of time—is different from latency. A fast connection setup doesn’t guarantee fast sustained transfers, and high download throughput doesn’t mean every small request will respond quickly.
- Check the units first. 1 byte equals 8 bits. Ignoring protocol overhead, 100 Mbps is about 12.5 MB/s. That’s a unit conversion, not a speed guarantee for any node. If the app shows MiB/s, note that it isn’t exactly the same as decimal MB/s.
- Check the number of connections. Single-connection and multi-connection tests aren’t directly comparable. Multiple connections may use more of your available bandwidth, but a single download or application connection may not reach the same speed.
- Keep test conditions consistent. Use the same download URL, test duration, and network. Pause background sync, system updates, and other high-bandwidth activity on your devices.
- Look at sustained performance. The initial peak can be skewed by buffering and sampling. Check whether the speed stays steady, then verify it with an actual video or file download.
- Keep data use in mind. At 10 MB/s for 20 seconds, the download uses about 200 MB, plus protocol overhead. Batch testing adds to your network and subscription data usage.
The test server itself can be a bottleneck. If every configuration gets similarly low speeds at the same time, check your local network and test source before assuming all nodes are congested. Browser speed tests also depend on browser proxy settings; they may measure a direct connection. First make sure traffic is actually going through the selected configuration.
5. Choosing on Desktop and Android: Use the Same Method, Check App Coverage Separately
Test whether the node works separately from whether an app is actually using the proxy. v2rayN is a desktop client; v2rayNG is an Android client that uses the Xray core. Even with the same subscription imported, results can differ because of the network, DNS, and proxy scope on each device. Don’t expect identical latency readings across devices.
Recommended approach: Test the configuration, then test the app
Desktop: v2rayN
- Run a real connection test first to confirm the selected configuration can reach the test destination.
- When using the system proxy, check that the target app reads the system proxy settings. Command-line tools don’t necessarily use it automatically.
- Check the local listening address and port. For example, if the actual port is 10808, the app must use the matching port and protocol—don’t rely on memory.
- If TUN is routing traffic through a virtual network adapter, check its status and routes. Don’t assume it works the same way as the system proxy.
Android: v2rayNG
- Select a configuration and start the service, then confirm Android has granted VPN permission.
- If per-app proxying is enabled, check that your browser and the app you’re testing are included as intended.
- Retest after switching between Wi-Fi and mobile data. Don’t carry over rankings from the previous network.
- If traffic only stops after the app moves to the background, check Android’s battery restrictions. Don’t assume every issue is caused by node speed.
Use the same test destination on both devices, but record each device’s network, test time, and app proxy coverage separately. Compare latency and throughput only after confirming connectivity.
When recording results, note the test time, client version, network type, destination, number of successful tests, and speed units. Before sharing a screenshot, hide subscription links, user IDs, and sensitive server details. There’s usually no need to share your full configuration; the failure stage and relevant error text are often enough to narrow down the issue.
6. Common Questions: Timeouts, Negative Results, and Test Rankings
Real connection latency shows -1. Does that mean it’s too low to measure?
No. Some versions use a negative number or special text to indicate failure, a timeout, or no valid result. Check your client’s status descriptions, then retest the configuration on its own and review the logs. Don’t include negative results when ranking successful tests, and don’t interpret them as “negative latency.”
Why can my browser load websites when the client test times out?
First check whether the test destination is restricted, then confirm the browser is using the same configuration. It might be loading a cached page, using a different proxy extension, or connecting directly because of routing rules. Repeat the test with one fixed destination. If only the test URL fails, switch to a reachable, consistently responsive test target in the settings and establish a new baseline.
Why does video still buffer on the node with the lowest latency?
Pause other downloads, then test sustained throughput on the current configuration. Buffering may also be caused by the route to the media server, load on the node’s exit, or local Wi-Fi. Compare the same video at the same resolution and time of day; don’t use the latency to a test homepage as a measure of video performance.
The ranking changes every time. Should I keep switching to the top result?
There’s no need to chase the lowest result from a single test. Keep one reliable primary configuration and one backup, then run three rounds to confirm the success rate. Switch only if you see repeated failures, major fluctuations, or slower performance in real use. If the difference is only a few milliseconds, check how things work in practice instead of repeatedly interrupting the connection.
7. Choose a Node in This Order
- Check the entry point first. For TCP transport, use TCPing as an initial check—but don’t mistake an open port for a working proxy.
- Then verify the route. Keep the real connection test URL fixed, repeat the test, and favor configurations that don’t fail repeatedly.
- Match the test to the task. For everyday browsing, look for stable real connection results. For video and large downloads, add a download test. Test real-time apps in the apps themselves.
- Finally, check app coverage. Confirm which traffic is routed by the system proxy, TUN, or Android VPN. A client test can pass even when your app’s traffic isn’t going through the proxy.
Troubleshooting gets easier when each metric is matched to what it measures. TCPing checks whether the entry point is reachable; a real connection test checks whether the proxy route can complete a request; a download test checks sustained throughput. Confirm that a configuration works, compare its stability, then look at peak speed. That’s usually more useful than focusing on a single ranking.