TCPing vs. Real Connection Latency vs. Download Speed Tests: How to Read Client Results

How the three tests differ: port reachability, proxy requests, and sustained throughput

Start with what each test measures—not just the numbers. TCPing typically attempts to connect to a specified TCP port on the server. A real connection latency test usually sends a request to a test URL through the selected server. A download speed test reads data through the proxy and measures how many bytes arrive over time. Each covers a different part of the connection, so their results can’t be ranked on the same scale.

v2rayN is a client; the selected core handles the actual proxy connection. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Tests with similar names in different client interfaces may not use the same timing method. Before comparing results across clients, check the test URL and how each test works.

Why can TCPing be fast while websites still won’t load?

Take a server using TCP port 443 as an example: a successful TCP connection only shows that something at that address and port accepted the connection at that moment. It could be the proxy service, a reverse proxy in front of it, or another service. The TLS handshake, proxy authentication, or request to the destination can still fail.

1. Check the server settings. VMess or VLESS credentials and transport settings must match the server. If TLS is enabled, verify the server name and other security settings too. Don’t disable certificate verification just to make a test pass.
2. Check the transport settings. With WebSocket, an incorrect path or Host setting can cause an error response after the TCP connection succeeds. A normal port latency doesn’t mean these settings are correct.
3. Check the server’s outbound connection. Accepting a connection doesn’t mean the server can resolve or reach the destination domain. An outbound network problem or access restrictions on the destination can make a real connection test fail.
4. Check how local traffic is routed. A built-in test may start its own test connection, while your browser depends on the system proxy, an app-level proxy, or TUN. A successful test doesn’t mean the browser used the same route.

System ping has similar limitations: ICMP responses may be blocked even when a TCP service works, and an ICMP response doesn’t prove the proxy port is open. When troubleshooting, record which test failed instead of simply saying that “ping failed.”

Real connection latency: Check the test URL, timeout, and route

A real connection latency test usually covers more than TCPing. It may involve the local test entry point, the server handshake, the server’s outbound connection, destination DNS resolution, and an HTTP or HTTPS request. Which steps count toward the final time, and whether a connection is reused, depend on the implementation. Don’t interpret the result as the physical round-trip time between two locations.

• Use the same test URL. Test every server against the same URL. Otherwise, one request might go to a nearby site and another to a distant one. If the test site itself is down, several healthy servers may all time out.
• Use the same timeout. For example, set a 5-second limit for every test. Exceeding it means the request didn’t finish in time—not that the connection latency was exactly 5,000 ms.
• Check the response. Some tests require a specific status code or response format. Receiving webpage content doesn’t necessarily meet the test’s success criteria.
• Distinguish the test route from your usual route. A batch test may create a temporary test connection for each server, while browser traffic follows the current routing rules. Don’t assume the two routes are the same.

In v2rayN, look for a test option labeled “Real Connection Latency” in the node list’s right-click menu. You can usually find settings such as the test URL and timeout under Settings → Parameter Settings. Menu labels and locations may change between versions, so check your current interface. In v2rayNG, look for connection test options in the main menu. Don’t confuse a test result in the configuration list with the status of the active VPN tunnel.

Download speed tests: Understand the units and test conditions

A download speed test measures throughput, not “more accurate latency.” A server that takes slightly longer to establish a connection may transfer a large file faster. A low-latency server may still have poor throughput because of outbound speed limits or peak-hour congestion. Short tests can also be skewed by connection warm-up and bursts of bandwidth.

Here’s an illustrative example for learning purposes—not a measurement or performance promise from this site: suppose a server has a TCPing result of 48 ms, real connection latency of 280 ms, and receives 20 MiB in a download test lasting 4 seconds. Its average throughput is 5 MiB/s, or about 41.9 Mbps. There’s no contradiction between these three figures.

Speed tests use real data. The example above transfers 20 MiB in one test; running a test on 30 servers would transfer about 600 MiB of response data alone, before protocol overhead. If your plan has a data cap, narrow down the candidates first instead of running download tests across your entire subscription.

A repeatable way to choose a server: availability first, stability next, speed last

Compare servers on the same device and network, around the same time of day. Start with three candidates and run a real connection test on each five times. Record the number of successful attempts and the median of successful results. Count failures separately—don’t discard them and report only a flattering average.

1. Check the local setup. Pause large downloads, check the system clock, and make sure the core starts normally. After updating your subscription, verify the selected configuration so you don’t test an outdated server.
2. Check the port first. Run TCPing on TCP servers where it applies, and note refused connections or timeouts. Don’t keep only the result with the lowest latency.
3. Verify proxy requests. Keep the test URL unchanged and run five real connection tests per server. If a server succeeds only twice, it shouldn’t take priority over a consistently successful option—even if its lowest result is just 100 ms.
4. Test downloads on a few candidates. Run download speed tests on only the two or three remaining servers. Keep the destination, number of connections, and duration the same, and don’t test several servers at once; they’ll compete for local bandwidth.
5. Try your actual apps. Open the websites you use, play the video you want to watch, or download a real file. If you mainly use the connection in the evening, test again then instead of relying only on morning results.

If your browser can’t connect: Specify the local proxy explicitly

If a built-in test succeeds but your browser can’t load websites, specify the proxy entry point in a command to tell whether the server is unavailable or the app isn’t using the proxy. First, check the local listening address, port, and inbound type in the client settings. The example below assumes 127.0.0.1:10808 is an enabled HTTP or mixed proxy entry point. This port is for illustration and isn’t the default in every version.

curl --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 --output response.html --write-out "HTTP=%{http_code} total=%{time_total}s\n" https://v2rayalpha.com/

On Windows, use curl.exe to avoid command-line environments that interpret curl as a different command. This example saves the response as response.html in the current directory and prints the status code and total time. It checks whether the request completes; it doesn’t measure maximum download bandwidth.

• Fails immediately to connect to the local port: Check that the client is running, the listening port matches, and the entry point supports HTTP proxy connections.
• Connects to the local entry point, but the request times out: Check the core logs for problems with the server connection, TLS, or access to the destination. Don’t just change browser settings.
• The command succeeds, but the browser fails: Check the system proxy status in v2rayN, the browser’s own proxy settings, and whether routing rules send the two through different outbound connections.
• Returns a status code such as 403: This means an HTTP response was received, not that the request succeeded. Check whether the destination site or an intermediate service is blocking it.

Common speed test questions: Timeouts, inconsistent results, and high bandwidth but poor performance