For users who can connect but experience slow page loads, low download speeds, or interruptions. Keep the test target and proxy path fixed, then compare nodes, network connections, and local settings. Use repeated tests, connection logs, and one-variable comparisons to determine whether to switch nodes or networks, or adjust DNS, routing, or background restrictions.
First, identify whether the problem is slow page loads, low throughput, or disconnects
Low latency and slow downloads can happen at the same time. A node latency test may only check whether a TCP connection can be established, or it may connect to a specific URL, depending on the client. It does not measure sustained download throughput or indicate how every website will perform. Describe the symptoms clearly before troubleshooting to avoid blaming every issue on the node.
Every request passes through these stages. If a browser spins for a long time before loading, focus on DNS resolution, connection setup, and handshakes. If a download starts but remains slow, look at bandwidth, congestion, and packet loss. If the connection drops after the screen turns off, check background operation settings on the mobile device first. Don’t change the node, DNS, and proxy mode all at once; even if that fixes the issue, you won’t know which change helped.
| Symptom | Check first | How to compare |
|---|---|---|
| First visit is slow; reloads are faster | DNS, initial connection, TLS handshake | Record the time for the first and subsequent requests; check DNS and handshake logs |
| Large downloads stay slow | Node egress, route throughput, target site throttling | Try different targets with the same node, then different nodes with the same target |
| Slow at night, normal during the day | Shared egress or peak-hour congestion at the network provider | Keep the same settings and repeat tests at different times |
| Only one app is slow | Per-app proxy list, app-specific proxy settings, target service | Confirm which outbound connection the app actually uses |
| Disconnects when the screen turns off | Battery optimization, process state, network switching | Compare behavior in the foreground and with the screen off |
Set a baseline: keep the target and test conditions fixed
Pause system updates, cloud sync, and other high-bandwidth tasks first. Use a wired connection on desktop where possible, and stay in the same spot on mobile. Choose a webpage that loads reliably to check initial load time, then use the same download file that permits speed testing to measure sustained throughput. The recommendations below are test guidelines, not results measured by this site or default client settings.
-
Record your setup
In v2rayN, open “Help” → “About” and note the client version. Also record the core name and version, node name, routing mode, and whether TUN is enabled. Menu locations may vary between versions; check your current interface.
-
Check the inbound
Open “Settings” → “Parameter Settings” and check the local SOCKS or mixed listening port. The commands below use
10808as an example. Use it only if the current port actually provides a SOCKS service; otherwise, replace it with the correct port. -
Keep the route consistent
At the bottom of the main window, check the “System Proxy” and “Routing” selections. For browser tests, confirm that the system proxy is active. For command-line tests, specify the proxy explicitly rather than relying on whether an app uses the system proxy.
-
Keep a test log
For each run, record the time, network connection, node, target, time to first byte, and average speed. Test node A, then node B, and finally node A again to reduce errors caused by short-term fluctuations at the target site.
Mind the units: 8 Mbps is theoretically about 1 MB/s; actual throughput is lower due to protocol overhead. Don’t compare an ISP’s advertised Mbps directly with the MB/s shown in a download window, and don’t use a tiny webpage to estimate a route’s maximum bandwidth.
Layer 1: Check node egress and target compatibility
A successful node connection only confirms that authentication and the transport link basically work. Congested shared egress, overloaded server resources, or poor connectivity between the node and the target site can all slow things down. Start by comparing nodes with different egress points or routes. Two nodes with different names from the same provider may share an egress point, so their names alone don’t prove that the tests are independent.
- Same target, different node: Keep the local network, target, and test time the same, then compare two available nodes. If one node is consistently slower, check its egress, quota, or server load first.
- Same node, different target: If webpages load normally but one download site is slow, the site may be throttling downloads or have poor connectivity to the node’s egress. That alone doesn’t indicate a client problem.
- Separate bandwidth from latency: A nearby region may respond quickly without offering more egress bandwidth. A distant node may have higher latency yet deliver more consistent throughput.
- Check configuration consistency: Verify that the server port, transport type, TLS,
serverName, and transport path match the provider’s settings. Don’t change these fields at random to “speed things up.”
v2rayN is a desktop client; the selected core handles the actual connection. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. When troubleshooting compatibility, confirm that the current core supports the configuration fields in use. Comparing cores is useful only when the server configuration supports both; switching cores isn’t a universal way to speed things up.
Layer 2: Separate local network issues from route issues
If the same node is slow on home broadband but fast over a mobile hotspot, the issue may lie somewhere between the access network and the node, but that doesn’t prove the ISP is at fault. Switching between a hotspot and home network also changes the wireless environment, egress, and network path. Narrow it down by using Ethernet to rule out Wi-Fi interference, then switching networks on the same device.
| Change only | What to look for | Next step |
|---|---|---|
| Switch from Wi-Fi to Ethernet | Speed improves and becomes more stable | Check the Wi-Fi channel, signal strength, and router load |
| Switch from home broadband to a hotspot | The same node is noticeably faster | Compare different times and share route differences with your network or node provider |
| Switch from evening to off-peak hours | Performance improves across most targets | Check for peak-hour congestion first, then cross-check with another route |
| Switch the target | Only one target remains slow | Check for target-site limits, egress region, and connectivity |
Packet loss triggers TCP retransmissions and reduces throughput; latency spikes can also make interactive use feel sluggish. But a failed ping doesn’t mean the proxy port is unreachable: intermediate devices may block ICMP. A router that doesn’t respond to traceroute alone doesn’t prove it is dropping application traffic. Base your conclusions on end-to-end connectivity, app behavior, and repeated tests.
Layer 3: Check DNS, routing, and local resources
The system proxy lets apps that support it connect to the local client. Routing rules then choose the outbound connection. These are separate layers. Switching to global routing won’t force an app that ignores the system proxy to connect. During testing, confirm both which inbound the traffic uses and which outbound is selected.
- DNS: If the first visit is slow, check the logs for repeated DNS timeouts. In v2rayN, open “Settings” → “DNS Settings” and review the current configuration. Distinguish between resolving the node’s domain and the target domain. Changing the system DNS alone doesn’t mean the core’s DNS behavior has changed.
- Routing: Check the order of custom rules and the outbound tag shown in the logs. If a target is mistakenly sent through a direct connection, changing proxy nodes won’t help. Sending a local service through a remote node when it could connect directly can also add latency.
- TUN: First verify the basic route using an app with an explicitly configured proxy, then test TUN separately. Avoid running multiple networking tools that compete for the default route or virtual network adapters.
- Resources: Check core process CPU, memory, and network throughput in Task Manager. Consider device performance or configuration overhead only if CPU usage is consistently a bottleneck while the slowdown occurs.
- Logs: Temporarily increase the log level for troubleshooting, then restore your usual setting. Leaving verbose logs on can increase disk writes and make important errors harder to spot.
The Windows command below compares connection setup and time to first byte; it doesn’t measure maximum download speed. It accesses this site’s homepage through a SOCKS proxy and resolves the target domain on the proxy side, so it can’t test the browser’s local DNS path. First confirm that 127.0.0.1:10808 is providing a SOCKS service.
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://v2rayhost.com/On macOS or Linux, use curl and replace NUL with /dev/null. These timings are cumulative from the start of the request and shouldn’t be added together. time_connect mainly reflects the time to connect to the local proxy; it isn’t node latency. Compare repeated runs with the same command and target instead of relying on a fixed “acceptable” number of seconds.
Use logs to pinpoint connection failures and delays
Slowdowns often involve retries: the first requests fail, then a later one succeeds, so the page simply appears to load slowly. Log messages vary by core and operating system; the examples below are common snippets. First identify whether the error concerns the local inbound, the node address, or the final target, then decide where to investigate.
Error: connection refused
Cause: The connection to the target port was refused. If the target is a local address, the core may not be running or the port may be wrong. Fix: Check the address and port in the error, then confirm that the local service is listening. If the error points to the node, verify the server port and service status.
Error: i/o timeout
Cause: A network read or write timed out. This snippet alone can’t tell you whether the route is blocked, the server isn’t responding, or DNS resolution is delayed. Fix: Keep the surrounding log lines and timestamps, then change the node or network one at a time to identify which layer is timing out.
Error: TLS handshake timeout
Cause: The TLS handshake didn’t complete in time. The cause may be route quality, server response, or the connection target. Fix: Identify which TLS connection is involved, then check the server port and serverName. Don’t disable certificate verification as a substitute for troubleshooting.
Before sharing logs, remove subscription URLs, user identifiers, authentication details, and other sensitive parameters. When reporting an issue, include the time it occurred, client and core versions, network type, relevant error lines, and comparison results. That’s usually more useful than a screenshot showing only a slow speed.
FAQs and final troubleshooting checks
Why does video still buffer when latency is only a few dozen milliseconds?
A latency test doesn’t measure sustained throughput for video segments. Fix the playback resolution and check whether the buffer keeps shrinking. Then try other targets with the same node and switch nodes for the same target to distinguish node egress issues from the video service’s network path.
It got faster after switching to global mode. Was bypass mode the problem?
First check which rule matched the target and which outbound was selected. Global mode may have sent a target through the proxy instead of directly, or changed the DNS resolution path. Fix the specific rule that matched incorrectly; that’s easier to maintain than permanently redirecting all traffic.
v2rayNG gets slow after the screen turns off but recovers when it turns back on. What should I do?
On Android, open “Settings” → “Apps” → “v2rayNG” → “Battery” and allow background activity using the available system options. Also check background data permissions. Then open v2rayNG “Settings” → “Per-app proxy” and check the target app’s list mode. Battery menu names vary by device.
Will updating the subscription automatically fix slow speeds?
An update may help directly only if the provider has changed a node address, port, or available configuration. Save the details of any working nodes before updating. If multiple nodes are slow on the same network, investigate the local connection and route instead of repeatedly refreshing the subscription.
After troubleshooting, undo temporary changes: restore any unnecessary global routing, reset the log level, remove test rules, and keep a stable configuration. For more on the underlying concepts, see the proxy, routing, and DNS sections in the user guide. For specific settings questions, consult the FAQ.
- Only one node is slow: Check the node’s egress, quota, or connectivity to the target first.
- Switching networks fixes it: Check the local wireless environment, access network egress, and route first.
- Explicit proxy is fast, but the browser is slow: Check the system proxy, browser settings, and DNS resolution path first.
- Works in the foreground but disconnects in the background: Check battery restrictions, process state, and network switching first.