How to Troubleshoot Slow V2Ray Speeds: A Three-Layer Method for Nodes, Routes, and Local Settings

When proxy speeds suddenly drop, changing protocols, enabling Mux, or repeatedly reinstalling the client usually does not speed up troubleshooting. Download performance depends on node load, access route, cross-network congestion, the destination server, local proxy mode, and device performance. First create repeatable test conditions, then change one variable at a time.

Establish a speed-test baseline before treating latency as bandwidth

Latency and throughput are different metrics. A latency test shows how long one round trip takes and helps assess how readily a node establishes connections. Download speed shows how much data transfers over time and is also affected by node egress bandwidth, destination-server limits, and TCP congestion control. A node with 45 ms latency may deliver only 8 Mbps, while one at 130 ms may sustain 120 Mbps.

Before testing, pause cloud-sync jobs, system updates, and background browser video. Use the same device, access network, and target file, and run three consecutive tests. The first connection may include DNS lookup and the TLS handshake, so record the second and third results. If the results are 92, 95, and 90 Mbps, the node is fairly stable; if they are 88, 21, and 76 Mbps, investigate load and packet loss instead of taking only the highest value.

Layer 1: Determine whether the node itself is congested or restricted

Node-level issues usually show three signs: only a few nodes are slow on the same network; speeds stay slow all day and repeatedly approach the same ceiling; or latency rises sharply as connections increase. First compare different nodes in the same region. If node A delivers 18, 20, and 19 Mbps while node B delivers 86, 91, and 88 Mbps, the local network and client are unlikely to be the main bottleneck.

Latency lists are useful only for initial screening. v2rayN latency tests check node response time but do not directly represent download capacity. Select a node on the main screen and run a latency test, then perform an actual download with two nodes that have similar latency. If one has 62 ms latency and 15 Mbps throughput while another has 75 ms and 96 Mbps, choose the latter for downloads.

1. Keep the test environment fixed

   Close other download tasks and stay on the same wired or wireless network; do not switch access methods during a test. Run each round for at least 60 seconds.

2. Refresh node information

   In the v2rayN 7.x main window, open “Subscription Groups” → “Update All Subscriptions” and confirm that node addresses, ports, and transport parameters come from the current subscription.

3. Filter by latency

   Run TCP latency tests on candidate nodes. First remove nodes that repeatedly time out or fluctuate by more than 300 ms; do not draw conclusions from the lowest latency alone.

4. Measure throughput

   Choose three candidate nodes, run the same task three times on each, and record average speed, minimum speed, and time to begin loading.

5. Check the logs

   Open “Help” → “View Logs” and check whether handshake timeouts, connection resets, or unreachable-destination messages cluster during testing.

Switching between VMess, VLESS, or different transport methods is meaningful only when the server provides the corresponding configuration. A protocol is not a client-side speed switch. When comparing protocols, keep the same server, port, and similar security layer whenever possible; otherwise differences in machine performance, entry route, and egress bandwidth get mixed into the results.

Layer 2: Compare routes, times of day, and access networks

Route congestion often follows a clear time pattern. If speeds hold at 90 Mbps during the day but fall to 15 Mbps from 8:00 to 11:00 p.m., while latency rises from 70 ms to 220 ms, peak-hour congestion is the more likely explanation. If several nodes in the same region slow down together, compare access routes instead of constantly changing client parameters.

The most useful comparison keeps the same node and changes only the local access network. For example, with a fixed node, home broadband may deliver 18 Mbps while another network delivers 82 Mbps. That points to the local carrier network, routing path, or home equipment. If both networks stay near 18 Mbps, return to node load and egress limits.

Layer 3: Check ports, DNS, routing, and the system proxy

When every node is slow on one device but other devices on the same network work normally, turn to local settings. v2rayN commonly uses local inbound port 10808, but the actual value is defined under “Settings” → “Parameter Settings.” Browsers, download tools, and the system proxy must point to the current listening port. An old port may still be occupied by another program, causing connection failures or bypassing the proxy.

The system proxy and TUN mode have different traffic entry points. The system proxy handles only applications that follow the system proxy settings; TUN mode captures traffic at a lower level. Do not stack multiple entry points while troubleshooting. Disable TUN first and enable only “Automatically configure system proxy” for a baseline test. Then test TUN separately if needed to determine whether the difference comes from traffic capture or the node.

