How to Fix Slow V2Ray Speeds: Check Nodes, Network Routes, and Local Settings

At a glance

For cases where a node connects but pages load slowly, videos buffer, or downloads crawl. Start by keeping test conditions consistent, then compare nodes, network access, and the local proxy path. Use latency, sustained throughput, and logs to narrow down the cause. By the end, you’ll have repeatable results to help decide whether to change the exit, investigate the network route, or adjust the client—rather than changing everything at once.

First, distinguish latency, time to first byte, and download speed

Latency shown in the node list is not the same as available bandwidth. A basic TCP connection test mainly measures how long it takes to establish a connection. A client’s real-connection test also depends on the test endpoint, TLS handshake, and server response. A reading of 80 ms, for example, does not tell you whether video will play smoothly. Conversely, a higher-latency node may still deliver strong sustained throughput.

Before testing, pause sync, system updates, and other downloads. Run just one client and one test at a time. Use the same device, target resource, and traffic-capture method, changing only one variable per test. The settings below are suggested test parameters, not measured results for any particular route.

3 runs

Repeat under the same conditions and use the median

30 seconds

Observe sustained transfer speed in each run

10808

Example local SOCKS port used below

No response for a long time, then a quick start: Check DNS resolution, connection setup, and the target server’s response first.
Starts quickly, then stays slow: Compare node exits, route capacity, and any speed limits imposed by the target site.
Speed repeatedly drops to zero or the connection disconnects: Check Wi-Fi signal, packet loss, kernel errors, and device sleep settings.
Only one website is slow: Test another similar site first; don’t assume every node is at fault.

Mind the units: 100 Mbps of advertised bandwidth works out to a theoretical maximum of 12.5 MB/s, since 8 bits = 1 byte. That’s before protocol overhead and other traffic. Speed tests may show Mbps while download dialogs show MB/s, so the numbers aren’t directly comparable.

Layer 1: Isolate node issues with a like-for-like comparison

You usually can’t see node load directly from the client. What you can observe is end-to-end performance—not the server’s CPU usage or how busy a shared exit is. If switching nodes makes things faster, it only shows that the new path works better for this test; it doesn’t prove the original node was oversold. Different nodes may also use different entry points, exits, destination routes, and provider traffic management.

Select node A in the v2rayN list, then choose “Set as active server” from the right-click menu. Confirm that the new test connection uses this node.
Choose the same file each time, with download access and enough data to test. Observe its speed for 30 seconds, repeat 3 times, and record the median and any interruptions.
Switch to node B, stop the old download, and establish a new connection. Keep the test target and local network unchanged.
Repeat outside peak hours and during your usual evening peak. Also note the access method, client version, and core in use.

What you observe	Most likely cause	Next test
A is slow, B is fast, same target	The route or exit used by A	Try a second target, then compare A and B again
Both A and B are slow only in the evening	Peak congestion on a shared link or exit	Keep the node the same and switch networks
Both nodes are slow on just one site	The target site, its CDN, or the route to it	Try another site and compare exit regions
The same node works on another device	Settings or performance on the original device	Check the proxy path and CPU usage

Takeaway: Change one variable first, then decide whether to switch nodes

Prioritize switching from A only if it performs significantly worse across multiple targets and time slots. If every node slows down at the same time, start by checking the shared network connection and local environment.

VMess and VLESS are protocol names, not speed tiers. You can’t attribute speed differences between two routes to the protocol alone. A region label in a subscription also doesn’t guarantee the actual entry point or the full route. Use node labels to tell them apart, but compare performance under the same conditions.

Layer 2: Separate local network issues from congestion on the remote route

The most useful route comparison keeps the device, node, and target the same while switching only the network—for example, test on home broadband, then on a mobile hotspot. Hotspots aren’t a perfect baseline: your plan may throttle speeds, and signal strength matters. But if switching networks consistently improves results, investigate the route from your original network to the node’s entry point.

Check your local connection first: Turn off the proxy and test a resource you know is reached directly. If the direct connection is also slow, troubleshoot Wi-Fi interference, router load, or a broadband fault first.
Try a wired connection: If possible, switch to Ethernet. On Wi-Fi, move closer to the router and compare bands so you don’t mistake a weak indoor signal for a node problem.
Check the gateway response: Find the default gateway address in your system’s network settings. Test the connection from your device to the gateway, then test a remote address that allows probes.
Retest at different times: Note the exact time. If speeds drop only during regular peak hours, share comparisons from multiple time slots when contacting your ISP—not just a single speed-test screenshot.

On Linux, use the command below to check ICMP responses from your local gateway. Replace 192.168.1.1 with your device’s actual gateway. On Windows, use ping -n 30 192.168.1.1. These probes typically bypass application-level proxies and don’t reflect actual traffic through the proxy tunnel.

ping -c 30 192.168.1.1

If your device already sees packet loss or significant jitter to the gateway, troubleshoot the local network first. But no ICMP response from a remote host doesn’t mean the proxy connection is unavailable; intermediate routers may filter probes. Even if a route trace shows packet loss at one hop, that doesn’t prove it is dropping application traffic if later hops and the destination respond normally.

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

Having the client open doesn’t mean your current app is using it. A browser may follow the system proxy, command-line tools may read only environment variables, and other apps may have their own proxy settings. Confirm that traffic is reaching the proxy before trying to optimize speed. In v2rayN, right-click the tray icon and go to “System Proxy” → “Auto configure system proxy.” Menu names may vary by version and platform. On Linux desktops, also check the system network proxy settings.

