When choosing a server, first confirm it can complete a proxy request, then compare response times, and test throughput if needed. This guide is for users who have imported a subscription but aren’t sure how to interpret latency and speed columns. It explains what each test does and doesn’t measure, where to find the tests in v2rayN and v2rayNG, and how to compare servers under the same conditions. The sample calculations are illustrative, not results from live servers.
Three tests, three different things: port reachability, proxy requests, and throughput
Use proxy response time to shortlist servers for everyday use, TCPing to check the server entry point, and download tests to assess high-volume transfers. These aren’t three levels of precision for the same metric, and milliseconds can’t be ranked alongside megabytes per second as one overall score. A nearby entry point doesn’t mean the proxy’s exit is close to the destination. A fast response doesn’t guarantee high sustained throughput.
TCPing: Check the server entry point
Connect to the server address and TCP port in the configuration, then measure how long the connection takes to establish. TCPing doesn’t verify VMess or VLESS credentials, or request an actual destination website.
Best for: Basic checks of the address, port, and network reachability to the server entry point.
Proxy response time: Check a proxy request
RecommendedSend a request to a test URL through the selected server, covering the proxy connection and destination request. Exactly when timing starts and stops, and whether a connection is reused, depends on the client version and core implementation.
Best for: Finding usable servers for everyday browsing and comparing results across multiple tests.
Download speed: Measure effective throughput
Receive test data continuously through the proxy, then estimate speed from the number of bytes received per unit of time. Results depend on the entry and exit paths, test server limits, and your local network.
Best for: Retesting a few shortlisted servers before streaming or downloading large files.
Standard ping usually uses ICMP, while TCPing uses a TCP connection; don’t confuse the two. If a server blocks ICMP, ping may time out even when the proxy works. Conversely, a ping response doesn’t prove the proxy port is open. If a server uses UDP-based transport, a TCP port test is even less relevant as a measure of whether it works.
Low TCPing but no connection? The test hasn’t reached the proxy handshake
A successful TCPing only means that a TCP port accepted a connection. For example, if the server entry point uses 443, the connection can still fail later during TLS verification, transport setup, or proxy authentication. The port may be handled by a reverse proxy, so the device accepting the TCP connection may not be the proxy process itself.
| Stage | Can TCPing check it? | What to check next |
|---|---|---|
| Server TCP entry point | Yes, it can test whether a connection is established | Address, port, local network, and remote listener |
| TLS and server name | No | TLS, SNI, or serverName in the server editor |
| Proxy authentication and transport | No | UUID, transport type, and fields such as Host and path for the selected transport |
| Access from the exit to the destination website | No | Proxy response-time test URL, remote DNS resolution, and exit connectivity |
In the v2rayN main window, select the server, right-click, and open the server editor. Check its settings against the subscription; don’t change SNI just to reduce latency. TLS servers also depend on the correct system time. In Windows, check automatic time and sync under Settings → Time & language → Date & time.
- Every server entry point times out: First check your internet connection, subscription status, and whether the server address resolves correctly.
- Entry point is reachable, but the proxy test fails: Check the logs for TLS, authentication, or transport errors, then verify the server settings.
- Only one destination fails: Try another trusted test destination before assuming the entire server is offline.
Proxy response time: The test URL and routing matter too
A proxy response-time test usually sends an HTTP or HTTPS request through the selected server. A new connection may include DNS lookup for the server address, connecting to the proxy entry point, TLS and proxy negotiation, connecting from the exit to the destination, and waiting for the destination to respond. It’s closer than TCPing to “opening a website through a proxy,” but it doesn’t represent latency for every website or app.
For an HTTPS test URL, TLS negotiation with the destination may affect the result, as can redirects, destination response times, and connection reuse. Don’t treat the displayed value as a pure network round-trip time. Nor should you calculate exit latency by subtracting TCPing from the proxy response time: the tests may run at different times and use different timing ranges.
- In the v2rayN server list, select a few servers, right-click, and choose the test whose name includes “Test server real connection latency.” Some versions add “(multiple selection)” to the name.
- To check the test destination, go to Settings → Parameter settings and look for “Real connection test address” in the v2rayN settings. Names may vary slightly by version; use the label shown in your current window.
- Use the same test URL when comparing servers. If every server fails, first check whether the URL is still responding normally.
- After choosing a server, use a browser to visit the website you actually need. Check the client logs too, to confirm the request uses the expected outbound route.
DNS resolution can happen in several places. The server address and destination domain may be resolved by different components. Whether resolution happens locally or remotely depends on the core and configuration. Don’t change all your DNS settings just because one latency result is high; check the logs first to see whether the failure is connecting to the server or the destination.
Download speed: Understanding MB/s, Mbps, and test data
A high download speed means this test achieved high throughput; it doesn’t guarantee a fast initial page load. Results vary with the test server’s location, single- or multi-connection strategy, test duration, and server load. Speed tests transfer real data and may use up your subscription allowance. If you’re on mobile data, check your remaining allowance first.
This is a unit conversion only. Using decimal units, a steady download rate of 10 MB/s for 20 seconds transfers about 200 MB. Clients may use different units and include extra stages such as warm-up, so this example doesn’t represent the fixed data usage of every test.
Guideline: Test throughput only for shortlisted servers
Use proxy response-time tests to shortlist two or three reliable servers, then test download speed one at a time. If their speeds are all close to your local connection’s limit, stop ranking them by peak speed. Compare how quickly your everyday apps work and how stable each server is in the evening.
- Match the units: Check whether the result is in MB/s, MiB/s, or Mbps before comparing speeds.
- Test one at a time: Running multiple download tests simultaneously uses your local bandwidth, so a low result doesn’t necessarily mean the server is throttling you.
- Pause background tasks: Downloads, cloud sync, and system updates use bandwidth. A saturated upload can also increase request latency.
- Track sustained performance: Initial peak speeds may be affected by caching or short bursts; they don’t show how fast the connection stays over time.
Desktop and Android: Compare under the same conditions
v2rayN, v2rayNG, and v2flyNG have different interfaces and core combinations, so their tests may work differently. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Even with the same subscription imported, make sure both clients use the same server, port, and transport settings. Don’t rely on the server label alone.
Comparison setup: Same network, same server, same destination
Desktop: v2rayN
- Run a proxy response-time test from the server list’s right-click menu, then test download speed on shortlisted servers using the menu item whose name includes “Test server speed.”
- Record the test URL, time, and client version. Run download speed tests on one server at a time.
- When checking real-world access, verify the system proxy status and routing selection at the bottom of the main window.
Android: v2rayNG
- After connecting, open the menu in the top-right corner of the main screen and select “Test real connection.” Some versions also offer a batch test for all configurations.
- Check the real connection test URL under “Settings” in the main menu, and use the same URL as on desktop if possible.
- First compare both clients on the same Wi-Fi network, then test mobile data separately. Don’t mix results from different networks in the same comparison.
Treat absolute results from different clients as a rough guide only. Compare how consistent each client’s repeated tests are, and whether the same tasks work reliably.
If the current v2flyNG version offers different tests, record the exact menu item name rather than calling a basic connection test a download speed test. Switching cores doesn’t guarantee faster speeds: the protocol and transport must be supported, and the bottleneck may be the Wi-Fi signal, ISP routing, or remote bandwidth.
- Keep conditions consistent: Disconnect other proxies, pause background downloads, and stay on the same network.
- Run three rounds: Wait about 10 seconds between rounds and record proxy response times and failures. Take the median of three valid results, and keep failures separate.
- Retest at different times: Run a set during the day and another in the evening, using the same destination to check for changes in load. Don’t keep only the best result.
- Verify real tasks: Test browsing, video, or file downloads according to your needs instead of relying on a single overall score.
Troubleshooting: Timeouts, negative values, and fluctuating results
TCPing works, but proxy response-time tests keep timing out. What should I check?
First, check the log area in the v2rayN main window to see where the request fails. For TLS errors, check the system time and the server’s SNI. For authentication or transport errors, compare the server settings with the subscription in the server editor. If all servers fail at once, go to Settings → Parameter settings and check the real connection test URL, then try another trusted destination.
It shows -1 ms. Does that mean the latency is extremely low?
No. A negative value, blank result, or timeout usually means no valid result was obtained; check the client’s message and logs for details. Don’t include it in an average latency calculation. Run the test again and note whether the failure was intermittent. A server that fails repeatedly shouldn’t rank higher because of one unusually low result.
The proxy response-time test is fast, but websites still won’t load. What should I check?
First check whether the request appears in the client logs, then check which routing rule matched. If the browser’s requests don’t appear in the logs at all, verify the system proxy or the app’s own proxy settings. For example, before directing an app to 127.0.0.1:10808, confirm the local listening port is actually 10808 under Settings → Parameter settings, and that the protocol matches. This port is an example, not a fixed value across versions.
It’s fast during the day but slow in the evening. Should I reimport the subscription?
Keep the current configuration and run three tests at each time using the same test URL. If both the entry connection and proxy response time slow down, your local connection or the route to the entry point may be congested. If only throughput drops, compare other shortlisted servers and download destinations. Updating a subscription gets you configuration changes; it won’t directly resolve network congestion.
Bottom line: Prioritize availability, then stability; test throughput as needed. For everyday browsing, choose a server that consistently passes the proxy response-time test with little variation. Run download tests when you need to transfer large files. When troubleshooting, record TCPing, proxy response time, and real-world results separately to identify whether the problem is at the entry point, in the proxy settings, or along the exit route.