V2Ray Slow Speed Troubleshooting: Nodes, Network Paths, and Local Settings

First, distinguish slow page loads from low throughput and intermittent drops

“Slow internet” can mean at least three things: a long wait before a page appears, a page that loads but downloads crawl, or a connection that starts normally and then stalls. These can involve DNS resolution and handshakes, available bandwidth, or connection stability. Client-reported latency usually measures only one type of probe; it cannot replace a real webpage or sustained download test.

Pause system updates, cloud uploads, and other downloads first. On the same device, choose a frequently visited HTTPS page and a fixed file that you’re allowed to download and that’s large enough for a sustained test. Don’t change the node, browser, and test target at the same time, or you won’t know which change made a difference.

These figures describe a testing approach, not measured results from this site or a performance guarantee. A small file may finish too quickly to show sustained throughput. If your data plan is limited, shorten the test window and keep it consistent across all runs. Download tools report MB/s, while carriers often use Mbps: the ideal conversion is 1 MB/s to 8 Mbps, before protocol overhead.

• Slow initial load: Record DNS lookup, connection, and time-to-first-byte durations. Note whether only the first visit is slow.
• Low sustained throughput: Measure transfer speed during the steady phase; don’t treat the initial peak as the result.
• Intermittent drops: Note when the connection drops, whether the screen is off or the network changed, and check the logs from that time.

Layer 1: Compare node load and exit paths

A node’s listed region doesn’t tell you the full route. Two nodes in the same region may use different data centers, ingress points, and exits; nodes with different names may share an ingress. Updating a subscription refreshes the configuration—it doesn’t add server bandwidth. On the same network and around the same time, compare two available nodes against the same target.

In v2rayN, select a node in the server list and use the speed test option in the context menu for an initial comparison; menu labels vary by version. In v2rayNG, select a node in the main list, reconnect, then test in the same app. Built-in tests may use different targets or concurrency than your actual traffic, so confirm the results with a real-world test.

If you manage the server, check CPU usage, bandwidth utilization, and connection count at the same time. Otherwise, describe the issue as a “possible node-side bottleneck”—client speed alone doesn’t prove the server is oversold. Results from different times can offer clues, but they can’t replace a controlled comparison under the same conditions.

Layer 2: Check your access network and cross-network routes separately

Keep the node and target unchanged. Switch your Android phone from Wi-Fi to mobile data, reconnect v2rayNG, and run another test set. Switching networks interrupts existing connections, so cached pages and downloads already in progress don’t count as results from the new network. On a desktop, you can compare using a phone hotspot, but factor in signal quality and data limits.

If Wi-Fi is the only slow connection, move closer to the router and compare the 5 GHz and 2.4 GHz bands. At long range or through multiple walls, 5 GHz isn’t necessarily more stable. If direct traffic is also slow on the same Wi-Fi, check wireless interference, router load, or saturated upstream bandwidth before repeatedly changing the proxy core.

1. Use your default gateway as the local network probe target to check stability between your device and router.
2. In Windows, run ping -n 30 and add your actual gateway address; then test the node address the same way if it allows probes.
3. Look for persistent packet loss and significant jitter, and run a real HTTPS request at the same time. Don’t draw conclusions from probe packets alone.
4. If the same node repeatedly works normally on another network, focus your investigation on the access network or the route from your ISP to the node’s ingress.

Slowdowns during evening peak hours that clear up overnight can point to congestion, but the destination may also be busier. Track two targets at the same time. Don’t change the MTU based on one speed test. Investigate path MTU and tunnel encapsulation only when you can reproduce a specific issue, such as a successful handshake followed by repeated stalls during larger transfers on a particular network.

Layer 3: Check the protocol, transport, and server settings

VMess and VLESS are proxy protocols. TCP, WebSocket, and gRPC are transport options at different layers, while TLS provides secure transport. Don’t lump them together in a single speed ranking. Real-world performance depends on the server implementation, network path, destination, and device—not just the protocol name.

v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core; supported fields and features may differ. v2rayN performance also depends on the selected core and its configuration. Switching clients isn’t just a matter of copying a node address: make sure the core supports the protocol and transport combination provided by your subscription.

