Tcping checks whether a TCP connection can be made to a server port. Real connection latency checks whether a request to a test target can complete through the proxy, while a download speed test measures sustained throughput. This guide is for desktop users who see “latency but no websites” or “low latency but slow downloads.” It explains what each test covers, what to check, and how to combine the results instead of choosing a node by a single millisecond figure.
What Tcping, real connection latency, and download speed tests measure
v2rayN is a desktop client that manages configurations and runs proxy cores. The results in its node list come from different test procedures; they are not three ways of displaying the same measurement. Understanding what each test covers helps you see which problems a successful result rules out—and which it does not check.
| Test | What it measures | What it does not prove |
|---|---|---|
| Tcping | Time to establish a TCP connection from your device to the node's address and port | That proxy authentication is correct or the destination website is reachable |
| Real connection latency | Time for a request to a specified test URL through the tested proxy to complete | That every website works or that sustained download speeds are high |
| Download speed test | Transfer rate when retrieving a test file through the tested proxy | That interactive response is fast or every download source will deliver the same speed |
Results also depend on the client version, proxy core, test URL, timeout, and concurrency settings. Real connection latency typically includes connecting to the proxy, any required handshake, and waiting for the destination to respond. The exact start and end points, as well as connection reuse, depend on the implementation. It is not a precise measurement of a single network round trip, and subtracting Tcping results from it does not reveal server processing time.
Why Tcping can succeed when you still can't browse
Tcping is not the same as the command-line ICMP ping. A server that does not respond to ICMP may still have an available proxy port; conversely, a successful TCP connection only means that the address and port accepted it. It does not verify whether the service behind that port understands VMess or VLESS, whether the user ID is valid, or whether the transport settings match.
For common TCP-based connections, Tcping covers mainly the early steps. A failed TLS handshake, incorrect WebSocket path, or mismatched REALITY public key or server name can all result in “Tcping returns a value, but the real connection times out.” If a reverse proxy or relay sits behind the same address, a successful TCP connection may only reach the entry point—it does not confirm that the proxy service beyond it is working.
- Authentication settings: Check whether the subscription is up to date and whether the user ID, password, or other details were changed manually. Do not combine fields from another node with the current configuration.
- Transport settings: Check the WebSocket path, Host, TLS server name, and REALITY fields. Keep the combination required by the server.
- System time: Enable automatic time synchronization. A significant clock difference can affect certificate validity checks and protocols that verify timestamps during authentication.
- Server-side outbound access: Even if the entry point accepts a connection, problems with server DNS or access to the destination website can still cause the real connection test to fail.
In this situation, check the core logs for handshake, authentication, and DNS errors first, then review the configuration. Repeatedly running Tcping does not test the next steps or fix incorrect protocol settings. If the error involves a certificate or authentication, do not hide the cause by disabling certificate verification.
Real connection latency: test targets and actual browsing are different
Real connection latency is closer to an everyday request than Tcping because it starts or invokes the proxy core and requests a specified address through the tested node. It helps answer “Can this configuration complete a proxy request?” but still measures one particular request, not a complete browser session.
Real connection test settings
- Where to configure
- Speed test options under Settings → Parameter Settings
- Test target
- Note the latency test URL configured in the interface
- Keep variables consistent
- Do not change the URL, network, or timeout settings during testing
Field names and locations may vary by version. Use the test URL and timeout shown in your current interface.
Browser access settings
- Application proxy setup
- Make sure the browser uses the system proxy or a locally configured proxy
- Selected node
- Make sure the active node is the one you just tested
- Routing
- Check the logs to see whether the website is routed through the proxy or connected to directly
The built-in test can use the tested proxy directly; it does not require the system proxy to be enabled.
So a successful real connection test and a browser that still fails are not contradictory. The browser may not be using the proxy, or an extension may be using a different proxy configuration. The website's domain may match a direct-connection rule while the test URL goes through the proxy. Watch the logs while making a request in the browser to confirm whether it reaches the core and which outbound route it uses.
Conversely, a browser may open familiar websites even when the real connection test fails. The test site may be unreachable, its response may not match what the test expects, or the timeout may be too short. First try the test target with the same node, then retest with another lightweight target known to work. Changing the target helps verify the test conditions; do not choose a target simply because it produces a lower number.
- Select a few nodes in the list, then use the right-click menu to find the test option containing “Real Connection Latency.”
- Wait for the test run to finish and record whether it succeeded or failed, along with the test target. Menu wording may vary by version.
- Set one successful node as active, then use a browser to visit the websites you actually need.
- If the results differ, check the system proxy, local listening port, browser proxy settings, and routing logs.
Download speed tests: throughput, units, and resource use
A download speed test measures how much data can be received over a period of time. Link bandwidth, server load, packet loss, congestion control, the file host, and test duration can all affect the result. Low latency can help interactive response but does not guarantee high sustained throughput. A high-bandwidth route over a long distance may not deliver the lowest real connection latency either.
- Check the units:
MB/sandMbpsare different units. Using decimal bytes, 1 MB/s equals 8 Mbps. If the interface reports MiB/s, convert using binary bytes instead. - Avoid competing for bandwidth: Pause large downloads, cloud sync, and tests on other nodes, or the results will reflect competition for the same shared connection.
- Retest a small selection first: Choose a few candidates that passed the real connection test. Do not start by running a download speed test on an entire subscription.
- Account for data use: Speed tests transfer real data and may count toward usage limits set by your system or provider. Repeating a test is not cost-free.
Short tests can be affected by connection setup and ramp-up, while longer tests are more likely to encounter changing loads. If a test shows a high initial peak that soon drops, look at the steady-state speed rather than recording only the maximum. Different test resources may be on different networks, and a speed cap on the test source itself does not prove the node's outbound bandwidth is inadequate.
Ports and test order: confirm availability before comparing speed
When troubleshooting, it is easy to confuse the node port, local listening port, and destination website port. They belong to different parts of the connection. The numbers below illustrate port roles only; they are not recommended settings for every node or fixed defaults for the current version of v2rayN.
For example, if an application connects to 127.0.0.1:10808, it is connecting to a local listening endpoint, not the remote node's port 443. This works only if the current configuration provides the proxy protocol the application needs on port 10808. The same port number does not mean the same protocol, and HTTP and SOCKS proxy settings are not interchangeable.
- Check the configuration: After updating the subscription, verify the node address, port, and transport details. If the core reports a startup error, fix that first.
- Use Tcping for a first pass: Look for obvious TCP connection failures, but do not choose the active node based only on the lowest result.
- Retest with real connections: Test candidates with the same URL. Check the logs for failures; move successful candidates to the next step.
- Use download tests as a supplement: Test only candidates that need to support sustained transfers, using the same resource and checking for consistent results.
- Verify with actual apps: Enable the proxy setup you need, visit familiar websites, and confirm that routing and logs look right.
Repeat the tests for three rounds under the same conditions. Record typical results and failures rather than keeping only the best run. This is a comparison method, not a performance guarantee. If loads vary between work hours and evening, keep separate records so early-morning results are not mistaken for peak-time performance.
Common result combinations: troubleshoot the failing step
Tcping returns a result, but the real connection keeps timing out. What should I check first?
Open the logs and test one node at a time. For authentication failures, update the subscription and check the user ID. For TLS or REALITY handshake errors, verify the server name, public key, and related settings. For DNS errors, check DNS for the affected domain. Do not change transport, routing, and DNS settings all at once, or you will not know which change helped.
The real connection test succeeds, but the browser still cannot open pages. Why?
Set the node as active, then choose the system proxy option on the main screen that fits your setup. Next, check whether the browser has its own proxy configured and whether its port matches the local listening port. If the request reaches the core, check which route matched the destination domain instead of changing the test URL again.
Latency is very low. Why are downloads still slow?
Pause other downloads, then test candidate nodes one at a time using the same resource. If only one download site is slow, check for a speed cap on that site or a poor route from the node to it. If several resources are slow, compare your local bandwidth, node congestion, and results at different times. A latency figure cannot be directly converted into download bandwidth.
The result is -1 or a timeout. Does that mean the node is completely down?
A negative value or timeout usually means the test did not get a valid result; the exact display convention depends on the version. It does not mean “negative latency.” Check whether the test target is reachable and whether the core started successfully, then test the same node again. If several nodes fail at once, check the shared test URL, local network, and listening port first.
Choosing a node: availability first, stability next
For everyday browsing, rule out nodes that repeatedly fail real connection tests, then compare response times and variation across repeated runs. If you transfer large files, also check sustained download performance. A node that excels in just one test may not suit every use, and no universal millisecond threshold can determine whether a node is “good” across all networks and websites.
- Browsing and interactive use: Prioritize websites that actually load, a consistent connection success rate, and real connection latency that stays steady across multiple tests.
- Sustained downloads: Among working nodes, compare steady throughput using the same resource, and keep data usage in mind.
- Reproducing an issue: Record the time, network, target URL, error type, and matched route. Do not share subscription URLs or authentication details.
Think of the three tests as checking progressively more of the connection: Tcping checks the entry point, a real connection test checks one proxy request, and a download speed test checks sustained transfer. Finish by testing the applications you actually use to confirm that a result in the node list translates into a working setup. For help checking proxy access and split tunneling, see the routing guide. If your subscription will not update, see subscription troubleshooting.