For users who can connect but experience slow page loads, low download speeds, or intermittent disconnections. Keep the test target constant, distinguish connection time from download speed, then narrow down the cause by switching nodes or networks and checking proxy settings and logs. Commands and ports are labeled with their purpose. Latency is not bandwidth, and not every slowdown is a protocol issue.
First, identify the problem: slow connections, downloads, or background disconnections
“Slow speeds” can describe at least three different problems. A long blank screen after opening a page may point to DNS resolution, connection setup, or a slow server response. If the page loads right away but large downloads crawl, throughput is more likely the issue. If Android works with the screen on but disconnects when locked, check background restrictions first. Each case calls for different evidence; a single latency reading in the node list won’t tell you enough.
| Symptom | What to record first | What to check first |
|---|---|---|
| First page load is slow; reloads are faster | Time for the first request versus repeat requests | DNS, handshakes, connection reuse, and caching |
| Pages load, but large downloads are slow | Sustained download speed for the same file | Node load, outbound bandwidth, and network congestion |
| Only one site is slow | Whether the other two test targets work normally | Target site limits, exit region, and routing rules |
| Disconnects when the screen locks | Whether the connection resumes as soon as the screen turns on | Android battery optimization and background permissions |
Before testing, pause cloud sync and downloads that are using bandwidth. Use the same device, target, and network each time. Repeat each test three times and note the time and any failures. Don’t compare a browser cache hit, a multi-connection speed test, and a single-connection download: they measure different things.
Layer 1: Use controlled tests to check node load
A successful connection only shows that a working route was available at that moment. The server’s CPU, outbound bandwidth, concurrent connections, or upstream network may still be bottlenecks. Clients usually can’t see these server-side metrics, so run controlled comparisons rather than assuming a timeout proves the server is overloaded.
-
Keep the test target constant
Choose the same HTTPS page or downloadable file that you’re authorized to access, and note when you test. First check that common sites also load normally with the proxy off; if not, troubleshoot your home or mobile network first.
-
Switch to another node
In the v2rayN main window, select another configuration in the node list, right-click it, and choose “Set as active server” before testing again. Prefer a node with a different exit route, not just a different name for the same server.
-
Test other targets too
Keep the node the same and try two other targets. If only one site is slow, the cause may be that site’s rate limits, CDN routing, or the route from the exit node to that site. That alone doesn’t indicate poor overall node performance.
-
Compare different times
Repeat the same tests at another time. If multiple targets all slow down during busy periods, shared resource limits or route congestion are worth investigating. Server monitoring is still needed to confirm the specific load issue.
If speeds recover as soon as you switch nodes, the issue is related to the original node or its network path, but this alone can’t distinguish a busy server from route congestion. Servers in the same region may use different peering providers, so geographic proximity doesn’t guarantee a shorter network route. Keep the original configuration and continue with the next layer of tests; changing the node, protocol, and DNS all at once makes it harder to identify the cause.
Layer 2: Switch access networks to isolate route issues
Proxy traffic travels along two routes: from your device to the node, then from the node to the target site. Interference on home Wi-Fi, congested ISP peering, and packet loss between networks can all reduce effective throughput. After packet loss, TCP retransmits data and adjusts its sending rate. Speeds may repeatedly rise and fall instead of staying consistently low.
- Switch networks on the same device: Keep the same node and target, then switch your computer from home internet to a phone hotspot. If the hotspot works but home internet remains slow, check the router, Wi-Fi link, and fixed broadband route first.
- Change the connection on the same network: If possible, use a wired connection or test closer to the router. If the issue occurs only over Wi-Fi at a distance, there’s no need to change protocol settings first.
- Separate latency from bandwidth: A node with low latency may have a congested exit, while a higher-latency node may sustain steady downloads. Pair connection tests with tests that reflect your actual use.
- Interpret probes with care: A node not responding to ICMP doesn’t mean the proxy is unusable. Packet loss at an intermediate hop followed by normal responses at later hops often means a router is limiting probe responses—not that application traffic is being lost.
Layer 3: Check the proxy entry point, routing, and DNS
v2rayN provides the client interface; the selected core handles the actual connection. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. A protocol works only if the client core is compatible with the server configuration. VMess and VLESS are protocol types, not speed tiers. Simply renaming a server’s VMess configuration to VLESS won’t make it faster.
- Check the system proxy: In Windows, open the v2rayN tray menu and go to “System Proxy” → “Automatically configure system proxy.” This affects apps that follow the system proxy settings; it doesn’t mean every program will use the proxy.
- Check the local listener: In v2rayN, open “Settings” → “Parameter Settings” to check the local listening port and entry type. Field names may vary between versions. The command below works as written only if a SOCKS or SOCKS-enabled mixed entry is actually listening on
127.0.0.1:10808. - Use one test path at a time: Pause system proxy or virtual network adapter handling by other proxy apps. Manual proxy settings and TUN mode can coexist without causing issues, but reduce variables while troubleshooting to avoid routing loops or duplicate traffic handling.
- Check the actual routing rule: Confirm that the target request uses the proxy outbound route rather than a direct connection. A browser may reuse an old cached connection, so establish a new connection after changing rules before testing again.
DNS can happen at different points. The node’s hostname must be resolved first, while the target site’s hostname may be resolved locally, by the proxy core, or remotely. Changing DNS can only help with the relevant resolution step; it won’t fix bandwidth limits on the server’s outbound connection. If only the first page load is slow, check the logs for resolution errors before changing the relevant DNS route.
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}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/This is a diagnostic example, not a test result from this site. Replace the target with an actual HTTPS URL you’re authorized to test. In Windows Command Prompt, use curl.exe and replace /dev/null with NUL. socks5h tells the SOCKS proxy to resolve the target hostname; this follows a different test path from local DNS resolution.
Log errors: distinguish connection failures from slow transfers
Open the client’s log panel, reproduce the issue once, and note the errors at that time. Timeouts, certificate failures, and port conflicts require completely different fixes. Here are some common error snippets. The surrounding log context is still essential; don’t change every setting based on a keyword alone.
i/o timeout
Cause: A network read or write operation timed out. Possible causes include the route to the node or target, filtering, or a slow server response. Fix: Check the address and outbound route associated with the error. Compare the same node on another network and the same network with another node. A timeout doesn’t automatically mean there’s a DNS problem.
connection refused
Cause: The target refused the connection, often because nothing is listening on that port or the connection was actively rejected. Fix: If the address is a local loopback, check that the client core is running and the port matches. If it’s a remote node, verify the node port and contact the server administrator.
address already in use
Cause: Another process is already using the local address and port the client needs to listen on. Fix: Close duplicate client instances or choose an unused listening port, then update the port in your system proxy and app settings.
x509: certificate has expired or is not yet valid
Cause: The device clock is incorrect, or the server certificate is outside its validity period. Fix: First sync the system date, time, and time zone. If they’re correct, ask the server administrator to renew the certificate. Don’t bypass certificate verification to hide the problem.
If you temporarily increase log verbosity, restore the normal level after reproducing the issue. When sharing logs with an administrator, include the time, error type, and failure stage, but redact subscription URLs, user IDs, and credentials. Subscription URLs often contain access credentials and shouldn’t be posted in public forums.
Android checks: VPN permissions and background restrictions
If desktop connections are fine but v2rayNG or v2flyNG disconnects intermittently on Android, check the device itself. Both apps can route traffic through Android’s VpnService. A VPN icon only shows that the VPN service exists; it doesn’t guarantee a successful connection to the proxy node or that the target app is included in the proxy.
Works with the screen on but stops receiving messages when locked?
On Android, go to “Settings” → “Apps” → “v2rayNG” or “v2flyNG” → “Battery,” then set background usage to “Unrestricted” or the equivalent option on your device. If the system has a separate auto-start setting, allow the app there too. Menu names vary by manufacturer. After changing the settings, test by locking and waking the screen.
Only one app is slow, but your browser works fine?
In the client’s “Settings,” check the “Per-app proxy” list and current mode. The selected apps may be the ones routed through the proxy, or they may be excluded in bypass mode. Check the on-screen description to confirm, then restart the VPN service and test again after making changes.
No system VPN icon after tapping Connect?
Stop any other app currently using the system VPN, then start the client and approve the system VPN connection request. If the VPN still doesn’t start, check the client logs and system VPN settings. Fix the service startup issue before changing the speed-test target.
Web pages load, but voice calls and games are unstable?
These services may rely on UDP. Check that the routing rules, protocol, and server-side path support the traffic. A working TCP web connection doesn’t prove UDP is available. Note the app and the specific failure, then inspect the configuration instead of changing the MTU blindly.
Narrow down the cause: change one setting at a time
The goal isn’t to find a universal set of “speed boost” settings; it’s to build a repeatable chain of evidence. Randomly changing the MTU, concurrency, connection reuse, or transport method can alter the symptoms or introduce new compatibility problems. Keep a working baseline, then change one setting at a time based on evidence so you can tell whether it helped.
- Only one node is slow: Record how that node performs against multiple targets, then compare with the server load, exit route, and network path.
- The same node is slow on only one network: Check the access network and ISP route first; there’s no need to rush into reinstalling the client.
- Explicit SOCKS requests work, but the browser doesn’t: Check the system proxy, browser proxy settings, extensions, and routing differences.
- First requests to every target are slow: Separate DNS resolution time, handshake time, and server time to first byte. Don’t switch protocols based only on total request time.
- Only Android background connections drop: Recheck battery management, background permissions, and VPN service status, then test again with the screen locked.
At a minimum, record the client name and exact version, selected core, network type, time of the issue, target type, and relevant error messages. Don’t publish your full configuration just to share logs. If you need to reinstall or review the setup steps, use the download page and guide below. Restore a standard connection before continuing with performance tests.