The milliseconds shown in the server list and download speed answer different questions. Tcping checks whether the server port is reachable, real connection latency tests whether a proxy request completes, and a download speed test measures sustained transfer. This guide is for anyone seeing “low latency but pages won’t load” or “real connection timed out, but the port is reachable.” It explains what each test covers, how to interpret the results, and what to check next—so you can find working nodes without sorting by a single number.
What each test actually measures
Start by breaking down the connection: your device connects to the node server, the proxy core negotiates the protocol and transport, and the node reaches the destination website. A response from the server doesn’t mean authentication succeeded; successful authentication doesn’t guarantee the destination is reachable. Each test covers a different part of the path, so the results aren’t interchangeable.
Tcping: server port reachability
Attempts to establish a TCP connection to the node’s address and port, primarily measuring connection setup time. It does not validate VMess or VLESS credentials or request a webpage.
Use it to quickly rule out basic connection issues, such as an unreachable port or an incorrect server address.
Real connection latency: proxy request availability
RecommendedSends a request to a specified test URL through the node being tested, covering proxy protocol negotiation and access through the node’s exit. It’s closer to a typical webpage request, but only reflects that particular test destination.
Use it when choosing a node for everyday use: first identify candidates that can complete a proxy request.
Download speed test: sustained throughput
Downloads test data through the node and measures transfer speed over a period of time. Results depend on the test source, network congestion, test duration, and number of concurrent connections.
Use it to compare sustained traffic, such as large downloads, after confirming the connection works.
In the v2rayN main window, select a server and open its context menu. Look for options such as “Test server latency (Tcping),” “Test server real connection latency,” and “Test server speed.” Labels and locations may vary by version and interface, so follow the menu in your current version. Don’t assume a shortcut from one version works in every version.
Why does a low Tcping result still leave webpages unreachable?
Tcping is not the same as your system’s ping command. Ping commonly uses ICMP, while this check tests a TCP port. A server can ignore ICMP requests and still accept TCP connections; conversely, a host that responds to ping may not have the port used by the node open.
If the node uses a domain name, its address must also be resolved before connecting. Whether DNS lookup time is included in the displayed result depends on the test implementation, so a Tcping result alone can’t confirm that DNS is working. For configurations that don’t use TCP as their actual transport, a TCP probe is even less of a substitute for testing the real protocol.
- Port reachable, authentication fails: The TCP connection may succeed even if the UUID, password, or protocol settings are wrong, while proxy requests fail.
- Entry point reachable, transport mismatch: A mismatch in the WebSocket path, Host, or TLS server name can cause the connection to be rejected during a later negotiation stage.
- Front-end service responds: For nodes behind a reverse proxy or CDN, Tcping may measure the front-end entry point rather than the full status of the back-end proxy service.
- Exit access restricted: Even after accepting a connection, the node may be unable to resolve or connect to the test site due to an exit network issue or destination restrictions.
Takeaway: once the port is reachable, test a proxy request right away
If Tcping returns a result but webpages won’t load, run a real connection latency test next and check the core logs. Don’t keep changing your local system proxy settings just because the latency number is low.
What real connection latency includes—and what to check when it times out
Real connection latency isn’t simply the “distance from your device to the server.” A test typically involves connecting to the node, negotiating the proxy protocol, having the node reach the test URL, and waiting for a response. If the test URL uses HTTPS, the relevant TLS steps are included too. Timing boundaries, connection reuse, and success criteria vary by implementation and version, so results from different tools aren’t directly comparable.
Look under Settings → Parameter settings for options related to the real connection test URL, speed test URL, and timeouts. If the current interface has multiple tabs, check those related to testing or speed. Note the actual URL before comparing nodes. A test URL that returns an empty response or a small amount of data is generally better for measuring request latency; a large file URL is better for measuring throughput. They serve different purposes.
- Test one node at a time. Pause batch tasks and retest the same node to avoid concurrent connections using local bandwidth or triggering server-side limits.
- Check the node settings. Edit the relevant entry in the server list and compare its address, port, credentials, transport, and TLS settings against the source. Don’t guess at missing fields.
- Check the system clock. Enable automatic time synchronization in your operating system. A significant time difference can affect certificate validation and protocol authentication that depends on time.
- Check the stage shown in the logs. For connection timeouts, start with reachability; for certificate errors, check the time and server name; for authentication or transport errors, check the node settings. A single timeout doesn’t tell you which end is at fault.
- Retry with another accessible test destination. If only the original destination fails, investigate the connection from the node’s exit to that destination instead of assuming the entire node is down.
How to read download speed results: units, duration, and data usage
A download speed test measures throughput, not response latency. A high-latency connection can still deliver high speeds during a sustained download, while a low-latency connection may be limited by exit bandwidth or server throttling. Judge initial response time and long-term download stability separately.
The bandwidth figures above illustrate unit conversion; they are not test results from this site. Pay attention to uppercase B and lowercase b: MB/s means megabytes per second, while Mbps means megabits per second. If the interface shows MiB/s, its conversion base differs from MB/s as well. Convert to the same units before comparing; don’t directly subtract a provider’s advertised bandwidth from a speed test result.
- Keep the test source consistent: Results can change when you use a different download URL for the same node. The source’s speed limits, load, and location all affect the result.
- Keep test conditions consistent: Use the same network, roughly the same time of day, and the same test settings. Pause large downloads, cloud sync, and other bandwidth-heavy tasks.
- Don’t rely on a brief peak: Short tests can be affected by connection setup and transfer ramp-up. Check whether the client reports an average or another statistic before interpreting the result.
- Keep data usage in mind: Downloading continuously at 10 MB/s for 10 seconds uses about 100 MB of data, plus protocol overhead. Batch testing more nodes adds to the total.
Turn test results into a node selection workflow
Don’t start by running download speed tests on every node. Check reachability first, verify real requests next, then test throughput on just a few candidates. This makes troubleshooting clearer and avoids unnecessary data use. The table below explains combinations of results; it does not report performance measurements for any group of nodes.
| Result combination | What it likely means | Next step |
|---|---|---|
| Tcping succeeds; real connection times out | The entry point is reachable, but the proxy request didn’t complete | Check protocol settings, core logs, and the test destination |
| Real connection succeeds; download speed is low | Basic requests work, but throughput is limited | Use the same test source and retest after pausing local bandwidth-heavy tasks |
| Real connection is slow; sustained download is fast | Response latency and sustained throughput differ | Choose based on your actual use, such as web browsing or file downloads |
| Test succeeds; browser fails | App routing or destination routing may differ | Check the system proxy, browser settings, and matched routing rules |
Workflow: keep nodes that complete requests reliably, then compare throughput
Run three real connection tests for each candidate node, recording failures and changes in latency. First rule out nodes that repeatedly time out, then run download speed tests on the remaining candidates. Finally, verify with a website you actually need to access.
Sort the three results from lowest to highest and use the middle value as a reference for comparing this round, while keeping a record of failures. Don’t record timeouts as 0 ms and include them in an average—that would make failed nodes appear “faster.” Record results from different times of day separately; a single daytime test can’t explain evening congestion.
Frequently asked questions about latency tests
If the result shows -1 or times out, is the node completely dead?
Not necessarily. A negative value or timeout usually indicates failure, not actual latency. Retest the node on its own, then check the test URL and logs. If multiple nodes fail only against the same destination, try another test destination first. If just one node keeps failing, check its settings and service status.
Why is it fast right after a test but slower a little later?
The number in the list is from a single test, not continuous monitoring. Use the same test destination, record latency and failures over three rounds, and pause background downloads. If the variation occurs mostly at a particular time, compare real-world access during that period. One peak result isn’t a reason to replace your entire setup.
Do I need to enable the system proxy or TUN before testing a node?
Built-in tests generally create a test path through the node being checked, so enabling the system proxy or TUN isn’t a universal prerequisite. First make sure the core starts normally. After a successful test, choose how to route traffic from apps such as your browser. If you use multiple routing methods at once, check for loops or conflicting paths.
Is the node with the fastest real connection latency always best for downloads?
Not necessarily. Use real connection tests to find working nodes, then run download speed tests on a few candidates. For downloads, focus on sustained speed and stability; for web browsing, response time and failure rate matter more. Since the test destination may differ from the service you need, verify your final choice with a real-world request.