v2rayN Speed Test Guide: Tcping, Real-Connection Latency & Download Speed

Three speed tests, three different things measured

The key takeaway: these results aren’t interchangeable. A low Tcping result doesn’t mean proxy authentication works. Low real-connection latency doesn’t guarantee fast large downloads. High download speed doesn’t ensure every webpage loads quickly. Each test measures a different stage—connection setup, a complete request, or sustained transfer—and each has different units and limits.

v2rayN is a graphical client that coordinates speed tests; some tests require the selected core. Xray and V2Fly don’t support exactly the same protocols or configuration fields. Before testing, make sure the node loads correctly with the current core. A reachable port doesn’t confirm protocol compatibility.

Tcping: Establishes a connection, but doesn’t test the full proxy

Tcping isn’t the same as a standard ICMP ping. It typically measures how long it takes to establish a TCP connection to the node’s server address and port. For example, if the node uses port 443, that’s the port being tested—not an arbitrary web server port. A domain-based node must also resolve its address first; whether DNS lookup time is included depends on the implementation.

Even if the TCP connection succeeds, the proxy may still reject it because of an incorrect UUID, password, TLS server name, or other setting. For nodes behind a reverse proxy or content delivery network, Tcping may only confirm that the front end is reachable—not that the proxy service behind it is working. A nearby entry point also doesn’t mean the exit node is close to the destination website.

• A result is shown: The target TCP port was reachable at the time of testing. This doesn’t mean a VMess, VLESS, or Trojan proxy session was established.
• Timeout: The port may be filtered, the address may be invalid, the network path may have a problem, or the server may not be responding. Check the logs and run other tests before drawing a conclusion.
• Not applicable: If actual traffic doesn’t use this TCP endpoint, Tcping can’t test the real path. A failure doesn’t necessarily mean the node is unusable.
• Highly variable results: Repeat the test on the same network before treating one slow connection attempt as a persistent problem.

Real-connection latency: The test target is part of the route

Real-connection latency is closer to “how long does it take to complete a specific request through this node?” The route typically includes a local connection to the proxy entry point, proxy protocol negotiation, the node’s exit connection to the test target, and the response back to your device. Depending on the configuration and implementation, it may also involve DNS lookups, a TLS handshake, connection reuse, and redirects. It doesn’t measure the distance to the node server alone.

“Real connection” doesn’t mean the test fully simulates loading a webpage. A page may involve dozens of domains, scripts, and images; a latency test usually sends just one small request. Completion criteria can vary by version—for example, the test may wait for response headers, a specific status code, or the entire request to finish. For meaningful comparisons, use the same test address and client version.

A test address that returns 204 generally sends no response body, making it suitable for checking small requests. But don’t assume every v2rayN version accepts only this status code. Use an address supported by the client and follow its success criteria. Enabling the system proxy alone also doesn’t guarantee that the built-in speed test will work: it may use a dedicated test configuration rather than the routing used for everyday traffic.

Download speed: Measure throughput separately from latency

A download test measures how much data is read over a period of time—not how quickly the first response arrives. Results depend on your local connection, Wi-Fi, proxy exit capacity, server throttling, congestion control, test duration, and concurrency. If the download test and real-connection test use different targets, different rankings are normal.

Check the units first. MB/s means megabytes per second; Mbps means megabits per second. Using decimal units, 8 MB/s × 8 = 64 Mbps; actual transfers also have protocol overhead. The figures below are examples for illustration only, not measurements from this site or performance claims about any node service.

These results don’t contradict each other: the connection to the entry point is quick, but a complete request involves more steps. Once connected, the node can still deliver good sustained throughput. If example node B has a real-connection latency of 180 ms and a download speed of just 2 MB/s, B may be better for small requests while A may be better for sustained transfers. Verify performance in your actual apps before deciding.

A consistent test process: Screen first, then compare

Select nodes in the v2rayN list, open the right-click menu, and run the tests you need. Common options include Tcping latency, real-connection latency, and server speed; labels vary across desktop versions. Look under “Settings” → “Parameter settings” for test options. The exact section may differ in your version. Note the existing values first; there’s no need to copy unfamiliar settings just to run a test.

1. Control variables: Pause background downloads, use the same local network throughout, and record the client and core versions, test address, and time. Don’t compare results from Wi-Fi with results from a wired connection.
2. Check reachability: Run Tcping and keep reachable entries. For transports that aren’t suitable for TCP checks, go straight to the relevant proxy request test.
3. Verify usability: Run three real-connection tests for each candidate, about 10 seconds apart. Record failures and use the median of successful results instead of keeping only the best run.
4. Limit download tests: Test only two or three candidates, one at a time. If you can set a test duration, use 15 seconds for each; otherwise, leave the default and record the actual duration.
5. Test with your apps: Select a candidate node and open a website you use regularly to confirm that traffic exits as expected. If the built-in test succeeds but an app doesn’t, check routing rules, the system proxy, and TUN mode.

For example, three real-connection results of 180, 195, and 420 ms have a median of 195 ms. If another node returns 160 ms, timeout, timeout, you can’t call it better based on its one successful result. Record timeouts as usability data; don’t silently discard them or arbitrarily convert them to zero.

Unexpected results: Find where the failure occurs

A negative value, blank field, or timeout in the latency column usually indicates a failed test—not “negative latency.” Its exact meaning depends on the client version, so check the logs. Change one condition at a time; otherwise, you won’t know whether switching nodes, changing the test address, or adjusting DNS made a difference.

Keep test records for meaningful comparisons

The same node name doesn’t guarantee that its entry point, exit node, or upstream route stays the same. After updating a subscription, briefly retest your regular candidates. You don’t need to save subscription URLs or authentication credentials—just record the test conditions and results.

• Environment: Operating system, v2rayN and core versions, local network type, and test date and time.
• Conditions: Test target, duration, whether nodes were tested one at a time, and the proxy and routing settings in use.
• Results: Tcping, three real-connection readings and the number of failures, plus average download speed and its unit.
• App checks: Whether commonly used websites load, transfers remain stable, and traffic exits as expected.

To check traffic routing, read the DNS setup guide and TUN mode guide. If the problem occurs during a subscription update rather than a speed test, see subscription update troubleshooting. Identify the failing part of the process before changing any settings.