V2Ray Slow Speed: How to Diagnose Nodes, Network Paths, and Local Settings

First, define “slow”: connection delay, time to first byte, or sustained downloads

Don’t change settings just yet. A page that takes a long time to start but runs smoothly once loaded is a different problem from a download that starts quickly and then stays slow. For the first, check DNS resolution, the proxy handshake, and the destination server’s response. For the second, focus on sustained throughput, congestion, and device load. If only one site is slow, first rule out rate limits, account policies, and differences in content delivery networks.

Use consistent units when comparing speeds. ISP plans are usually listed in Mbps, while download tools may show MB/s. In theory, 100 Mbps is about 12.5 MB/s; actual speeds are lower due to protocol overhead. Latency, measured in milliseconds, describes waiting time—not how much data can be transferred per second. A node showing a latency of a few dozen milliseconds does not prove its server has enough outbound bandwidth.

Set a baseline: same target, one task, three test runs

Choose a fixed file that’s large enough to test and permitted for testing. Pause cloud sync, updates, and other speed tests. Record the client and core versions, node label, network connection, and test time. Use node labels for your own records only—never post subscription URLs, user IDs, or full connection links in public support tickets.

These figures describe a test plan, not results measured by this site. Prepare four sets of results: original node and network, different node and original network, original node and different network, and—if possible—a second device. Keep the test target and number of download connections the same. Don’t directly compare a single-connection browser download with the combined speed from a multithreaded test tool.

1. Alternate tests between node A and node B within the same time window. This helps avoid mistaking changes in network load over time for differences between nodes.
2. Connect the same device to another network and test node A again. A mobile hotspot changes both the carrier and wireless conditions, so the result reflects a change to the entire connection path.
3. Switch devices on the original network, keeping the same node and core settings where possible. This helps show whether the issue follows the device.
4. If speeds are slow at night but normal during the day, repeat the same test at both times. Don’t conclude that the server is rate-limiting based on a single result.

Layer 1: Node load and outbound limits

Keep your local network unchanged and try another node before switching protocols. If node A stays slow across multiple targets while node B performs normally at the same time, the issue is more likely with A’s server, outbound connection, or network path. The client usually can’t see the server’s actual CPU usage, shared bandwidth, or per-user rate limits. Treat “high node load” as a hypothesis to investigate—not a speed-test result.

• Compare different exits: Two nodes in the same region may share a server or upstream connection. Start with nodes known to use different exits to reduce the chance of a shared bottleneck.
• Compare different destinations: If two unrelated services are both slow through the same node, check the node and network path. If only one destination is slow, consider limits on the destination side too.
• Check usage and plan limits: Review your data allowance, expiration status, and speed rules in your provider’s account portal. A connected status in the client doesn’t mean your account hasn’t hit a speed limit.
• Compare one connection with multiple connections: A much higher combined speed with multiple connections shows only that concurrency affects performance. Single-connection limits, round-trip time, or packet loss may still be factors.

VMess and VLESS are proxy protocols, not bandwidth tiers. Switching protocols often also changes the server, transport, or TLS settings, so you can’t attribute the entire speed difference to the protocol. If a node requires specific transport and security settings, follow the server configuration. Don’t disable certificate verification or change transport fields just to run a speed test.

Layer 2: Network connection, packet loss, and inter-network paths

If the same node performs much better on a different network, the issue is related to your connection or the path to that node. But that alone won’t tell you whether the cause is Wi-Fi interference at home, a saturated broadband upload, or congestion between carriers. Try Ethernet or a stable Wi-Fi connection closer to the router, pause uploads and backups, then test again. A saturated upload can cause queues that slow both browsing and downloads.

In Windows PowerShell, you can check whether a server’s TCP port is reachable. Here’s the command structure: example.com is just a sample domain—replace it with the node’s actual server address. Replace 443 with the node’s actual port too; 443 is commonly used for TLS, but it isn’t the default for every node.

Test-NetConnection -ComputerName example.com -Port 443 -InformationLevel Detailed

A true TcpTestSucceeded value only means the TCP connection succeeded this time. It doesn’t confirm proxy authentication, TLS, the transport path, or access to the destination. This command checks the server port directly from your device, so it’s not suitable for diagnosing a service that uses UDP only. If the domain is behind a CDN, the result may only reflect the connection to an edge server.

• Port checks fail intermittently: Verify the actual address and port, check for firewall alerts on your device, and test another network. Don’t assume the server is at fault.
• Ping times out, but the proxy works: The server or an intermediate device may not respond to ICMP. ICMP packet loss doesn’t necessarily mean proxy TCP traffic is being dropped.
• A middle hop shows packet loss in a route trace: If later hops and the destination respond normally, an intermediate device may simply be limiting probe responses. That alone doesn’t prove it’s dropping forwarded traffic.
• Speeds drop only during peak hours: Save comparisons for the same target and node at different times. Try a node with a different network path before repeatedly reinstalling the client.

Layer 3: Check that system proxy, routing, and DNS work as expected

The system proxy affects only apps that follow its settings; it doesn’t send all device traffic through the core. In v2rayN, first check “System Proxy” → “Automatically Configure System Proxy,” then go to “Settings” → “Parameter Settings” and verify the local listening port. Menu labels may vary by version, so use the listener configuration shown in your current interface. TUN mode and the system proxy are different connection methods. For troubleshooting, keep one clearly defined entry point enabled.

If you’ve confirmed that a SOCKS inbound listener is available at 127.0.0.1:10808, you can run the explicit proxy request below in Windows Terminal. This port is an example—don’t copy it without confirming the listener type. An HTTP proxy port can’t be used as a SOCKS port. The sample page checks a small request; it isn’t suitable for measuring large-file throughput.

curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output NUL --write-out "connect=%{time_connect}s start=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

socks5h sends the destination domain to the SOCKS proxy for handling. Where it’s ultimately resolved still depends on the core’s routing, DNS, and outbound settings. Here, time_connect mainly measures the time to connect to the local proxy entry point, not the actual latency from the client to the remote node. Time to first byte also includes proxy negotiation, the connection to the destination, and its response; it isn’t a DNS timing by itself.

On Android, v2rayNG users should also check whether the target app is in the expected proxy scope under “Settings” → “Per-app proxy,” and confirm that system VPN permission is still active. If speeds drop or the connection disconnects only when the screen is off, go to “Settings” → “Apps” → “v2rayNG” → “Battery” and allow background activity. Menu names vary by device manufacturer. If speeds are also slow with the screen on, don’t assume battery optimization is the only cause.

Use logs to tell handshake failures from low throughput

Logs help identify where a request failed; they aren’t bandwidth meters. Note when the issue occurs and keep only the relevant lines from around that time. v2rayN is the client interface; errors come from the core that’s running. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core, so log messages may differ. When you’re done troubleshooting, restore your usual log level to avoid unnecessary disk writes from continuous detailed logging.

If the logs show that requests connect successfully but downloads are slow, return to your node and network path comparisons. Don’t keep changing settings because of occasional warnings that aren’t related to the issue. Before sharing logs, remove subscription URLs, credentials, user IDs, and unnecessary server details. Keep the timestamp, error type, and a redacted outbound label.

FAQ: Low latency, speed test differences, and slowdowns after updates