This guide is for v2rayN users dealing with issues like “low latency but websites won't load,” “Ping times out but the proxy works,” or “fast speed tests but frequent buffering.” First, distinguish four metrics: host response, port connectivity, proxy requests, and sustained throughput. Then compare nodes using a fixed target, serial retests, and real-world app checks—never treat a single millisecond figure as a complete measure of reliability.
Four types of tests: know what each number measures
v2rayN is a desktop GUI client that delegates node configurations to the selected core. Latency shown in the server list is not an inherent property of a node; it depends on your current network, the test target, and how the test is implemented. Switching Wi-Fi networks, changing the test URL, or testing more nodes in parallel—even at the same time of day—can change the rankings.
Menu names, test options, and timing methods vary by version. Check the command before running it: TCPing results are not “proxy latency,” and download speed is not the same as a webpage's time to first paint.
| Metric | What it measures | What it tells you | What it cannot confirm |
|---|---|---|---|
| ICMP Ping | ICMP round-trip time from your device to the target | Whether the target responds, round-trip time, and packet loss | Whether the proxy port, authentication, and destination website work |
| TCPing | TCP connection from your device to a specified port | Whether the address and port accept a TCP connection | Whether VMess, VLESS, or other protocol settings are correct |
| Proxy latency | Accessing a test URL through the proxy configuration being tested | Whether that configuration can complete a request under the specified test conditions | Whether all websites, UDP traffic, and long downloads work properly |
| Download speed | Downloading a test file through the proxy | Transfer speed for that file during the test | Everyday latency, long-term stability, or speeds across all services |
Ping vs. TCPing: low latency doesn't mean the proxy works
ICMP Ping does not send proxy authentication details or verify TLS, the WebSocket path, or the server's ability to reach external destinations. Some servers and networks restrict ICMP, so a Ping timeout only means no expected response was received—it does not prove the proxy is down. Conversely, a successful Ping does not mean the proxy port is listening.
TCPing checks connectivity at the port level. For example, if a node uses TCP port 443, test the server address and port 443 from its configuration—not some other host. Even if the port accepts a connection, the proxy can still fail during authentication, TLS negotiation, or transport-path matching. With CDN-backed nodes, the TCP connection may reach only an edge server, not the actual proxy service.
- Ping succeeds, but the TCP connection fails: Check for an incorrect node port, network filtering, or a server that isn't listening.
- TCP connection succeeds, but the proxy test times out: Check the protocol settings, TLS server name, transport configuration, and server forwarding setup.
- Ping times out, but the proxy test succeeds: Keep the node; don't remove it just because it doesn't respond to ICMP.
- The node uses a non-TCP transport: TCPing cannot verify that transport. Test the proxy connection using the core that actually handles it.
Proxy latency: the test URL and core both affect the result
A proxy latency test typically starts or uses the proxy configured for the selected node, then requests a specified URL. It covers more than a basic TCP port test, but “proxy latency” is not measured consistently across all versions. Check the current version's implementation to see whether DNS lookup, proxy handshake, TLS connection, and receipt of a response are included in the timing.
In v2rayN, open Settings → Parameter Settings and look for options related to the latency test URL and speed test URL. The server list's right-click menu usually includes a test command for proxy latency. Exact menu locations and wording vary by version. Note the current URL before changing it, so you don't compare results from different targets as if they were equivalent.
A fixed test URL with a small response
RecommendedUse the same stable, accessible URL with a small response, and keep the protocol and redirect behavior consistent. When comparing nodes, change only the node—not the test target.
Best for: screening nodes for everyday use and comparing repeat test results.
Websites you actually use
Use these to check logins, page resources, and destination-specific restrictions. A full webpage involves multiple domains and requests, so its total load time is not a substitute for latency to a small-response test URL.
Best for: cases where general tests pass but a specific service still fails.
A large-file download target
Useful for measuring throughput and sustained transfers, but not for frequent, low-traffic probing. Resource throttling, cache hits, and test duration can all affect the result.
Best for: comparing download performance after candidate nodes pass connectivity checks.
If every node suddenly times out on the same URL, check whether the target is having problems before reimporting all your subscriptions. Also check your system clock, certificate errors in the logs, and whether the destination rejects traffic from the server's exit IP. A successful proxy test proves only that this particular request succeeded.
Download speed tests: bandwidth, units, and short-lived peaks
Latency measures how long a request takes to make a round trip; throughput measures how much data is transferred over time. They may be related, but they are not the same. A cross-region node can have higher round-trip latency yet sustain faster downloads, while a nearby node can connect quickly but struggle with shared bandwidth or peak-time congestion.
The three examples below illustrate unit conversions. They are not test results from this site or performance promises for any node. Lowercase b means bit; uppercase B means byte. In decimal units, 1 byte equals 8 bits. If the app reports MiB/s, binary units also affect the conversion.
The rule: confirm connectivity first, then use data for speed tests
Run short, serial download tests only on the two or three candidates that consistently pass the proxy test. Record sustained speeds, not a single peak, and check how your subscription plan bills data.
- Local limits: Your broadband speed, Wi-Fi signal, router load, and other downloads can all lower the result.
- Remote limits: The node's exit connection, the test server's network, per-connection throttling, and server load can all limit throughput.
- Test duration: A test that's too short may end before transfer speeds stabilize; a longer test uses more data. Keep the duration consistent when comparing nodes.
- Protocol overhead: Encryption, encapsulation, and retransmissions use resources, so real-world speeds are usually below the theoretical rate conversion.
A repeatable selection process: keep conditions consistent and track each stage
Don't select every node and run multiple tests at once. Parallel tasks compete for local bandwidth, connections, and CPU time, so the tests themselves can create queues. A more reliable approach is to screen broadly, narrow down the candidates, and then check real-world apps.
- Keep conditions consistent: Pause system updates and large downloads, use the same network, and note the core, test URL, and time of each test.
- Check ports first: Test connectivity for TCP nodes where applicable. This step narrows the list; don't use Ping as your only reason to discard a node.
- Retest proxy latency: Test each candidate five times, recording successful attempts and every duration. If fewer than five tests succeed, don't record only the average of the successful samples.
- Compare medians: For example, if five results are 180, 185, 190, 210, and 900 ms, the median is 190 ms. Keep the 900 ms spike in your notes too; the median shouldn't hide variability.
- Run short throughput tests: Test two or three stable candidates using the same resource and duration, one at a time. The figures above are calculation examples, not rankings from real nodes.
- Check real-world apps: Switch to the active node, confirm that system proxy or TUN mode is working as expected, then test commonly used websites, video, or file transfers.
Two use cases, two different retesting priorities
Web browsing and interactive requests
- Prioritize proxy test success rate and variation across repeat tests.
- Check DNS resolution, logins, and resource loading on sites you actually use.
- Keep results from peak hours; don't judge by the lowest reading during quiet periods.
Large files and sustained transfers
- Confirm a stable connection before comparing sustained download speeds.
- Keep the download target, test duration, and local network consistent.
- Watch for stalls and reconnects; don't rank nodes by momentary peaks.
Bottom line: choose your primary node based on the services you use, keep a backup for reliability, and track latency separately from throughput.
Tests pass, but websites still won't load: check the traffic path
Node tests and browser traffic may not use exactly the same entry point or route. The client can test a specific node, while your browser may not be using the system proxy or may be routed directly by the rules. So “the server list test succeeded” and “this app is using that node” are two different things.
- System proxy: Check whether the app uses the system proxy settings. Command-line tools and some apps may not follow them automatically.
- TUN: Check that the virtual network interface started successfully, the required permissions are available, and the relevant routes are active. Don't rely on the toggle's appearance alone.
- Local listener: Check the actual port in Parameter Settings. If you set it to
127.0.0.1:10808, the app must use that port and the correct proxy type. This is a configuration example, not a guarantee of the current version's default. - Routing and DNS: Check which rule matches the destination domain and where its traffic exits. Reaching the test domain doesn't mean a service's domain follows the same route.
- Core logs: Distinguish connection timeouts, authentication failures, certificate errors, and local port conflicts before deciding which settings to change.
VMess and VLESS are proxy protocol names, not speed tiers; switching protocols does not replace checking your settings. For TLS nodes, verify settings such as the server name against the server requirements. Don't disable certificate validation just to make a test pass. Low TCP latency is no help if the configuration doesn't match the server.
FAQ: latency readings, speed tests, and choosing a node
The latency column shows -1. Does that mean the node is completely down?
Some versions use a negative or blank value to indicate that a test didn't succeed; it does not mean “negative latency.” First check whether the test was TCPing or a proxy latency test. Retry the node on its own using the same target, and check the logs and timeout settings. Treat it as a node failure only if repeated tests fail and the node also doesn't work in real apps.
Why is an 80 ms node slower than a 200 ms one?
First, make sure both numbers come from the same kind of test. If they are proxy latency results for the same URL, compare sustained throughput and request success rates as well. The 80 ms node may connect quickly but have a congested exit, while the 200 ms node may be farther away but have more bandwidth available.
Do I need to enable the system proxy for a speed test?
Built-in client tests usually use the selected node's proxy configuration directly, so the system proxy toggle is not necessarily a prerequisite. Behavior depends on the version. When testing with a browser or external download tool, check separately that the system proxy, TUN mode, or the tool's proxy settings are active.
The rankings change every time. Should I keep switching automatically?
Keep test conditions consistent and record five results during both quiet and peak hours. If the difference is only a few milliseconds and success rates are similar, stick with the more stable node. Switch only if timeouts persist, performance noticeably stalls, or a service stops working—don't mistake normal variation for a failure.
If download speeds are fine, does that mean video and real-time calls will work too?
No. A download test mainly measures throughput for a specific resource. Real-time services are also affected by jitter, packet loss, UDP support, and app-specific routing. Test them briefly in the apps you actually use and note any interruptions; don't assume one download result applies to every type of traffic.
Final choice: prioritize reliability, then rank by latency or speed as needed
Keep one primary node and one tested backup. If something goes wrong, retest against the same target and check the app's traffic path. Change subscription or protocol settings only when the evidence points to the node configuration or server.