• Check the node first: The address, port, user ID, and TLS setting must match the server. Port 443 alone doesn’t mean TLS is enabled.
• Then check the transport: Set the WebSocket path and Host, gRPC service name, TLS server name, and other values to match the server’s settings.
• Then compare options: Test a different transport only if the server provides another working endpoint. Don’t change an existing WebSocket node to gRPC.
• Keep the original configuration: Export it before making changes, and revert immediately if the connection fails. Never disable certificate verification to improve speed.

Multiplexing isn’t a universal speed boost, either. It may reduce the overhead of setting up repeated connections for many short requests, but under some packet-loss conditions or during long, high-volume transfers, requests sharing an underlying connection can affect one another. If your core and protocol support the setting, compare results with it enabled and disabled. Don’t change concurrency or transport at the same time.

Layer 4: Verify local proxy, DNS, and routing settings

Windows system proxy settings aren’t guaranteed to cover every app. In v2rayN, select “System Proxy” from the tray menu to configure it automatically, but terminals may still connect directly, and browser extensions can override system settings. First check the local listener under “Settings” → “Parameters.” Depending on the version, it may be under “Basic Settings” or an inbound settings page; follow what you see in your version.

The Windows PowerShell command below specifies the HTTP proxy entry point explicitly, ruling out whether an app is ignoring the system proxy. First confirm that the local listening port is 10809, then copy the command. If your port is different, update the command first. Here, 10809 is only an example; it isn’t the default for every v2rayN installation.

curl.exe --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect}s start=%{time_starttransfer}s total=%{time_total}s bytes=%{size_download} speed=%{speed_download}B/s\n" https://v2rayultra.com/

This command checks the proxy entry point and shows request timings; it isn’t a sustained throughput test. time_connect mainly reflects the connection to the local proxy. time_starttransfer also includes the subsequent tunnel, handshake, and wait for the destination’s response, so it shouldn’t be called “node latency.” For a large-file test, use a fixed download URL you’re authorized to access. The 30-second limit may end the request early; don’t mistake that for a dropped node connection.

• Check routing: The system proxy sends traffic to the core, but routing rules may still send it directly. Check the access logs to verify the actual outbound route for your test target. “Global proxy access” doesn’t mean every destination uses the proxy.
• Check DNS: If the first visit is slow but repeat visits are fast, look for DNS lookup timeouts. Don’t replace every DNS address at once. Check Android Private DNS and the client’s DNS settings separately, changing and retesting one at a time.
• Check per-app proxy settings on Android: In v2rayNG, go to “Settings” → “Per-app proxy” and confirm the test app is included. Labels may vary by version; also check whether the current selection is a proxy list or a bypass list.
• Check background restrictions: On Android, go to “Settings” → “Apps” → “v2rayNG” → “Battery” and review background restrictions. If connections drop only when the screen is locked, temporarily allow background activity to test, then consider the battery impact.
• Check device load: On desktop, check Task Manager; on Android, watch for overheating and CPU throttling. Avoid repeatedly switching between TUN mode, other VPN services, and proxy tools, since routing changes can mask the underlying issue.

How timeouts and resets in logs relate to slow speeds

Enable verbose logs only for short troubleshooting sessions. Note when the request occurs, then check entries for the same target at that time; a single error may be from an unrelated background app. Keeping verbose logging enabled can increase storage and processing overhead, so switch back to your usual log level when you’re done. Before sharing logs, hide subscription URLs, user IDs, and server details.

The exact error wording may vary by operating system and core version. If there’s no matching request in the logs, first check whether the app is using the proxy rather than changing the remote node again. If the request uses the expected outbound route but still stalls, compare the logs with your earlier node and network test results.

FAQs and when to stop troubleshooting

You can stop troubleshooting once you’ve found a stable, reproducible difference. Record the time, access network, node, target, proxy mode, three test results, and relevant log lines. There’s no need to keep chasing a lower-looking latency number. If you need help, these details make it much easier to diagnose the issue than “all my nodes are slow.”

1. Direct connections are slow too: Check the access network and device load first.
2. Only one node is slow: Keep using a working node and send the comparison results to your service provider.
3. Switching networks fixes it: Focus on the wireless link, your ISP’s route, and shared ingress.
4. Explicit proxy works, but the app doesn’t: Recheck system proxy, per-app proxy, and routing rules.
5. Only one transport configuration fails: Verify the server settings and core compatibility before investigating performance.