If you can connect but pages load slowly, first distinguish a slow connection setup from slow ongoing downloads. Then keep the test target fixed and compare nodes, network connections, and local settings in turn. This guide is for v2rayN, v2rayNG, and v2flyNG users who have already imported nodes. Recording results at each step helps narrow down the cause and avoid mistaking network congestion for a client configuration issue.
Start with a baseline: latency isn’t download speed
A low TCPing result only means a TCP connection to the specified address and port was established quickly. It doesn’t prove that proxy authentication, the TLS handshake, or access to the destination website will succeed. A real-connection speed test typically sends a request to a test URL through the proxy, making it closer to an actual visit. However, results still depend on the test URL, timeout threshold, and caching, so they can’t be directly converted into video or file download speeds.
Pause cloud sync, system updates, and other downloads, then test the same resource each time. Record the network type, node, test time, and any errors. The figures below are recommended test conditions and unit conversions—not measurements of any node by this site.
The MB/s shown by your browser and the Mbps listed for your internet plan are different units. Also distinguish between “the first page takes a long time to load, but downloads are fine afterward” and “the connection is quick, but downloads remain slow.” For the first, check DNS resolution, the handshake, and routing. For the second, check bandwidth, congestion, and the node’s exit capacity.
- Only one website is slow: Test a second site from a different provider to rule out destination-side throttling, regional policies, and CDN differences.
- All sites through the proxy are slow: Compare nodes and network routes. Don’t start by changing all your DNS settings.
- Direct connections are slow too: Check local Wi-Fi, broadband usage, and your router before assessing proxy performance.
Layer 1: Use comparisons to check for node load
Client speed isn’t determined by whether the protocol is called VMess or VLESS. Server CPU, outbound bandwidth, concurrent connections, and provider throttling can all become bottlenecks. A region in a node’s name doesn’t guarantee its actual entry route, and nodes with different names may share the same entry or exit point.
-
Keep the test target fixed
Choose a sufficiently large HTTPS resource that allows speed testing, and use the same browser or command-line tool each time. Don’t run multiple speed tests at once; they’ll compete for bandwidth on the same connection.
-
Select the active node
In the v2rayN server list, select a node and right-click it, then choose “Set as active server.” Confirm that the active item has changed before testing. Highlighting a row in the list doesn’t necessarily switch nodes.
-
Test a real connection
In the server list, right-click and choose “Test server real connection latency.” Wording may vary between versions. Choose a real-connection test, not just a TCP connection test, and record the number of timeouts and successful attempts.
-
Switch nodes for comparison
Switch to a node with a different entry point or network route. Keep the network, target, and tool unchanged, and test three times on each node. Repeat at another time of day to avoid drawing conclusions from a one-off result.
If one node stays slow on the same network while other entry points perform normally, the problem is more likely with that node or its route. If speeds are normal during the day but drop across the board in the evening, you can only conclude that the issue is time-related congestion. Client-side results alone can’t tell you whether the cause is server load or the ISP’s route; you’ll need server monitoring or more route samples.
Layer 2: Separate your local connection from the remote route
Keeping the node unchanged and switching networks is a low-cost way to test. For example, connect a computer to a phone hotspot instead of home Wi-Fi, or compare Wi-Fi and mobile data on an Android device. Mobile data tests use your data allowance, so limit file size and test duration. Change only the network—not the node and DNS at the same time.
| What you observe | Most likely cause | Next test |
|---|---|---|
| The same node is fast on a hotspot but slow on home internet | Local connection or the ISP’s route to the entry point | Connect your computer by Ethernet, pause downloads on other devices, then test the same node again |
| All nodes are slow on the same network | Local bandwidth, a shared entry point, or the test target | Test a direct connection first, then try different entry points and targets |
| Ongoing downloads slow down only in the evening | Route congestion or competition for a shared exit | Record results for the same target at different times, then compare other routes |
| Only one target is slow | The destination service, the route from the exit to the destination, or the CDN | Retest with another target; don’t assume the entire node is unusable |
On Windows, use ping -n 20 to test the default gateway; on macOS, use ping -c 20. Find the gateway address in your current network details. If packets are frequently lost even to the local gateway, address Wi-Fi signal issues and device load first. Remote servers may restrict ICMP, and a hop that doesn’t respond during a traceroute doesn’t mean application traffic is being lost there.
- On Wi-Fi, move closer to the access point. If possible, switch to a wired connection to rule out wireless interference.
- Use traceroute only as a clue about the route. Judge the connection by the actual HTTPS request as well, not by packet loss at an intermediate hop alone.
- If only some large pages or long-lived connections stall, consider issues such as path MTU. Don’t change network adapter settings wholesale without evidence.
Layer 3: Make sure your app is actually using the proxy
The system proxy affects only apps that honor that setting; it doesn’t guarantee that every app will use the proxy. Tun mode routes traffic through a virtual network interface, but routing and exclusion rules still apply. Don’t mix these two connection methods when troubleshooting. First identify which one your test uses, then check which outbound connection the request actually matched.
In v2rayN, check the local listener under “Settings” → “Parameter settings,” then review the rules under “Settings” → “Routing settings.” Menu labels may vary by version; use the options shown in your current interface. The examples below assume the local SOCKS listener is 127.0.0.1:10808. This is only an example; replace the port with your actual one before running the commands.
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output /dev/null --silent --show-error --write-out "connect=%{time_connect} start=%{time_starttransfer} total=%{time_total} bytes_per_second=%{speed_download}\n" https://example.com/The commands above work in the macOS and Linux shell. In Windows PowerShell, use curl.exe and replace /dev/null with NUL. example.com is only for checking that a request works; the page is too small to assess sustained bandwidth. For a download test, use a stable large file URL that you’re authorized to access.
socks5hsends the destination hostname to the proxy for resolution instead of having curl resolve it locally first. The DNS method ultimately used still depends on the core configuration.- Here,
time_connectmainly reflects the time to connect to the local proxy entry point, not the full remote handshake. Time to first byte also includes processing time at the destination. - If a request through an explicitly configured proxy works but the browser is slow, check the browser’s own proxy settings, extensions, and secure DNS before switching nodes.
- For troubleshooting, you can temporarily use the client’s global proxy routing as a comparison, then restore your original rules when you’re done. “Set system proxy” and “global proxy routing” operate at different levels.
Transport, Mux, and DNS: Change one setting at a time
Transport requires server-side support. WebSocket, gRPC, and other transports supported by the core don’t have a universal speed ranking across networks. Reverse proxies, connection keep-alive policies, and route quality all affect results. Compare valid configurations provided by your service; don’t switch transport types on a single node just to run a speed test.
| Setting | Possible effect | How to test |
|---|---|---|
| Mux connection multiplexing | May reduce the overhead of establishing multiple connections, but multiple requests can also be affected by packet loss on the underlying connection | Confirm that your core and protocol support it. Test with Mux both off and on; don’t simply crank up the concurrency |
| DNS and resolution route | Slow resolution can delay the first connection, and different resolved addresses may lead to different CDN routes | Keep the node unchanged. Compare the first visit with repeat visits, and check the resolution logs |
| Routing rule order | An earlier matching rule may send the destination direct or through a different outbound | Check the destination domain, IP conditions, and outbound tag; review the logs to see which rule actually matched |
| Local resource usage | High CPU or network usage from the core, other apps, or security software can limit throughput | Check CPU and network usage during a download, then pause other workloads and test again |
Mux isn’t a bandwidth multiplier and can’t increase the capacity of a single route. Start with Mux off to establish a baseline, then compare two types of load: many short requests and one large file. Some combinations of protocol, transport, and core have specific multiplexing limitations, so don’t copy old settings across every node.
DNS usually affects resolution and initial connection time more directly; it won’t magically speed up a large file transfer that’s already underway. But a different DNS result can change which CDN address you reach, so DNS still matters. Before switching resolvers, note your current settings and check whether the resolver itself depends on a proxy connection that hasn’t been established yet. Otherwise, the dependency can lead to timeouts.
Log errors: Fix connection failures before judging speed
The following are examples of errors that may appear in logs; full prefixes vary by system and core. Errors can help narrow down the issue, but rarely prove a root cause on their own. Note when the error occurred and which node was active. Before sharing logs, remove subscription URLs, credentials, and personal network details.
connection refused
Cause: The destination address actively refused the connection. The local core may not be listening, or the remote service may be down. Fix: Check the address in the error first. For a local address, check the listening port and core status; for a remote address, verify the node port and service status.
i/o timeout
Cause: A read or write operation exceeded its timeout. The issue may involve DNS resolution, the route, or the destination response. Fix: Use nearby log entries to identify which stage timed out, then compare the same node on a different network and different nodes on the same network. Increasing the timeout doesn’t make the connection faster.
address already in use
Cause: Another process is already using the local listening port. Fix: Close duplicate instances, or confirm which program is using the port before changing it. Apps configured to use the proxy explicitly must be updated to use the new port too.
x509: certificate has expired or is not yet valid
Cause: The system clock is incorrect, or the server certificate is outside its validity period. Fix: Sync the device’s date, time, and time zone. If the error persists, ask the service provider to check the certificate instead of disabling verification.
Common questions and final checks
Why does video still buffer when latency is low?
A successful short request doesn’t guarantee stable throughput over time. Keep the video quality fixed and watch the playback buffer, then test another destination through the same node. If only one video service is slow, focus on the route from the node’s exit to that service. Don’t rank nodes by latency alone.
Mux made things slower. Should I increase concurrency?
Turn Mux off to return to your baseline, then test the same target three times. If performance is consistently better with Mux off, leave it off and check whether your core and server combination supports multiplexing. Increasing concurrency isn’t automatically the right next step.
What if speeds drop after my Android screen locks and recover when it turns back on?
First check whether v2rayNG or v2flyNG stays connected. Then, in the system app settings, allow the app to run in the background under battery management. Test the same node with the screen on and locked. If the issue occurs only in the background, check battery restrictions and conflicts with other VPN services first.
Can updating the subscription fix slow speeds?
Updating the subscription can fetch addresses and settings changed by the service provider, but it won’t increase bandwidth on its own. After updating, check whether the active node changed, then compare using your original test conditions. If a node was replaced, record it as a new test subject.
Keep a short record of the node, network, target, time of day, and results before and after each change. A difference you can reproduce is more useful than one impressive speed-test result. If nodes perform alike, check the route; if routes perform alike, check the local entry point, routing, and DNS. Retest after each change, and revert anything that doesn’t help.