1. Verify the core

   Go to “Settings” → “Parameter Settings” → “Core Type” and confirm that the selected core supports the VMess, VLESS, and transport settings in the current subscription, then restart the core.

2. Check the port

   In “Settings” → “Parameter Settings,” view the local listening port. If it is 10808, the browser or download tool should also use 127.0.0.1:10808.

3. Use one proxy mode

   Use the status bar’s “System Proxy” → “Automatically configure system proxy” to create the test environment. Temporarily close other programs that modify system proxy settings.

4. Simplify routing

   Go to “Settings” → “Routing Settings” and temporarily use straightforward baseline rules to confirm whether the target request uses the proxy, connects directly, or is blocked.

5. Retest DNS

   Clear the system DNS cache and restart the core. If the logs show a long resolution wait, test local DNS and proxy-side resolution separately, then keep the more stable option.

Test environment: Windows 11 24H2, v2rayN 7.x
Local address: 127.0.0.1
Local port: 10808
Duration per round: 60 seconds
Number of tests: 3
Recorded fields: TCP latency, time to first byte, average Mbps, minimum Mbps, error logs

Routing rules directly change the actual path. If a download domain is mistakenly classified as direct, the test measures the local network rather than the proxy node. Conversely, sending a local or mainland-China service that should be direct through a remote node adds unnecessary distance. When checking rules, start with their order: earlier rules usually select the outbound first, and later rules do not take over an already matched request.

When Mux and protocol changes actually help

Mux multiplexes multiple logical connections over fewer underlying connections. It may reduce connection setup overhead for many short connections, such as when opening several small web resources at once, but it is not necessarily faster for a single large download. If the underlying connection loses packets, multiple logical streams may wait together, making speeds more erratic on high-bandwidth, high-loss routes.

To determine whether Mux suits the current environment, test with it disabled and enabled on the same node, covering both initial page load and a large-file download. If average speed is 94 Mbps with Mux off and 61 Mbps with it on, while web-page responsiveness barely changes, leave it off. If initial load time for many short connections drops from 2.8 to 1.7 seconds without a meaningful fall in large-file throughput, keep it enabled.

• Single-file download is slow: First compare with Mux disabled and watch sustained throughput, not just the peak during the first few seconds.
• Many small web resources: Record total load time and compare time to first byte and overall duration with Mux on and off.
• Heavy packet loss on the route: Fix the node or path first; multiplexing cannot restore lost bandwidth.
• Considering a protocol change: Use only VMess or VLESS configurations provided by the subscription and matched by the server. Do not change authentication or transport parameters on the client alone.
• REALITY configuration: The server name, public key, short ID, and flow-control parameters must match. A successful connection alone does not mean the route is faster.

Follow a fixed order for the final diagnosis

The goal is not to find a fleeting peak speed but to identify which layer contains the bottleneck. Compare nodes horizontally, compare times and networks at the route layer, and compare devices and matched settings locally. After checking all three layers, most “connected but slow” problems can be narrowed to a verifiable range.

1. Record the raw results

   Save three rounds of latency and throughput for the current node, noting the date, time period, access network, and proxy mode instead of relying on vague impressions.

2. Compare different nodes

   Test at least three nodes on the same network. If only a few are slow, classify the issue as node load, egress, or node-configuration related.

3. Compare different times

   Test the same node off-peak and from 8:00 to 11:00 p.m. If several nodes decline together, focus on route congestion.

4. Change the access network

   Keep the node and device unchanged and switch only the network. If speed changes substantially with the network, investigate the original access route and routing equipment first.

5. Restore local settings

   Verify the actual port, such as 10808, simplify routing, test the system proxy and TUN separately, and disable Mux for comparison.

6. Keep the stable configuration

   Choose the combination with the smallest variation across three consecutive rounds. A stable 80 Mbps is usually more suitable for daily use than a 140 Mbps peak with a 12 Mbps minimum.

The same method works on Android. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Keep the subscription node and access network consistent first, then check routing mode, DNS, and logs separately. Specific configuration support may differ between cores, so after importing a profile, confirm that its protocol and transport parameters were recognized correctly.