For anyone managing several servers at once, this article breaks down what ping and Tcping, real connection latency, and download speed tests each measure, where their errors come from, and how far apart their typical values sit. It gives an order of evaluation for two scenarios — picking a server day to day and troubleshooting a route — and lists the four most common misreadings. After reading, you can filter servers in a fixed order instead of switching on gut feeling.
What Each of the Three Numbers Measures
Ping measures one ICMP round trip from your machine to the target server; Tcping measures one TCP round trip along the same path. Both cover only the local machine–to–server segment. They never enter the proxy protocol, and they say nothing about whether the server is actually forwarding traffic.
Real connection latency measures the full path: establishing the TCP connection, completing the TLS handshake, running the VMess or VLESS protocol handshake, and receiving the first valid response byte. Because server processing time is included, a value higher than ping is normal — it does not mean the server is broken.
A download speed test measures throughput in MB/s or Mbps — how much data can be moved per unit of time. It is a different dimension from latency: a 40 ms server may deliver only 3 MB/s, while a 180 ms server may hit 20 MB/s. Both are common.
| Metric | What It Measures | Coverage | Typical Range | Main Error Sources |
|---|---|---|---|---|
| ping / Tcping | One network round trip | Local machine to server IP | 10~300 ms | ICMP rate limiting, handshake queueing |
| Real connection latency | Handshake to first byte | Local machine to completed outbound | 30–150 ms above ping | Server load, TLS negotiation, protocol handshake |
| Download speed test | Throughput per unit time | Usable bandwidth of the whole path | 1~50 MB/s | Speed test file location, single-thread limits, local bandwidth ceiling |
The Measurement Boundaries of Ping and Tcping
Tcping is closer to real-world use than ICMP ping, because proxy connections are built on TCP in the first place. ICMP is rate-limited, deprioritized, or simply dropped on many routes, so “ping fails but the server works” is not a contradiction.
The reverse also holds: a low ping does not mean the server is usable. A server may expose only port 443, with ICMP and every other port silent. In that case Tcping 443 returns a result while ping returns nothing — normal configuration, not a fault.
- Answers: round-trip time from your machine to this server, whether packets are dropped, whether jitter persists.
- Answers: whether the server port is listening, whether the TCP handshake is intercepted along the way.
- Cannot answer: whether the server process forwards traffic correctly, whether the protocol handshake succeeds.
- Cannot answer: the server's real throughput, whether the server is rate-limiting you.
Real connection latency
RecommendedCovers the whole flow from handshake to first byte, closest to what you actually feel when opening pages and loading APIs.
Best for: picking a server day to day, checking whether a server works at all
ping / Tcping
Looks only at link-layer round trips, so the numbers are clean and fast to collect — the handiest way to locate route problems.
Best for: diagnosing link quality between your local network and the server
Download speed test
Measures throughput per unit of time, reflecting bandwidth rather than responsiveness, and each run consumes real traffic.
Best for: bandwidth screening for large downloads and video
Why Real Connection Latency Sits Well Above Ping
Real connection latency includes at least three round trips: one for the TCP three-way handshake, one or two for the TLS handshake (usually one with TLS 1.3), and one for the protocol handshake plus first byte. Every round trip adds link RTT, so with a 100 ms link, a real connection latency of 250–400 ms is a common range.
The standard is not the absolute value but the relative ranking within the same batch of servers, plus how much a single server fluctuates across repeated measurements. Comparing absolute numbers across regions means little; two servers in the same city are the ones worth putting side by side.
Recommended Setup: Which Speed Test Entry Point to Use on Each Platform
Desktop (v2rayN)
- Right-click in the server list → “Test server Tcping latency”
- Right-click → “Test server real connection latency”
- Run a download speed test from the speed test column or the “Test speed” toolbar button
Android (v2rayNG)
- Server menu on the right → “Test real connection latency”
- The menu can test every server at once
- Do bandwidth screening back on desktop to cut data usage
Real connection latency measured on both platforms lands in a similar range; a 10–30 ms gap is normal, and there is no need to force the two numbers to match exactly.
Three Prerequisites for Download Speed Tests
Download speed tests are the easiest to get wrong. Most default test files sit outside China, and if your home broadband is only 100 Mbps, the ceiling you measure is 12.5 MB/s — no server can push past it. Run a baseline over your local connection first, so you know whether the bottleneck is the server or your own line.
In v2rayN you can replace the speed test file URL under Settings → Parameter Settings with an address closer to you, and results will track your real usable bandwidth more closely. The server used for the test really does forward data — quite unlike a latency test.
Note
Every download speed test transfers the full size of the test file. Multiply a 10 MB test file by the number of servers, and a metered plan can burn several hundred MB in minutes. Filter servers with real connection latency first, and run download tests only on the final two or three you plan to keep.
- Measure baseline bandwidth once over your local connection and note the number for comparison.
- Run a download speed test on each candidate server; if the single-thread result falls short, try multi-threaded.
- Swap the test file for an address you can reach nearby, to cut interference from cross-border routes.
- A result at 70% or more of the direct baseline counts as acceptable throughput for that route.
Order of Evaluation: From Packet Loss to Bandwidth
The three numbers have a fixed order of use; reverse it and you reach the opposite conclusion. Start with download speed, for example, and servers with high bandwidth but high latency float to the top — day-to-day browsing actually feels slower, so you end up switching servers again.
- Check Tcping packet loss first. Drop any server losing more than 5%; ignore its latency figure entirely.
- Then look at how much real connection latency fluctuates. Refresh three times and take the median; anything varying by more than 50% drops to backup.
- Sort by median real connection latency and take the top three into the next round.
- Run download speed tests on those three and choose by purpose: low latency for pages and APIs, high throughput for large files and video.
- If pages are still slow after connecting, check DNS and routing rules before swapping servers again.
Conclusion: Check Packet Loss First, Compare Latency Next, Measure Bandwidth Last
A server losing more than 5% of packets is unusable no matter how low its latency looks; only servers whose real connection latency varies by less than 20% deserve a download speed test. Reverse the three steps and the results will almost certainly flip.
Four Common Misreadings
| Common Misreading | What Actually Happens |
|---|---|
| Low ping means fast | Ping covers only the local machine–to–server segment; it excludes protocol handshake and forwarding time |
| A fast download test means good for browsing | Throughput and latency are separate dimensions; page loads depend more on latency and DNS resolution |
| Watching only the minimum, not the jitter | The minimum often appears in a single idle moment; the median represents normal conditions |
| Testing with the system proxy on gives truer results | The client's built-in speed test does not go through the system proxy; having the proxy on only affects tests run inside a browser |
What these four misreadings share is mixing numbers from different dimensions into one ranking. Remember that the three layers — link, handshake, throughput — each map to one kind of number, and no single figure will lead you astray when choosing servers.
Conclusion: Test the Same Server Three Times and Read the Median, Not the Minimum
The minimum usually shows up in a single idle moment and does not represent normal conditions. Take the median of three measurements, compare it across the same batch of servers, and the result stays stable and is easier to reproduce next time.
Speed Test FAQ
Why is real connection latency so much higher than ping?
Real connection latency includes the TCP handshake, TLS handshake and protocol handshake; the extra 1.5–3 round trips all add link RTT, so 30–150 ms higher is a normal range. If the gap stays stable over time, server processing is fine.
The same server shows very different latency on two refreshes — is that normal?
Fluctuation within ±20% is normal; above 50%, or frequent timeouts, check your local network first, then consider route congestion. In that case demote the server to backup rather than using it as your main one.
Download speed tests look fast, but pages still load slowly?
Throughput and latency are two dimensions. Page loads depend more on handshake latency and DNS resolution, so switch to a server with lower real connection latency and confirm domain resolution is not taking a long detour.
Should I turn off the system proxy before running a speed test?
No. The built-in speed tests in v2rayN and v2rayNG are started by the client itself and do not go through the system proxy; only tests run from a browser against a speed test website are affected by the proxy.
Do speed tests use up server traffic?
Yes. Tcping and real connection latency only perform handshakes, so traffic use is negligible; a download speed test really transfers the test file, 10 MB per run, so on metered servers test only the final two or three you plan to keep.