For v2rayN and v2rayNG connections that work but have slow page loads, low download speeds, or peak-hour stalls. Keep test conditions fixed, then compare nodes, networks, and local proxy settings to narrow down the cause. Change one variable at a time and record timings, errors, and results. This helps distinguish DNS delays, node congestion, and apps that are bypassing the proxy.
First, identify whether the issue is slow initial loads, low throughput, or frequent drops
The latency shown by a client is not the same as available bandwidth. A TCP connection test typically shows whether a port is reachable and how long the connection takes. “Real connection latency” also depends on the test URL, handshake, and response time. A node with low latency can still download slowly if its shared bandwidth is limited. Conversely, a long-distance route with higher latency may sustain fast large-file transfers.
| Symptom | Check first | How to compare |
|---|---|---|
| The first page load takes a long time, then loads normally | DNS, handshake, connection reuse | Request the same page repeatedly and compare the first and subsequent load times |
| Downloads remain slow | Node egress, route capacity, destination rate limits | Use the same file source and test two nodes, one at a time |
| Transfers stall periodically | Wireless interference, packet loss, connection timeouts | Keep the node fixed and switch access networks |
| Only one app is slow | App proxy settings, routing, the app’s own service | Compare the app with a request through an explicit proxy |
“Every site is slow” needs to be verified. Test at least two different sites, and compare web pages, small files, and sustained downloads. If only one destination is slow, keep the node unchanged and check the destination’s service status, regional endpoint, and routing match. Don’t assume the entire node is unusable.
Establish a repeatable speed-test baseline
Before testing, pause system updates, cloud sync, and other downloads. Record the client and core versions, node label, access network, routing mode, and time. In v2rayN, find the version under Help → About; check the core version in the startup log. Menu locations may vary across interface versions, so record the exact field names you see as well.
These are test parameters, not speed guarantees. In v2rayN, go to Settings → Parameter Settings to check the local listening port and confirm that the current proxy entry supports SOCKS. The example below uses Windows curl.exe. If your port isn’t 10808, replace it with the actual local port.
curl.exe --proxy socks5h://127.0.0.1:10808 "https://v2ray-group.com/zh-CN/index.html" --output NUL --silent --show-error --connect-timeout 10 --max-time 20 --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s\n"socks5h sends the destination hostname to the SOCKS proxy for resolution. It doesn’t mean the node server’s own hostname can skip local DNS resolution. This command is useful for checking whether small requests complete reliably, not for measuring bandwidth. For a SOCKS request, time_connect mainly measures the connection to the local proxy; it is not the network latency between the client and node. Time to first byte also includes proxy negotiation, the remote connection, and server processing.
Layer 1: Node load and egress limits
At the node layer, check whether different nodes perform consistently differently on the same access network. Choose two nodes with different egress points or service routes, then test each with the same destination, at the same time, and using the same method. Different node names don’t prove the underlying routes differ; multiple endpoints from one provider may also share egress bandwidth.
Keep the destination fixed
Use the same URL, file, and routing mode throughout. First confirm that the request uses the proxy outbound; otherwise, one test may be proxied while another is handled by a direct-connection rule.
Test nodes one at a time
In the v2rayN main window, select a node and choose Set as active server from the right-click menu. Wait for the core to reload before sending a request. Don’t run speed tests on multiple nodes in parallel.
Record the time of day
Test each node three times and record the median and number of failures. Run one round during the day and another in the evening to see whether performance drops noticeably only at certain times.
Check your plan limits
Check remaining data, expiration date, and speed limits on your service provider’s account page. Updating a subscription refreshes the configuration; it won’t increase node capacity or remove account-level speed limits.
If node A is slow across several destinations while node B works normally at the same time, suspect node A or its route before changing local DNS. If both A and B are slow only at the same download site, consider the site’s rate limits, restrictions on the node’s egress IP, or routing problems between the egress and that site.
Layer 2: Access network and route
Keep the node and destination fixed. Compare wired and wireless connections first, then compare home broadband with a mobile hotspot. A hotspot changes the carrier, address family, and route, so it can show that the access path matters—but it can’t prove that a specific hop is dropping packets. On Android, pause background updates and make sure you have enough data for the test.
- Check Wi-Fi: Test near the router, then compare with a wired connection. If wired is stable but Wi-Fi fluctuates, check signal strength, channel congestion, and competition from other local devices.
- Check time of day: If the same node slows consistently in the evening and recovers off-peak, congestion is more likely. Confirm with another node or network before drawing a conclusion.
- Check the route: Send 30 consecutive probes to your local gateway and check for LAN instability. A responsive gateway doesn’t guarantee a healthy internet route, and an intermediate router that doesn’t respond to probes isn’t necessarily dropping application traffic.
- Check the address family: Check which IPv4 or IPv6 addresses the node’s hostname resolves to. Compare one variable at a time, and only if the evidence points to an issue with a specific address family. Don’t disable address-family support system-wide without a reason.
VMess and VLESS are proxy protocol names, not indicators of route quality. Any transport change must also match the server configuration. Arbitrarily changing the port, TLS, SNI, or transport path will usually make a working node’s handshake fail; it won’t compensate for insufficient physical route capacity.
Layer 3: Local proxy entry, routing, and DNS
If an explicit SOCKS request works but your browser is slow, first check that the app uses the expected proxy entry. In v2rayN, System Proxy → Set system proxy automatically affects apps that use the system proxy settings. The routing mode determines how traffic is handled by the core. These are separate settings, and enabling the system proxy doesn’t mean every app will use it.
| Where to check | What to do | What to confirm |
|---|---|---|
| v2rayN system proxy | System Proxy → Set system proxy automatically | The browser and system settings point to the current client entry |
| Local listening port | Go to Settings → Parameter Settings, check the port, then compare it with the app’s proxy configuration | The app isn’t connecting to an old port or a different proxy process |
| Routing mode | Record the current mode, temporarily switch to Global for comparison, then restore the original mode | Whether the destination behaves differently because the original rule sends it direct |
| v2rayNG app scope | Go to Settings → Per-app proxy in the sidebar and check the toggle, mode, and app list | The app being tested is included in the intended proxy scope |
v2rayN’s TUN mode and system proxy can both be active, but don’t add another VPN or proxy app while troubleshooting. Save the current configuration, then test one traffic-capture method at a time. If you need a work VPN tunnel, check your company’s network requirements first; don’t delete existing network settings just to test.
Check DNS in layers too: resolving the node address determines whether the client can connect to the server; resolving the destination hostname affects where the request goes; the routing domainStrategy determines how DNS results are used for rule matching. These are separate settings. If only the browser’s first load is slow, compare its Secure DNS setting and record the original value. Don’t change system, client, and browser DNS settings all at once.
- Check the logs to see whether the destination connection uses the expected outbound before changing routing. In custom rules,
outboundTagmust match a defined outbound tag. - If your computer’s CPU stays near full load during transfers, pause other CPU-intensive programs and test again. Record the core process’s CPU usage too, so you don’t mistake a device bottleneck for a node issue.
- If an Android device disconnects mainly after the screen locks, check battery and background activity permissions under Settings → Apps → v2rayNG. Background restrictions usually affect connection continuity, not download speed while the app is in the foreground.
Use logs to distinguish slow responses from connection failures
Open the client log, repeat a fixed test, and find the corresponding entries by timestamp. For brief troubleshooting, set the log level to info. Use debug temporarily only if regular logs aren’t enough, then restore the previous level. Detailed logs may contain destination addresses and connection details; redact subscription URLs, UUIDs, and account credentials before sharing.
context deadline exceeded
Cause: An operation exceeded its time limit. This line alone can’t tell you whether the issue is the node, DNS, or the destination site.
What to do: Use surrounding log entries to identify the failure stage, then compare the same node with a different destination and the same destination on a different network.
connection refused
Cause: The connection was explicitly refused. The local proxy may not be listening, or there may be no service on the remote port.
What to do: Check the address in the error. If it’s 127.0.0.1:10808, verify the actual local port and core status. If it’s the node address, check the server-side port.
address already in use
Cause: On systems that use this error wording, it usually means another process is already using the listening address or port.
What to do: Close any duplicate client instance, or choose an unused port in Parameter Settings and update the app’s proxy configuration.
An EOF or connection-closed message in the log doesn’t automatically mean the server is throttling you. It could indicate a normal end, an early close by the remote host, or an interruption somewhere along the route. Investigate the entry further only if it recurs at the same stage for the same destination and lines up with failed requests.
Common questions and how to verify the results
Why are downloads slow when latency is only a few dozen milliseconds?
Latency measures round-trip or request time, not bandwidth. Choose a large file you’re authorized to download and test two nodes one at a time, three times each. If only one node stays slow, check its egress, account speed limits, and peak-hour load.
Global mode is faster. Can I leave it on?
Treat this first as a routing comparison. Check whether the destination used a direct connection in the original mode, then fix the relevant rule and restore the original mode. Before using Global mode long term, consider access to your LAN, work systems, and local services.
Can updating the subscription or changing the core fix slow speeds?
Update a subscription to apply address or configuration changes; it won’t increase the capacity of an existing route. Compare core versions only if you’ve confirmed a compatibility issue with a specific version, and keep the original configuration. Before switching cores, make sure they support the node’s protocol and transport settings.
Android is fast but my computer is slow. What should I check next?
Connect both devices to the same Wi-Fi network, node, and destination. On the computer, use an explicit SOCKS request first to rule out differences in system proxy and browser settings. Then check background traffic, core logs, and CPU usage.
Your final notes should capture the test conditions, not just say “switching nodes fixed it.” For example: on home broadband, node A timed out in all three evening tests to the same destination, while node B worked normally; A recovered on a mobile hotspot. This narrows the issue to the combination of node A and a specific access path, giving your service provider useful details to investigate.
- Keep: Test time, client and core versions, access network, node label, destination, and timings.
- Restore: Temporary Global mode, verbose logging, test DNS settings, and interface parameters.
- Retest: After restoring your usual settings, run the app that was slow and confirm the improvement isn’t limited to the test command.