Use this guide when v2rayN, v2rayNG, or v2flyNG connects successfully but pages load slowly, videos buffer, or downloads are much slower than usual. Fix the test conditions first, then check the local proxy chain, node status, and cross-network route to identify the faulty layer instead of relying on a single latency reading.
Establish a Reproducible Speed Baseline
“Connected but slow” is not a precise enough diagnosis. A slow first page load, slow sustained downloads, one specific site loading slowly, and a broad evening slowdown can have very different causes. Before changing settings, record the test time, network connection, client version, current node, and proxy mode. The desktop menu paths in this guide use v2rayN 7.11.3 as a reference. Labels may change slightly in later versions, but the troubleshooting logic remains the same.
Use the same device and network for baseline tests. Do not switch between wired and wireless connections, and avoid system updates, cloud sync, or large uploads during testing. Keep only the test page open in the browser. Run each download test for 30 seconds, repeat it 3 times, and wait 60 seconds between rounds. This helps rule out misleading results caused by temporary caching, connection warm-up, or background traffic.
A complete proxied request passes through the application, local listening port, routing rules, proxy node, and destination site. A port conflict, incorrect rule match, packet loss, or congestion at any point can appear as “slow speed.” For the first round, record results without changing multiple parameters. If you change the node, protocol, and DNS at the same time, a recovery will not reveal the real cause.
Record the Current Environment
Note the client version, core version, network type, node name, and test time. In v2rayN, open Help → About to check the version, and check the beginning of the runtime log for the core actually loaded.
Measure the Direct-Connection Baseline
In v2rayN, select System Proxy → Clear System Proxy, fully exit TUN mode, and run the same download test 3 times against the same source. The direct-connection results show whether the local network itself is stable.
Measure the Proxied Result
Restore the original node and proxy mode, then repeat the test against the same target. Do not change the browser, download source, or network; the only difference between the two sets should be whether traffic passes through the proxy.
Calculate the Speed Ratio
Divide the median proxied speed by the median direct speed. This is more useful than a single peak reading. If the three results vary by more than a factor of two, address network instability before discussing the node’s capacity.
Layer 1: Check Local Proxy and Routing Settings
If every node is slow, start with the local layer. Common causes include the system proxy not actually being enabled, the browser still using an old port, TUN competing with another traffic-filtering tool, or routing rules sending the test target to direct or blocked outbound traffic. Repeatedly refreshing the subscription will not usually help because the node configuration may be fine.
The common local listening port in v2rayN is 10808, but it may differ after a version change, configuration migration, or manual adjustment. Use the actual port shown under Settings → Parameters. If a browser extension or another application has a SOCKS address entered manually, verify that the address is 127.0.0.1 and that the port matches the client. Do not overwrite the current value simply because an old guide lists 10808 or 10809.
- System proxy mode: For ordinary browser traffic, start with “Automatically configure system proxy” as a verification step. If you select “Do not change system proxy,” only applications with a manually configured proxy will use the node.
- TUN mode: This can handle programs that do not read the system proxy, but first confirm that the virtual network adapter is created correctly. During testing, do not run another network tool that also captures traffic.
- Routing mode: Temporarily switch to global proxy mode for comparison. If global mode works but rule-based routing is slow, inspect the domain and IP rules instead of continuing to change nodes.
- DNS settings: If opening a site pauses for a long time but downloads are normal once connected, focus on the relationship between domain resolution, remote DNS, and split-DNS rules.
For precise routing checks, open Settings → Routing Settings in v2rayN and copy the current rule set before making changes, so the everyday configuration remains intact. Create a temporary test profile containing only the necessary rules and make sure the target domain clearly uses proxy outbound traffic. Restore the original rules after testing and reconnect so that old connections do not continue using the previous path.
The core type must also match the node parameters. Open Settings → Parameters → Core Type to confirm the current selection. Whether VLESS or VMess nodes work correctly depends on more than the protocol name: verify the address, port, user identifier, transport, TLS, and server name. Incomplete parameters may cause repeated connection attempts rather than a complete disconnect, resulting in slow first loads and unstable throughput.
Local-Layer Findings
| Observed comparison | More likely cause | Next step |
|---|---|---|
| Global proxy works, rule-based routing is slow | Rule matching or split DNS | Check the routing outbound selected for the target domain |
| Browser works, other programs are slow | The program does not read the system proxy | Check the program’s proxy settings or test TUN mode |
| Every node pauses while establishing a connection | Local DNS, port, or core settings | Review the logs and verify the listening port |
| Still very slow with the proxy disabled | Local network or destination site | Check the router, wireless signal, and upstream network first |
Layer 2: Compare Nodes to Identify Load Issues
After confirming that the local path is healthy, determine whether one node is overloaded. Node load often varies significantly between nodes: one node in the same subscription may remain slow while others perform normally under identical tests. Do not rely only on the latency order in the client list. Latency tests transfer very little data and cannot directly show usable bandwidth when many users are active.
Choose at least 3 nodes with different entry addresses or in different regions, and test them in a fixed order. After connecting each node, wait 10 seconds for DNS caching and connection state to settle, then run 3 rounds of sustained downloads lasting 30 seconds each. Record the median, not an occasional peak. If only one node is consistently much slower across multiple time periods, node load or that node’s server egress is more suspect.
- Test nodes A, B, and C with the same client, network, and target.
- After each node switch, close the old test connection and reopen the test page.
- Run one set in the morning and another in the evening, using the same test method in both periods.
- If a node slows only in the evening, record the exact time instead of immediately changing transport parameters.
- If all nodes slow down together, move on to the route layer rather than blaming one node.
A subscription update can also create misleading comparisons. After an update, nodes with the same name may no longer point to the same address or port. Before comparing them, open the node details and confirm that the entry domain, port, transport, and server name have not changed. VMess and VLESS are only parts of the configuration. Actual speed also depends on server resources, egress bandwidth, congestion control, and the cross-network path, so the protocol name alone cannot predict performance.
Layer 3: Identify Route Congestion by Time and Path
A route issue is usually not caused by an incorrect configuration field. It reflects changing transmission quality between the device and the node entry, or between the node and the destination. Typical signs include several nodes slowing down at about the same time, a much worse evening performance than daytime performance, or small transfers working while sustained large transfers repeatedly drop. Cross-provider routing, wireless interference, and a saturated home uplink can look similar.
Compare different time periods first, then compare connection types. Run the same test once in the morning and once in the evening, with 3 rounds per set. If possible, test wired and stable wireless connections on the same device, but reconnect the proxy after switching. If wired is normal while wireless is slow, the issue is more likely local access. If both decline together in the evening, upstream route congestion is more likely.
| Pattern | Likely layer | How to verify |
|---|---|---|
| Stable during the day, multiple nodes slow in the evening | Peak-hour cross-network route | Keep the node fixed and run 3 rounds in each period |
| Wireless is slow, wired is normal | Local access | Move closer to the access point, disable background uploads, and retest |
| Pages load slowly at first, sustained downloads are normal | DNS or handshake path | Compare resolution time with true connection latency |
| Small transfers are normal, sustained transfers drop periodically | Packet loss, congestion, or traffic shaping | Run a continuous transfer test for at least 30 seconds |
| Only one destination site is slow | Destination site or node egress route | Cross-check with two similar destinations |
Transport choices can affect route performance, but do not change them blindly without a comparison. TCP, WebSocket, and gRPC transports are determined by the server configuration; the client cannot replace them unilaterally. Transport parameters in VLESS or VMess nodes must match the server. Arbitrarily changing the network type, path, host name, or TLS settings usually causes connection failures rather than fixing genuine route congestion.
The same troubleshooting logic applies on Android. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core; for both, stabilize the network first and compare the same node across different times. Mobile data and wireless are different access paths, so switching between them can show access differences but cannot by itself prove a client performance difference. Also disable battery-saving restrictions that interfere with background connections, and keep the screen and test app active during testing.
Use Logs to Find Port, Resolution, and Connection Errors
If slow speeds come with frequent drops, repeated reconnects, or pages remaining blank for a long time, check the core logs. Logs help distinguish a connection that is slow to establish from one that never establishes at all. In v2rayN, watch live output in the log area on the main screen. After changing settings, clear the old logs and reproduce the issue once so errors from hours earlier are not mistaken for the current cause.
A single error does not always indicate an ongoing failure. For example, a destination closing the connection can also produce a read error. Check whether the same error repeats within a short period, and correlate it with the domain, node, and proxy mode in use. The following log messages are good starting points for targeted checks.
Error: failed to find an available destination
Cause and fix: The outbound address could not be resolved or no destination is available—check the node domain spelling, review DNS settings, restart the core, and see whether the error continues to recur.
Error: failed to listen TCP on 127.0.0.1:10808
Cause and fix: The local listening port is already in use by another process—open Settings → Parameters to verify the local port, close the process using it, or switch to an unused port and update the application proxy settings accordingly.
Error: transport/internet/tcp: failed to dial
Cause and fix: The core could not establish a TCP connection to the node entry—verify the server address and port, then compare with another node. If several nodes fail during the same period, check the local network and upstream route.
Error: context deadline exceeded
Cause and fix: The operation did not finish within the allowed time—use the surrounding log entries to determine whether it occurred during DNS resolution, node connection, or destination access, then narrow it down by changing the node and test target.
After fixing a port conflict, confirm that every application using the proxy has been updated as well. If the local SOCKS port changes from 10808 to 10818 but a browser or download tool still points to 10808, it may appear completely unable to connect or keep falling back. Applications using the system proxy usually follow the client configuration; applications with a manually entered proxy address must be updated separately.
If the logs contain only occasional connection-closed messages while sustained downloads remain stable, do not treat every notice as a speed failure. Focus on the same error repeating frequently, each occurrence causing a clear pause, or the core restarting continuously. After troubleshooting, restore the normal log level to avoid excessive debug output affecting readability and disk usage.
Build a Retest Process Without Confounding Variables
The key principle is to change only one variable at a time. Keep a simple record with the date, time, client and core versions, access network, node, proxy mode, test target, results from all three rounds, and a log summary. It does not need complex charts, but it must answer what changed and whether the result can be reproduced.
Keep the Test Target Fixed
Choose the same resource that can sustain a stable transfer. Keep the browser, download method, and duration consistent for every round, and do not switch targets mid-test.
Eliminate Local Variables
First disable background uploads and system updates. Use System Proxy → Automatically configure system proxy for the baseline test, then test TUN separately if needed.
Compare Three Nodes
Keep the routing rules unchanged and switch only the node. Wait 10 seconds after connecting to each node, run 3 rounds, compare the medians, and ignore brief one-off peaks.
Compare Two Time Periods
Repeat the same steps in the morning and evening. If multiple nodes decline together only in the evening, shift the investigation to the cross-network path and peak-hour congestion.
Restore the Everyday Configuration
After verification, restore the original routing rules, DNS, and proxy mode, restart the core, and visit a regular destination to confirm that no test settings remain.
If speed returns immediately after changing nodes while the system proxy, routing, and test target remain unchanged, a node-side issue is more likely. If speed returns after switching to global proxy mode while the node stays the same, check routing rules and DNS first. If it remains slow with the proxy disabled, address the local network or destination site before changing more V2Ray parameters.
For intermittent issues, retest across at least two time periods. A quick recovery may result from completed node maintenance, a changed network path, or lower destination load; it does not prove that an unrelated setting you changed was effective. Keep the configurations and test records from before and after the change to avoid repeating trial and error.
Common Questions About Slow-Speed Troubleshooting
Why is the node with the lowest latency still slow for downloads?
Latency tests transfer very little data and mainly reflect connection setup time, not sustained bandwidth. Run 3 continuous 30-second downloads for each candidate node, then compare the medians.
What should I do if all nodes suddenly become slow?
Clear the system proxy and test a direct connection first, then check for background uploads. If direct access is normal, retest three nodes in the morning and evening to see whether the route is fluctuating in sync.
What does it mean if speed returns after switching to global proxy mode?
The node itself usually works, so the issue is more likely in routing rules or split DNS. Open Settings → Routing Settings and check which rule and outbound actually match the test domain.
Can updating the subscription directly fix slow speeds?
It can help only when the node address or parameters in the subscription have changed. Compare the address, port, transport, and server name before and after updating; do not treat a subscription refresh as a universal fix.
Do I need to keep changing the protocol and transport?
No. VMess and VLESS transport parameters must match the server. Changing TCP, WebSocket, or gRPC settings only on the client creates a mismatch. First identify the faulty layer by comparing nodes and time periods.
The final diagnosis should identify a specific layer: the local layer covers proxy capture, ports, DNS, and routing; the node layer asks whether one node stays slow under identical conditions; the route layer looks for synchronized, time-based changes across multiple nodes. Following this order reduces unnecessary changes and makes later reports reproducible.