TCPing is useful for checking whether a server port is reachable. A proxy latency test verifies that a request can complete through the proxy, while a download test measures sustained throughput. This guide is for anyone who has imported a subscription but isn't sure which column to sort by. Follow the steps below to distinguish an open port from a working proxy and a fast download, so you don't end up with the lowest-latency node that doesn't actually work.
Each test measures a different part of the connection
The millisecond value in a node list isn't a standardized metric. TCPing typically opens a TCP connection to the node's address and port. A proxy latency test uses the proxy core to access a test URL through the selected node. A download test goes further, receiving response data and measuring throughput over time. Since they differ in endpoints, request volume, and timing, their results aren't directly comparable.
This diagram shows the logical flow of a request to a destination service through a proxy. Nodes that use an additional transport layer or relay may have other steps between the entry point and the proxy server. TCPing often covers only the first part; proxy latency and download tests also check the rest of the route.
| Test | What it tells you | What it doesn't confirm |
|---|---|---|
| TCPing | Whether a TCP connection can be made to the node's entry-point port | Proxy authentication, access to the destination website, or sustained speed |
| Proxy latency | Whether the selected proxy route can complete a test request | Access to every website or stable downloads over time |
| Download speed | Effective throughput to the test resource | Fast page loads or the same speed at other times |
Why a node can be unusable even with low TCPing latency
For example, if TCPing to server port 443 reports 38 ms, your device can usually establish a TCP connection to the listening port at that address quickly. This doesn't provide the authentication details required by VMess or VLESS, or verify TLS settings, the WebSocket path, or whether the node's exit can reach the destination site.
- Authentication mismatch: The server can accept the TCP connection and then reject the proxy request. Repeating TCPing won't identify an incorrect authentication field.
- Transport settings mismatch: The port may be reachable, but incorrect settings such as the TLS server name or transport path can still cause the application-layer connection to fail.
- The entry point may not be the final server: If a relay or CDN sits in front of the server, a low reading may mostly reflect the distance to that entry point.
- Some protocols don't rely on TCP alone: TCPing can't replace testing actual UDP traffic. Don't use it to infer that every protocol is working.
A TCPing timeout also needs to be considered in light of the test implementation and network conditions. First, confirm the client is testing the current node address and correct port, then check the proxy latency result. If both fail, investigate your local network, the entry-point port, node status, and subscription settings. Don't conclude that the server is down based on just one test.
Proxy latency is a better measure of usability—but check the test target
A proxy latency test typically uses the core to establish a proxy route through the selected node, then requests the configured test URL. Timing may include DNS resolution, the proxy handshake, the destination's TLS handshake, and the wait for a response. The exact start and end points depend on the client and core implementation. It isn't a fixed value that can be calculated as “TCPing plus a few round trips.”
Some test URLs return a tiny response or use an HTTP 204 status as a success signal. These requests are useful for measuring response time, but they don't transfer enough data to estimate download bandwidth. DNS caching, connection reuse, and the test resource's location can also affect repeated results.
Proxy latency test log
- Target URL
- Use the same HTTPS test URL each time
- Number of runs
- 5 runs per node
- Interval
- Wait at least 3 seconds between runs
- Record
- Median, slowest result, and number of failures
Keep the target and test method consistent before comparing nodes.
Download speed test log
- Download resource
- Use the same test file each time
- Test duration
- For example, 10 seconds per run
- Concurrent tests
- Test just one node at a time
- Record
- Average speed, variation, and data transferred
Use a large enough resource to observe sustained speed without the download finishing too soon.
If the test target itself is unreachable, several healthy nodes may all time out. Keep the original settings and try a different, known-accessible HTTPS target with a small response for comparison. Then restore the original URL and test again. If only one target fails, check its access restrictions and the node's exit route instead of immediately deleting the entire subscription.
Download tests measure throughput: know the difference between MB/s and Mbps
Download speed depends on the slowest parts of the entire route, including your broadband connection, Wi-Fi signal, node entry point, server egress, limits on the destination resource, and the number of concurrent tests. A nearby entry point may reduce some round-trip time, but it doesn't guarantee ample egress bandwidth. A high-latency node can still sustain high throughput once a connection is established.
Know your units: 1 MB/s = 8 Mbps using decimal units. A 100 Mbps connection has a theoretical equivalent of about 12.5 MB/s; real-world speeds are also affected by protocol overhead and network sharing. If the interface uses MiB/s, convert using binary units instead. Don't rank values just because they all contain the letter M.
| Displayed value | Decimal conversion | How to read it |
|---|---|---|
| 5 MB/s | 40 Mbps | Transfers about 5 MB of data per second |
| 10 MB/s | 80 Mbps | Don't mistake this for just 10 Mbps |
| 100 Mbps | 12.5 MB/s | Theoretical conversion, not a guaranteed test result |
Compare nodes in v2rayN in a consistent order
The steps below use the typical v2rayN desktop interface on Windows. Menu wording may vary slightly between versions and interface variants; look for the tests labeled “Tcping,” “real connection latency,” and “speed.” Test options are usually under the speed test settings in Settings → Parameter Settings. Note the current test URL, timeout, and download duration before comparing nodes.
- Update and verify the list: Update the relevant subscription group and make sure the nodes you're testing are from the same list refresh. A successful subscription update means the configuration was retrieved; it doesn't mean every node has passed a connectivity test.
- Keep local conditions consistent: Pause other downloads and cloud sync, and use the same network connection for every test. Don't test one node over Ethernet and another over a congested Wi-Fi connection.
- Test the entry point first: Select candidate rows in the server list, right-click, and choose the Tcping test. Keep the results to assess entry-point reachability; don't pick your final node based on the lowest number alone.
- Then test proxy latency: Right-click and choose the real connection latency test. The five-run method above is a good baseline. If your version has a concurrency setting, set it to 1 for consistent comparisons and to avoid tests interfering with one another.
- Run a few download tests: Test download speed only on the two or three nodes with consistent proxy latency. Record the average rate, not the initial peak as if it were sustained bandwidth.
- Verify with a real application: Set a candidate as the active server, check the current status under System Proxy, and confirm that your browser is using the system proxy. Open a page you actually use, then complete a real download.
Built-in tests may use specially generated test configurations, so they don't necessarily follow the same complete route as your browser. If the built-in proxy latency test succeeds but your browser doesn't, check the system proxy, the application's own proxy settings, routing rules, and DNS. If an application has a manually configured local proxy such as 127.0.0.1:10808, make sure it matches the port actually listening under Settings → Parameter Settings. This port is an example, not a fixed value for every installation.
A worked example: low latency, slow downloads
The hypothetical figures below illustrate how to interpret results. They aren't measurements from this site or a performance guarantee from any service. Suppose nodes are tested on the same network, at the same time, and against the same target. Node A has a TCPing result of 32 ms, a median proxy latency of 460 ms, and an average download speed of 2 MB/s. Node B's results are below.
Node A reaches the entry point faster, but is slower when accessing the test target through the proxy. That suggests the route or processing beyond the entry point needs further investigation. These three figures alone aren't enough to conclude that the server's CPU is overloaded or the route is congested; check logs and retest against different targets and at different times. In this example, node B is the better candidate for real-world testing.
How to choose: rule out unstable nodes, then rank by use case
For web browsing, compare proxy success rates and response-time variation first. For large file transfers, compare sustained download speeds. A node that occasionally posts the lowest millisecond reading shouldn't outrank stable candidates if repeated tests often fail.
Averages can hide outliers, too. Five results of 180, 190, 185, 900, timeout don't feel like five results around 220 ms. Recording timeouts and slow requests is more useful than looking at the last number left on screen after a refresh. Test again during peak evening hours to catch issues that may not show up during the day.
Common speed test questions and what to try next
TCPing returns a value, but every proxy latency test times out. What should I check first?
First, verify the test URL and timeout settings, then check the core's logs. If you see TLS or authentication errors, check that your subscription is up to date, your system clock is correct, and transport settings haven't been changed manually. If the port is reachable, repeatedly changing the local listening port usually won't fix a remote handshake error.
The proxy latency test succeeds, but my browser can't open pages. Is the node broken?
First, confirm the active server, then check the System Proxy status and your browser's proxy settings. For apps with a manually configured proxy, verify the local address and port as well. If only certain domains fail, check whether routing sends them direct and whether DNS is returning an unexpected address. A failure with one target doesn't mean the entire node is unusable.
Downloads reach full speed, but web pages still take a long time. Why?
High sustained throughput doesn't mean connections start quickly. A web page may contact multiple domains, with repeated DNS lookups, handshakes, and waits for responses. Check proxy latency variation first, then use your browser's Network panel to compare DNS, connection, TLS, and waiting time. If needed, test another target to rule out slow processing by the site itself.
My desktop and Android results differ. Which one is correct?
Use the same network, node, test target, and roughly the same test time on both devices before comparing. v2rayN is a desktop client; v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Their test implementations and settings may differ. Each result reflects the conditions on that device at that time, so don't use them to rank nodes directly across devices.
Keep a brief record of the test time, network connection, node name, successful proxy latency tests, median latency, and average download speed. Don't include subscription URLs or authentication details in screenshots you share publicly. For further troubleshooting, see Troubleshooting and follow the steps for “Connection failed” or “Some websites won't load.”