Use this process for slow page loads, fluctuating download speeds, frequent video buffering, or sudden latency spikes. Fix the test conditions first, then check the node, access route, and local settings in order. Change one variable at a time and use latency, packet loss, throughput, and logs to choose the next step.
Establish a Repeatable Speed Baseline First
Switching nodes repeatedly makes the cause difficult to isolate. If the node, test time, target site, proxy mode, and Wi-Fi conditions all change together, restored speed will not tell you which adjustment worked. Before testing, stop file synchronization, software updates, and any task using upstream bandwidth. Keep the test device in the same position on the network.
Measure at least three values: connection establishment time, average sustained throughput, and the amount of variation over ten minutes. Low latency only means fast round-trip responses; it does not indicate greater usable bandwidth. A node with 65 ms latency may sustain only 8 Mbps, while another at 120 ms may consistently reach 45 Mbps.
Use the same large file or continuous transfer task for three rounds, keeping each round above 60 seconds with 30-second gaps. Do not judge performance by the peak during the first few seconds. Browser caching, brief server bursts, and client statistics refresh intervals can all make short-term speeds look higher.
| Metric | Recommended sample | What it tells you |
|---|---|---|
| True connection latency | Run 5 consecutive tests and record the median | Filter out one-off handshake spikes |
| Sustained throughput | 60 seconds per round, 3 rounds total | Assess node bandwidth and route stability |
| Packet loss rate | Send 50 to 100 probe packets | Identify access-network or intermediate-route issues |
| Test period | Test once during the day and once in the evening | Confirm whether congestion occurs at regular peak hours |
Logging tip: Record the client version, core version, proxy mode, and current network at the same time. For example: “v2rayN 7.x, Xray core, system proxy, Wi-Fi, HTTP port 10809.” Do not guess versions; copy the exact values shown on the client’s About page or at the start of its log.
Layer 1: Determine Whether One Node Is the Problem
The node layer is the easiest to verify. Choose two or three nodes from the same subscription group with similar regions but different server addresses. Keep the local network, protocol type, and test target unchanged. In v2rayN, select a node in the server list and run “Test server real connection latency.” On Android, run a connection test from the node list in v2rayNG or v2flyNG.
If only one node remains slow while the others perform normally across three rounds, the issue is usually that node’s server load, port reachability, or outbound bandwidth. If every node in the same region slows in the evening and recovers during the day, peak-hour route congestion is more likely. If every region and protocol is slow, move on to checking the access route and local settings.
- Update the subscription once to make sure you are not still using an old node configuration that has been changed or deactivated.
- Select at least 3 nodes using the principle of similar regions and different servers.
- For each node, run 5 true connection latency tests, followed by 3 rounds of sustained transfer.
- Record both the average speed and the slowest round; do not rank nodes by their highest instantaneous speed.
- Reconnect to the most stable node, then retest the application that was originally slow.
| Example Test Results | Median latency | Throughput across 3 rounds | Initial conclusion |
|---|---|---|---|
| Node A | 72 ms | 7、9、6 Mbps | Normal latency but limited bandwidth |
| Node B | 89 ms | 38、41、39 Mbps | Stable; suitable as a baseline |
| Node C | 210 ms | 0、18、2 Mbps | Noticeable connection instability |
Conclusion: Stable throughput matters more than the lowest latency
Node B has 17 ms more latency than Node A, but the difference across three rounds is only 3 Mbps, making it better for downloads and video. Node C’s peak speed is not low, yet two rounds were nearly unusable. Check for packet loss on the route or excessive server load first.
Node parameters must also match completely. For VMess, the user ID, port, transport, and TLS settings must match the server. VLESS may also involve Reality, flow control, and the server name. A mismatch usually causes connection failures, but repeated retries at the transport layer can also appear as pages waiting for a long time or extremely low speeds. Do not modify protocol fields delivered by the subscription just to chase higher speeds.
Error: context deadline exceeded
Cause and fix: The connection or request did not finish within the allotted time—switch to another node in the same region, then check whether the current route has high packet loss.
Error: dial tcp: i/o timeout
Cause and fix: The TCP connection to the server address and port timed out—verify the node port and test again on another network to distinguish an unreachable node from a local route problem.
Error: connection reset by peer
Cause and fix: The remote end or an intermediate device reset the connection—update the subscription and reconnect. If several nodes show the same error, continue checking the access route.
Layer 2: Check the Access Network and Intermediate Route
When several nodes slow down at once, do not change advanced client settings yet. Move the same device from Wi-Fi to Ethernet, or test on another available access network. If speed immediately returns without changing the node configuration, the problem is in the local access network or carrier route before the client, not in the subscription.
Common Wi-Fi causes include signal attenuation, co-channel interference, and upstream congestion. Even when a speed test shows ample download bandwidth, a saturated upload can delay TCP acknowledgments and proxy handshakes. During testing, move closer to the access point, prefer the 5 GHz band, and pause heavy uploads on other devices.
ping -n 50 1.1.1.1
pathping 1.1.1.1
powershell Test-NetConnection 1.1.1.1 -Port 443These commands only help observe basic connectivity from your local network to public targets; they cannot replace node speed tests. On Windows, if 50 probes show 0% packet loss and most latency values fall between 10 and 30 ms, local access is generally stable. If loss reaches 3% or more, or latency repeatedly jumps from 20 ms to 300 ms, address Wi-Fi interference, router load, or the access route first.
- Slower at a regular time: Retest from 20:00 to 23:00 for three consecutive days. If daytime performance is normal but evening performance drops, peak-hour congestion is the likely cause.
- Recovers immediately on another network: With the node and client configuration unchanged, investigate the access route first.
- Instability at the first gateway: Check the Wi-Fi signal, Ethernet cable, router load, and background uploads.
- Stable basic connectivity but node timeouts: Compare servers in different regions and ports instead of repeatedly reinstalling the client.
Note: Do not treat one command result as a route diagnosis. Save one data set when speeds are normal and another when they are slow, using the same network, device, and test target each time.
Layer 3: Review the System Proxy, TUN, and Routing Rules
Once the node and access route are healthy, check local settings. First confirm that the target application is actually using the proxy. v2rayN commonly uses local SOCKS port 10808 and HTTP port 10809; use the current values under “Settings” → “Parameters” as the source of truth. Browsers using the system proxy generally use the HTTP port, while applications configured manually for SOCKS must use the corresponding SOCKS port.
If an application still points to an old port, the connection may fail outright. If another program has claimed the same port, the core may fail to start or keep retrying. Open the v2rayN log and first confirm that inbound listening succeeded, then check whether requests from the target appear. On Android with v2rayNG or v2flyNG, stop the connection and start it again to clear an old virtual network session.
Error: bind: Only one usage of each socket address is normally permitted
Cause and fix: The local listening port is already in use—close the program occupying 10808 or 10809, or change the port under “Settings” → “Parameters” and restart the core.
Error: failed to find an available destination
Cause and fix: The outbound server address could not be resolved—check that the node address is complete, switch DNS settings, restart the core, and reconnect.
Error: no such host
Cause and fix: The node or target domain could not be resolved—verify the system time and DNS availability, then update the subscription to rule out an outdated address.
Split tunneling can also make “only some websites slow.” Rules typically use domains, IPs, processes, or inbound tags to send traffic through direct, proxy, or blocked outbounds. If the target domain is mistakenly sent direct, the application may keep waiting; if a local service is mistakenly proxied, traffic takes an unnecessary detour. Temporarily switch to global proxy mode for comparison to quickly determine whether rule matching is involved, then restore the original split-tunneling setup.
- Test once in system proxy mode and record the initial page-load time and sustained speed.
- Disable the system proxy, then test with TUN mode alone to avoid interference from two simultaneous traffic-capture methods.
- Temporarily switch the routing mode to global proxy. If a specific website clearly recovers, inspect the rule matched by its domain.
- Restore the original routing mode, move the conflicting rule in the order, reconnect, and test again.
- Check inbound, matched-route, and outbound tags in the log to confirm that requests follow the intended path.
TUN mode takes over more applications that do not read system proxy settings, but it also adds three checkpoints: the virtual network adapter, DNS, and routing table. Use TUN for comparison when the browser is fast but games or command-line tools are slow. If the system proxy already covers the target application, there is no need to force-enable TUN just for a speed test.
How Protocols, DNS, and Device Resources Affect Speed
VMess or VLESS is only one part of a proxy connection. Actual performance also depends on the transport layer, TLS, server entry point, and route quality. The protocol name alone cannot tell you which is faster. With the same server, route, and similar parameters, the difference may be small; incorrect transport settings, however, can cause retries and extra handshakes that significantly slow access.
DNS issues usually appear as a long wait before the first page opens, while download speed is normal once the connection is established. Check the log for repeated DNS timeouts, then review the system DNS, client DNS, and routing rules for conflicts. After changing DNS, restart the core and reconnect, or old cache entries may continue affecting the result.
| Symptom | Check first | Comparison test |
|---|---|---|
| Slow initial load, stable after downloading | DNS resolution and handshake | Change DNS and restart the core |
| All traffic remains slow | Node load and route bandwidth | Switch to a node with a different server address |
| Speed periodically drops to zero | Packet loss, Wi-Fi interference, device load | Use Ethernet and pause uploads |
| Only a specific application is slow | Proxy source and matched route | Compare system proxy and TUN mode |
| CPU stays near 100% after connecting | Device resources and concurrent tasks | Retest after stopping concurrent downloads |
Conclusion: Choose the troubleshooting layer by symptom; do not change the protocol and routing at the same time
For a slow initial load, check DNS first. For consistently slow speeds, check the node and route. When only some applications are slow, verify the traffic entry point first. Change one setting per round and keep before-and-after data so you can tell whether an adjustment actually worked.
Include device resources in the baseline. Open the system task manager and watch CPU, memory, and disk usage during testing. If the proxy core stays near 100% CPU in one process while extraction, synchronization, or security scans are also running, pause other heavy tasks before testing again. If another device on the LAN reaches 40 Mbps with the same node while the current device gets only 8 Mbps, local resources or the network adapter deserve priority over node-related factors.
Direct Fixes for Common Speed Problems
Why is downloading still slow when latency is only 60 ms?
Latency is not bandwidth. Run at least 3 sustained-transfer rounds of 60 seconds each on the same node. If performance remains below other nodes, switch nodes first instead of ranking them by latency alone.
What should I do if speeds are normal during the day but consistently slow at night?
Record data from 20:00 to 23:00 for three days and compare the same node on another access network. Recovery after switching networks indicates congestion in the access or intermediate route; consider peak server load only if every network is slow.
Why is the browser fast while the terminal and games are slow?
The browser may be reading the system proxy while the terminal and games are not. First confirm whether the application supports HTTP or SOCKS proxies. Applications that do not read system proxy settings can be tested separately with TUN mode.
Do I need to reinstall after speeds suddenly drop following a subscription update?
Compare node addresses, ports, protocols, and transports before and after the update, then try other nodes in the same group. Reinstalling will not fix node load or route congestion; comparing configurations is more useful.
How do I handle global proxy mode being fast while routing mode is slow?
Check the direct-connection rule and DNS group matched by the target domain. After reordering conflicting rules, reconnect and confirm in the log that the outbound tag changed from direct to the intended proxy outbound.
The full troubleshooting sequence can be reduced to one sentence: compare three nodes under controlled conditions, use another network to rule out the access route, then check ports, proxy mode, DNS, and matched routing rules. Changing advanced parameters is meaningful only after the first two layers are stable.
After resolving the issue, keep a record of the healthy state, including client and core versions, node region, true connection latency, throughput across three rounds, proxy mode, and test time. When speeds drop again, reuse this baseline to determine within about ten minutes whether the problem is the node, route, or local configuration.