If a node has low latency but pages won’t load—or a speed test times out while your browser works—check the entry port, proxy route, and download throughput separately. This guide explains what four common tests measure, how to run them in v2rayN, how to record results consistently, and how to troubleshoot timeouts. For users who have imported a subscription and want to find reliable everyday nodes.
Four network tests, four different measurement scopes
A node can’t be described by a single latency figure. A web request may pass through your local proxy port, the node’s entry point, a protocol handshake, the node’s exit, and the destination website. ICMP ping and TCPing usually stop near the entry point. A real connection test checks whether a proxy request works, while a download test measures sustained throughput. Since each test ends at a different point, their results don’t belong on one simple speed ranking.
| Test | What it primarily measures | What it cannot prove on its own |
|---|---|---|
| ICMP ping | ICMP round-trip time and response from your device to the target host | Whether the node’s service port is open or proxy authentication is correct |
| TCPing | Time to establish a TCP connection from your device to the node’s specified port | Whether the VMess or VLESS configuration is correct or the exit can reach websites |
| Real connection latency | Time for a request to reach a test address through the selected node | Whether every website is reachable or long transfers remain stable |
| Download speed test | Rate of sustained data transfer from a specified resource through the node | Whether web pages load quickly or UDP performs well in games |
ICMP doesn’t use TCP ports. If a node listens on 443, a regular ping won’t test that port. Servers may also block ICMP, so “ping failed” doesn’t mean the proxy is unavailable. If a relay or content delivery network sits in front of the node address, your probe may reach only that front-end—not the final exit host.
A successful TCPing test means only that a TCP endpoint accepted a connection; it does not verify the proxy protocol. Even if the port responds quickly, a wrong user ID, TLS server name, transport path, or other protocol setting can still make subsequent requests fail. For configurations that rely on a non-TCP transport, TCPing is even less of a substitute for testing the actual connection.
Choose the right metric: check availability before throughput
Real connection latency
RecommendedFor everyday node selection, first use this test to see whether proxy requests complete, then compare results across multiple runs. The test address may take a different route from the websites you use, so verify with an actual visit too.
Best for: web browsing, office apps, and an initial shortlist of everyday nodes
TCPing
Quickly check whether the node’s entry TCP port is reachable. Useful for narrowing down a problem after a real connection test fails, but don’t choose your primary node based only on the lowest result.
Best for: checking entry-point connectivity and isolating failures
Download speed test
Watch transfer rates over time, keeping file size, test duration, and data usage in mind. A resource server’s rate limits can also lower the result.
Best for: large file transfers and assessing video buffering
Real connection latency is not necessarily the same as full page load time. Depending on the client version, the test may use different timing boundaries, connection reuse, and success criteria. HTTPS requests may also involve DNS, the proxy protocol, TLS, and the destination’s response. For a fair comparison, keep the client version, core, test address, and network conditions the same; don’t draw conclusions from a single test on two different devices.
How to choose: rule out repeated failures, then compare stability
Run five consecutive real connection tests and record the number of successes and the median. Compare the candidates that succeed every time against your actual browsing experience and download needs. Don’t let one unusually low TCPing result outweigh repeated timeouts.
Run a comparable test session in v2rayN
Update your subscription and check that node settings are complete. Then pause system updates, cloud sync, and other high-bandwidth tasks. The steps below use labels from the commonly seen Chinese v2rayN interface. Menu wording can vary by version; options labeled “Tcping,” “Real connection latency,” and “Speed” in the right-click menu run different tests, so don’t mix their results.
- Record test conditions. Find the version number under “Help” → “About” or in the current version information. Also note the core, Wi-Fi or wired connection, and test time. Don’t change several settings at once while testing.
- Choose a small set of candidates. Select 3–5 nodes in the list, right-click, and run the test labeled “Tcping” to check the entry port first. Avoid running concurrent tests on a large subscription.
- Run the real connection test. Keep the nodes selected, right-click, and choose the test labeled “Real connection latency.” If a test fails, record the timeout first; don’t immediately set the timeout limit to an extremely high value.
- Keep the test address fixed. Look for speed- or latency-test settings under “Settings” → “Parameter settings,” and note the current test address and timeout. If your version has a separate settings page, use the options shown there. Don’t change the target between runs.
- Repeat the test. Run five rounds, about 10 seconds apart. Count timeouts separately, sort the successful results, and take the middle value. Don’t treat a timeout as 0 ms when calculating an average.
- Test downloads one node at a time. Run the speed test separately for each node you keep, or use a trusted resource that permits speed testing and observe it for about 20–30 seconds. Check your subscription’s remaining data before continuing.
Reading the results: why low latency and high speed can coexist
The figures below illustrate how to interpret results; they are not measurements from this site or a promise of node performance. Suppose node A returns real connection times of 176, 184, 181, 179, and 180 ms across five tests, with an average download rate of 8.0 MB/s. Test conditions are unchanged, and no other downloads are running.
42 ms and 180 ms are not contradictory: the first measures only the time to establish a TCP connection to the entry point, while the second includes more of the proxy request. Subtracting one from the other does not give an exact “node processing time,” because the tests use different connections, routes, and timing boundaries.
| Example node | TCPing | Real connection | Download | Interpretation |
|---|---|---|---|---|
| A | 42 ms | 5/5 successful; median 180 ms | 8.0 MB/s | A good everyday candidate |
| B | 18 ms | 3/5 successful; median of successful tests: 290 ms | 1.2 MB/s | Fast entry point, but the full request is unstable |
| C | 96 ms | 5/5 successful; median 240 ms | 15.0 MB/s | Good for large downloads; check interactive latency separately |
Node C has higher throughput than A, but that doesn’t mean every web page will load faster. Pages involve multiple requests, script execution, and responses from resource servers. Large downloads, on the other hand, can sustain bandwidth more easily once a connection is established. Keep units consistent: using decimal units, 8.0 MB/s is about 64 Mb/s. This is still an application-level data rate and won’t necessarily match your internet plan’s advertised speed.
Troubleshoot timeouts: check the entry point, protocol, and destination in order
When a test times out, first identify which kind of test failed. Treating every failure as “the node is broken” can lead to repeated subscription changes while missing the real cause, such as a local port conflict, an unreachable test address, or traffic routed directly.
Why is TCPing fast while the real connection keeps timing out?
Open the client logs and look for authentication failures, TLS handshake errors, or closed connections. Check the address, port, user ID, and transport settings in your subscription, and verify your system clock. A reachable TCP entry port does not mean the proxy protocol handshake succeeded.
Why does my browser work while the real connection test times out?
Check whether the built-in test target is unreachable on its own, then confirm that your browser actually uses the selected node rather than a direct connection or another node. Retest with a reachable, fixed target and check the logs to see which outbound route was used.
Why does the download crawl at a few hundred KB/s even though the real connection test passes?
Pause other transfers and test one node at a time, then cross-check with another resource that allows downloads. If only one resource is slow, the source may be rate-limiting you or the route to that site may be poor. If everything is slow, check your local network and node congestion.
Ping fails, but websites work. Should I switch nodes?
Don’t switch nodes based on ICMP results alone. The server may not respond to ICMP; check the real connection success rate and actual website access instead. To investigate packet loss, use sustained requests or diagnostics suited to the transport. An unanswered ICMP ping does not by itself mean proxy traffic is being lost.
VMess and VLESS are protocol names, not performance ratings. A faster node may have a closer entry point, more exit bandwidth, or a different relay route. Two latency columns alone cannot prove that one protocol is inherently faster. If you change protocols and servers at the same time, the comparison no longer isolates one variable.
Check the browser route: specify the local proxy port explicitly
On Windows, you can run a supplementary check with the built-in curl.exe. This example assumes you’ve confirmed in v2rayN under “Settings” → “Parameter settings” that the local HTTP or mixed proxy port is 10808, and that the candidate node is active. This port is for the example only; if the interface shows a different one, update the command to match. A SOCKS-only port cannot be used directly as an HTTP proxy port.
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --output NUL --silent --show-error --write-out "http=%{http_code} start=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/- Choose a test target: The command structure uses an example domain. For an actual comparison, use a stable HTTPS page that you can access and are permitted to test, and keep the address the same throughout.
- Read the output:
httpis the HTTP status code;startis the cumulative time from the start of the request to the first byte;totalis the total time for the transfer. These are not direct substitutes for the real connection value shown in v2rayN. - Rule out local issues first: If the connection to
127.0.0.1fails, check that the client is running, the port is correct, and the core has started. Don’t immediately assume the remote node is down. - Distinguish a response from access: A response such as 403 means you received an HTTP response, but the destination may restrict access. A status code does not automatically mean the service is usable.
Specifying the proxy explicitly can help rule out apps that ignore the system proxy, but you still need to check the core’s routing rules: the domain may be routed through a direct outbound. To verify a candidate node, check the logs to confirm the request used the corresponding proxy outbound, and watch for TUN or other networking software changing the underlying route.
Keep primary and backup nodes for different needs
Choose by use case: assess interactive performance separately from sustained downloads
Web browsing and everyday work
- Keep candidates that succeed in all five real connection tests.
- Compare the medians and note whether the slowest result is unusually high.
- Open the two websites you use most and check sign-in and resource loading.
- Keep a backup node with a different entry point or route.
Video and large files
- After confirming availability, test sustained downloads one node at a time.
- Use the same resource, duration, and speed units; avoid concurrent speed tests.
- Test again during your usual evening hours to spot peak-time congestion.
- Track data usage and avoid repeatedly maxing out your bandwidth.
Prioritize stable access, then choose a node for the task. Your primary and backup nodes don’t need to rank first and second on a latency leaderboard.
For real-time voice or gaming, also verify UDP reachability, jitter, and sustained packet loss in the relevant app. TCPing, HTTP real connection tests, and download rates are no substitute for these metrics. Keep at least the date, network, node, test target, number of successful tests, and speed units in your records. That way, when an issue comes up, you can tell whether it’s due to a change in your local network, the destination website, or peak-time degradation on the node’s route.