Check the listening port: In v2rayN, open “Settings” → “Parameter settings” and verify the local listener and related port options. The example below uses 127.0.0.1:10808 for a SOCKS connection; use the values in your current configuration.
Simplify traffic capture temporarily: For troubleshooting, turn off TUN and test through an explicitly specified local proxy only. Restore your original settings afterward to avoid conflicts between the system proxy, TUN, and an app’s own proxy settings.
Check which routing rule applies: Make sure the test domain isn’t matched by a direct or blocking rule. For a short test, route the target explicitly through the proxy, then restore your original routing rules.
Check for existing app connections: Restart the test after switching nodes or routes. Existing browser connections may not immediately move to the new exit.

If curl is available, explicitly specify the SOCKS endpoint to rule out whether the app is using the system proxy. This request fetches response headers only; it is not a download speed test. socks5h lets the proxy resolve the target domain, making it useful for comparison with local DNS resolution. If the request fails, check the logs to determine why.

curl --proxy socks5h://127.0.0.1:10808 \
  --connect-timeout 10 --max-time 30 \
  --head https://example.com/

If an explicitly proxied request works but the browser is slow, check browser proxy extensions, custom DNS settings, and cached connections. If both are slow, go back to comparing nodes and network routes. Don’t bind the local listener to all network interfaces to “speed things up”: widening its reach won’t add exit bandwidth and will make it accessible from more places.

DNS, resource usage, and logs: investigate remaining issues

DNS tends to affect the first page load and connection setup, not a download that’s already in progress. If a page takes a long time to appear but resources transfer normally afterward, compare the first visit to a new domain with repeat visits, and check the resolution logs. Browser Secure DNS, system DNS, and core DNS may use different paths, so changing one setting may not affect the actual request.

Check device load: Watch Task Manager or System Monitor during a download. If one CPU core stays near 100% or the device gets hot and throttles, close demanding background tasks and test throughput again.
Enable detailed logs only when needed: Temporarily increase log verbosity while reproducing the issue, then restore it. Leaving verbose debug logging on can increase disk writes and may record details such as visited domains.
Change MTU with care: Investigate MTU only if you see evidence such as some sites stalling under TUN or large requests failing while small ones work. Don’t treat a particular MTU value as a universal speed boost.
Keep the core consistent for comparison: v2rayN is a client; V2Ray and Xray are cores. Before switching, make sure the protocol and transport settings are compatible. Don’t change the core, node, and DNS all at once.

The following are real error snippets that may appear in core or connection logs. Surrounding text and formatting vary by platform. They can help identify the stage where a failure occurred, but they don’t directly prove that a node is slow.

Error: `bind: address already in use`

Cause: Another process is already using the local listening address and port.

Fix: Close any duplicate client instance, or change the local port and update the app’s proxy settings to match. Restart the core and confirm that it starts listening successfully.

Error: `i/o timeout`

Cause: A network read or write operation exceeded its time limit. This may happen during DNS resolution, connection setup, or data transfer.

Fix: Check the target address and operation stage in nearby log entries. Then compare the same node on another network and another node on the same network.

Error: `connection refused`

Cause: The target refused the connection. For a local proxy port, this often means the core isn’t listening or the port is incorrect.

Fix: First check whether the address in the log is local or remote. Then verify the local listener, or check the node address and port.

Before sharing logs, remove subscription URLs, user identifiers, and authentication details. If you need to submit a bug report, include the time of the error, target type, client and core versions, traffic-capture method, and comparison results. These details are more useful for reproducing the issue than a full configuration screenshot.

Common questions: Why is real-world performance slow when the speed test is fast?

The node has low latency, but videos keep buffering. Why?

Check the player’s buffer and connection-speed details, then download another target resource using the same node. A latency test doesn’t measure throughput to a video CDN. If only one platform is slow, compare exit regions and routes to the target instead of choosing a node by latency alone.

Does enabling TUN improve download speeds?

TUN captures traffic; it doesn’t automatically increase bandwidth. First establish a baseline with an explicit proxy, then test again with TUN enabled. If the issue occurs only with TUN, focus on routing, DNS, permissions, and interface settings instead of switching nodes again.

Why does the same node work on my phone but run slowly on my computer?

First, make sure both devices use the same network, and disable cellular data switching on the phone. On the computer, compare the browser with an explicit proxy request using curl, and check background downloads and CPU usage. On Android, v2rayNG mainly uses the Xray core, while v2flyNG uses the V2Fly core; don’t assume their configuration options are interchangeable.

Why did a node slow down after I updated the subscription?

Check whether the active node changed and whether the provider changed the address, port, or transport settings. A subscription distributes configuration; it doesn’t carry your traffic. Select the node again, establish a new connection, and run three comparisons against the same target.

Why is a file download slow when the speed test uses all my bandwidth?

A speed test may use multiple connections, while a file download may use only one. The target server may also impose limits. Compare single-connection performance against the same target first; don’t simply add lots of parallel connections. Too many can consume shared bandwidth and may trigger server-side limits.

Wrap-up: Keep reproducible records and only the changes that help

At the end of a troubleshooting session, you should be able to summarize the result in one sentence—for example, “Same device, same node, same target: slow on home broadband, normal on a hotspot.” That’s more useful than “I changed a bunch of settings and it seems faster.” The first result points to a next step; the second doesn’t show which change made a difference.

Record the test time, network, node label, and client and core versions.
Save results from three sustained-transfer runs, noting the units, target, and whether multiple connections were used.
Restore any temporary routing, log-level, and traffic-capture changes. Keep only settings you’ve verified are effective.
If you need to change client versions, back up your configuration first, then retest under the same conditions. See the setup guide for installation and basic proxy settings.