Use TCPing to screen node ports, real connection latency to check whether a node can complete a proxy request, and download tests to measure sustained throughput. This guide is for v2rayN users facing issues like “low latency but pages won’t load” or “high latency but fast downloads.” Keep test conditions consistent, troubleshoot each layer, then choose a node based on how you’ll use it.
What Each Speed Test Measures
Loading a webpage involves more than connecting to a server. Your device connects to the node, the proxy core handles protocol authentication and transport negotiation, and the node connects to the destination site before response data returns. TCPing, real connection latency, and download tests measure different parts of this process, so their results aren’t directly comparable in a single ranking.
| Test method | What it primarily measures | What it tells you | What it doesn’t tell you directly |
|---|---|---|---|
| TCPing | TCP connection from your device to the node address and port | Whether the entry port is reachable and roughly how long the connection takes | Whether the UUID is correct or the proxy can access websites |
| Real connection latency | A request sent through the tested node to a test URL | Whether the proxy route and test destination are reachable | Response speed for every website or throughput for large files |
| Download speed test | Sustained data transfer from a speed test server through the node | Transfer rate to that destination during that test | Long-term minimum bandwidth, gaming latency, or overall app experience |
Real connection tests often use a very small HTTP response, such as a URL that returns status code 204. They send an actual proxy request, but don’t load a full webpage. The timing endpoint, connection reuse, and timeout handling depend on the client and core implementation. So the result shouldn’t be read as “how long it takes for a browser page to fully load.”
Why a Low TCPing Result Doesn’t Mean a Node Works
TCPing typically attempts to connect to the server address and port configured for the node. If the node uses a domain name, its address must be resolved first; whether DNS lookup time is included depends on the implementation. TCPing is not ICMP ping and doesn’t require an ICMP response. A TCP port can accept connections even when the server blocks regular ping requests.
For example, if a VLESS node listens on TCP port 443 and TCPing reports 45 ms, that only shows that the entry point accepted a TCP connection. It says nothing about the subsequent TLS or REALITY negotiation, VLESS authentication, or the node’s outbound connection to the destination website.
- Authentication error: The VMess or VLESS UUID doesn’t match. TCP may still connect, but proxy requests will fail.
- Incorrect transport settings: A mismatched WebSocket path or Host, or an incorrect TLS
serverName, may not cause an error until after the TCP connection is established. - Incorrect security settings: A mismatched REALITY public key,
shortId, or related setting needs to be checked in the core logs—not by repeatedly refreshing TCPing. - Only the entry point was tested: A node using a CDN may connect to a nearby edge first. Low latency to that edge doesn’t mean the origin connection or subsequent outbound route will also be fast.
Real Connection Latency: Check for Success Before Comparing Milliseconds
A real connection test sends a request through the node being tested. It typically involves a connection from your device to the node, proxy protocol handling, a connection from the node to the test destination, and the response coming back. With an HTTPS test URL, the destination’s TLS handshake is also involved. DNS caching, connection reuse, and the test method can all affect the time.
So TCPing at 45 ms and real connection latency at 260 ms aren’t contradictory. The difference isn’t a precise measure of “server processing latency,” and subtracting one number from the other doesn’t tell you how busy the node is. The test destination, the node’s outbound route, and the number of handshakes can all affect the result.
TCPing for Initial Screening
Check entry-point connectivity first to quickly spot obvious network or port problems across a group of nodes. Don’t choose your everyday node based only on the lowest millisecond reading.
Best for: Quickly checking entry-point issues across many nodes
Screening by Real Connection Latency
RecommendedRun repeated tests against the same URL. Keep nodes that return successful, consistent responses with little latency variation, then verify them against the websites you actually use.
Best for: Web browsing, API requests, and everyday node selection
Follow Up with a Download Speed Test
Test sustained throughput only for a small shortlist. Consider data usage and your actual needs; there’s no need to repeatedly run full-speed tests on every subscription node.
Best for: Large file transfers and evaluating video buffering
A real connection timeout doesn’t necessarily mean the node is unusable. The test URL may be unreachable, the destination may restrict certain egress routes, or DNS resolution may have failed. Keep the results from the original URL, then retest with another reliable URL that returns a small response. Don’t change destinations from one comparison round to the next, or you’ll lose a consistent baseline.
Download Speed Tests: Understanding MB/s, Mbps, and Burst Speeds
A download test measures how much data arrives over a period of time. The bottleneck could be your home broadband, Wi-Fi, shared node bandwidth, the outbound link, or the speed test server. The result describes the whole route, not the performance of the node server alone.
Start with the units. In decimal units, 1 MB/s equals 8 Mbps. Broadband plans are commonly advertised in Mbps, while download apps may display MB/s or MiB/s. The figures below are illustrative examples for educational purposes, not measurements by this site or a performance guarantee for any node. They show how all three results can occur at once.
- Low latency, low throughput: Short requests may respond quickly, while long transfers are limited by throttling or shared bandwidth.
- High latency, high throughput: A long-distance route may have a high round-trip time yet still sustain a high transfer rate once connected.
- Fast at first, then slower: Burst bandwidth, congestion, or server policies may be a factor. Watch the stable rate, not just the brief peak.
At an average rate of 8 MB/s, a 15-second test transfers about 120 MB, not including protocol overhead. Testing multiple nodes uses more data. If your subscription is metered, narrow the list with real connection tests first, then run download tests on two or three candidates.
Build a Repeatable Test Workflow in v2rayN
The steps below follow the node list workflow. Depending on the version, right-click menu items may be named “Test server latency (Tcping),” “Test server real connection latency,” or something similar. Settings may also move between groups, so follow the interface in your version. Record the client and core versions before testing; don’t combine results from before and after an upgrade as if they came from the same test run.
- Keep network conditions consistent: Pause other downloads, cloud sync, and system updates. Choose Ethernet or the same Wi-Fi network, and don’t switch networks during testing.
- Check the test settings: Open “Settings” → “Parameter Settings” and check the latency test URL, speed test URL, timeout, and concurrency options available in your version. Record the actual values. If speed test options have their own section, check that section too.
- Start with a small batch: Select the nodes to test in the node list, right-click, and run TCPing. Then run a real connection test on the same nodes. Record the results separately; don’t treat the two latency fields as interchangeable.
- Run three rounds: Use the same test destination each time and record both successful attempts and latency. For example, if the results are 180, 185, and 620 ms, the median is 185 ms—but keep the 620 ms spike in your records too.
- Test throughput separately: Run download speed tests on shortlisted nodes, one at a time. Record the time of day, test duration, and average speed. Avoid running multiple downloads that compete for your device’s bandwidth.
- Check your real-world use: Set a node as active and open the websites or services you actually use. A successful built-in test doesn’t guarantee that your system proxy, app proxy, or routing settings are correct.
Two-Round Testing: Separate Node Quality from Your Setup
Controlled test conditions
- Keep the test URL, network, and test duration consistent.
- Test a small batch for latency first, then run download tests one node at a time.
- Record all three rounds, not just the lowest result.
Everyday app usage
- Restore your usual system proxy and routing settings.
- Check that the target app is actually using the selected node.
- Retest websites, video, or downloads during your usual hours.
Controlled tests compare nodes; everyday checks confirm your configuration and real-world experience. Neither can replace the other.
Built-In Test Passes, but Your Browser Is Still Slow: Check the Proxy Route
The node test in v2rayN and your browser traffic may not follow exactly the same configuration path. A node test typically routes its test connection through the selected node, while everyday app traffic is also affected by system proxy settings, the app’s own proxy settings, routing rules, and DNS behavior. If a website is routed directly by a rule, switching nodes may not change its speed.
For an independent check, you can specify the local SOCKS endpoint explicitly. The command below assumes you’ve confirmed that 127.0.0.1:10808 is an active SOCKS or compatible mixed inbound, and that you’ve selected the target node in the interface. Port 10808 is just an example and may not apply to every installation. If your local listener uses a different address, update the command first.
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --output /dev/null --silent --show-error --write-out "HTTP=%{http_code} total=%{time_total}s\n" https://www.example.com/- This command works in Linux and macOS terminals with
curlinstalled. In Windows PowerShell, usecurl.exeand replace the output target/dev/nullwithNUL. socks5hsends the destination hostname to the SOCKS proxy for resolution, which can reduce differences caused by local DNS lookup. The core and routing configuration still determine where the hostname is ultimately resolved.time_totalis the total time from the start of this command until the transfer ends. It isn’t the same as the real connection latency field in v2rayN, nor is it a measure of server processing time alone.- The example destination is only for checking that a request works. Use the same reliable destination for meaningful comparisons; don’t use the response time for a small page to estimate large-file download bandwidth.
Explicitly specifying the proxy endpoint helps rule out issues with the system proxy, but it doesn’t bypass the core’s routing rules. If you still suspect the request is taking the wrong route, check the destination, matched rule, and outbound tag in the logs while the request is running. Redact subscription URLs, credentials, and other sensitive information before sharing logs.
Speed Test FAQs: Troubleshoot by Symptom
TCPing takes only a few dozen milliseconds, but the real connection test times out. Should I switch nodes?
Run another real connection test from the node list, then check the core logs for the same time. If you see an authentication or handshake error, verify the UUID, TLS, REALITY, and transport settings. If only the test URL fails, try a reliable alternative before deciding the node is the problem.
Every node fails the test at the same time. Does that mean my subscription has expired?
Start with one known-working node and reduce concurrency. Check your local network, test URL, and whether the core started normally. Don’t repeatedly delete and reimport the entire subscription before identifying the cause.
Why are downloads fast but webpages still slow?
Large file transfers and repeated short connections are different workloads. Check real connection latency across multiple rounds, then inspect browser DNS, routing, and third-party resources on the website. Retest the same page instead of comparing load times across different sites.
Does -1 or a timeout mean the latency is extremely high?
Usually, treat these results as a failed test, not negative latency. Check the timeout setting and logs, then test again separately. Failure indicators vary by version, so read the status text; don’t average them with valid millisecond readings.
Should I always choose the node with the lowest latency?
Compare success rates and consistency first, then consider what you need the node for. For browsing, prioritize nodes with stable real connection results; for large transfers, compare sustained throughput. Retest at least once during your usual hours and keep a verified backup node.
A practical order for choosing a node is: successful requests, consistent results, and working performance for your actual use—then consider whether an individual metric is lower or higher. Record the test destination, network, time, and units so you can tell whether a slowdown came from the node, destination server, or local setup.