TCPing checks whether a server port is reachable; real connection latency shows whether a proxy route can complete a test request; and a download test measures sustained throughput. For users who have imported a subscription and are comparing servers: rule out unusable configs first, compare response times next, and test download speeds only for the remaining candidates.
What the three tests measure: ports, requests, and sustained transfers
The “latency” shown in a client’s server list is not a single, standardized metric. The same millisecond unit may represent only a TCP connection to the server—or a test URL reached through the proxy. Before comparing results, check which test ran and whether it used the same target.
| Test | What it measures | What it doesn't tell you |
|---|---|---|
| TCPing | The TCP connection from your device to the configured server address and port; usually the time to establish the connection | Whether proxy authentication works, the target website is reachable, or download bandwidth is sufficient |
| Real connection latency | Access to a test URL through the selected server; typically includes the proxy connection and an HTTP or HTTPS request | Whether every website is accessible, long-lived connections are stable, or download speeds are high |
| Download speed test | Data received through the proxy, measured as throughput over time | Whether interactive responses are fast, speeds stay consistent at other times, or every destination performs equally |
The timing boundaries for real connection latency depend on the client version and test implementation. Some tests include DNS lookup, the TLS handshake, or connection setup; others reuse an existing connection. It's best understood as “the time for one request under specified conditions,” not as a standardized round-trip time that can be compared across platforms.
Low TCPing latency but websites won't load: where to look
Suppose a config uses TCP port 443. A successful TCPing test only means that the port on that address accepted a TCP connection. The listening port may belong to a reverse proxy or CDN edge, and subsequent requests still depend on the transport settings, proxy authentication, remote outbound route, and destination website. A failure at any stage can prevent the page from loading.
- Check the server fields first. The server address, port, and user ID in the subscription must match. Don't mistake the display name in a share link for the server address, and don't change the port to
443without a reason. - Then check the transport settings. For WebSocket, verify the path and Host; for TLS, check the server name and your device's clock. If a VLESS config uses REALITY, make sure the public key, server name, and other parameters match the server's requirements.
- Check that the core supports the config. V2Ray and Xray don't support exactly the same features. Successfully importing a config doesn't mean the current core supports all its transport and security options. Check the startup logs and connection errors.
- Finally, check the outbound route and destination. A server may authenticate successfully while remote DNS, the outbound network, or the destination website still fails. Test two different sites you use regularly rather than drawing conclusions from just one.
In logs, connection refused usually means a connection target refused the connection; timeout simply means an operation didn't finish within the allotted time. First identify whether the log refers to a local listening address, the proxy server, or the final destination, then investigate. Focusing on one error word can lead you to mistake an entry-point issue for a server issue.
Bottom line: once the port is reachable, check the protocol and request path first
If TCPing succeeds but real connection tests keep failing, check the config, core logs, and test URL. Don't keep sorting servers by TCPing results. A low port connection time is useful for comparison only after the request layer passes.
How to run tests in v2rayN and on Android
In v2rayN, select an entry in the server list and open its right-click menu. Look for options such as “Test server latency (TCPing),” “Test server real connection latency,” and “Test server speed.” Menu wording, spacing, shortcuts, and submenu placement can vary by version. Identify the test by its function, and don't mistake an old result in the list for the current run.
Test plan: check connectivity first, then speed
Desktop: v2rayN
- After updating the subscription, select the entries to test and run the real connection latency test from the right-click menu.
- Wait for the entire test run to finish, and note failed entries and the test time.
- Test download speed for passing candidates one at a time to avoid competing for bandwidth.
- Switch to an active server, then use your browser to check the websites you normally visit.
Android: v2rayNG / v2flyNG
- Select a config and start the connection. Grant VPN permission when prompted by the system.
- In the menu, look for “Test real connection” or the equivalent connection test. Batch testing options vary by version.
- v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Check config compatibility before switching.
- Stay on the same Wi-Fi or mobile network throughout the test.
The test URL, timeout, and timing method may differ between platforms. Compare results within each client; don't combine desktop and Android millisecond readings into one ranking.
A built-in client test may create a test route directly for the selected entry, without relying on the system proxy. A browser, however, depends on the system proxy, its own settings, or TUN routing. So after a built-in test succeeds, confirm that the app is actually using the intended entry point. Don't keep changing the subscription to fix a browser routing issue.
How to read download speeds: units, duration, and concurrency
A download test measures how much data can be received over a period of time. Results are usually shown in MB/s, MiB/s, or Mbps. Broadband plans commonly use Mbps, while clients may show bytes per second. If the numbers differ by about a factor of eight, check the capitalization and units before assuming the connection is throttled.
These are unit conversion examples, not measured server results, and don't account for protocol overhead. If the timing includes connection setup, the average speed for a small file will be much lower. Multiple concurrent downloads can produce a higher result than a single connection. Recording how you tested is more useful than saving a peak number by itself.
- Use the same test resource and time window. Compare results using the same URL, file size, or test duration to avoid one download hitting a CDN cache while another fetches from the origin.
- Stop competing traffic. Pause system updates, cloud sync, and other downloads. Devices on the same network can also use up bandwidth and lower your results.
- Separate the initial burst from sustained speed. A short-lived spike doesn't represent a long download. Check whether the speed holds up in the second half and whether transfers stall often.
- Keep data usage in mind. Speed tests transfer real data. For example, at an average of 10 MB/s for 10 seconds, the test receives about 100 MB. Check your data allowance before running repeated tests.
Which result should guide your server ranking? Filter in two stages based on what you need
Everyday browsing and API requests depend on reliably completed responses; large transfers depend more on sustained throughput. First use real connection tests to find working configs, then compare latency or download speed based on your needs. TCPing helps diagnose entry-point issues, but it's not a reliable overall measure of user experience.
Prioritize real connection latency
RecommendedFirst remove entries that fail repeatedly, then compare multiple results under the same test conditions. A server that responds quickly once but times out the rest of the time should rank below one that stays available.
Best for: everyday browsing, short requests, and initial server selection
Use download speed as a second filter
Run this only for candidates that have passed connection tests. Compare sustained speed and interruptions; don't switch servers repeatedly for a single brief peak.
Best for: large file transfers and extended data downloads
Use TCPing as a diagnostic
Use it to check whether the server's TCP entry point is reachable. If the port connects quickly but requests fail, investigate the proxy settings and the rest of the route.
Best for: distinguishing an unreachable port from a request-layer failure
Try each candidate three times and note how many tests succeed and the typical response time. For example, three results of 180, 195, and 210 ms to the same test URL have a median of 195 ms. Another server with one result of 80 ms and two timeouts shouldn't be considered better just because of its lowest value. These numbers illustrate how to record results; they don't represent the performance of any actual server.
Test in this order: success rate → typical latency → sustained speed
Start with entries that complete requests consistently. If response times are similar, compare throughput based on your actual download needs. Record timeouts as failures; don't count them as zero milliseconds in an average.
Speed test results don't match website performance: four common questions
Real connection test passes, but your browser still can't load pages?
First, open the v2rayN tray menu and check that “Set system proxy” is configured to “Automatically configure system proxy.” Then make sure your browser isn't using a different, manually configured proxy. Check the port the client is actually listening on. If the interface shows 10808, external apps should use that port instead of copying a port from another guide. Then check whether routing sends the destination through the intended outbound.
Only real connection tests time out, but the websites you use still load?
Check the test URL and timeout in your current version's settings, and make sure the test destination is reachable. Pin the server and try another known working website. A restricted test URL, changed response format, or too-short timeout can all cause failures. Don't disable TLS certificate verification just to get a result.
Download speeds are high, so why is the first page still slow?
Webpages load resources from multiple domains and require DNS lookups, scripts, and images; they aren't a single continuous download. Keep the current server selected and check other websites separately. Then review the logs for the destination and outbound route of slow requests. A real connection test covers only its configured URL, not every page resource, and doesn't measure the experience of UDP applications.
Things work during the day, but speeds drop at night. Should you change protocols?
Keep the server, network, test URL, and test method the same, and record results at both times. If multiple servers slow down at once, first check for local bandwidth contention and network congestion. If only one server consistently underperforms, investigate that server or a specific route. VMess and VLESS are proxy protocol names, not speed tiers; the protocol name alone can't predict bandwidth.
A simple record is enough: time and date, network type, client and core versions, test URL, successful test count, typical latency, and download units. Before sharing logs for help, redact subscription URLs, user IDs, and authentication details in share links. For more help checking entry points and routing, see Deep Dive. Make sure app traffic reaches the correct entry point before comparing server speeds.