For users whose nodes connect but pages load slowly at first, downloads are sluggish, or connections often stall in the evening. Establish a baseline under consistent conditions, then compare nodes and network connections before checking local proxy settings, DNS, and Mux. Change one variable at a time and keep your original configuration and test notes. This helps distinguish network congestion from client settings issues.
1. Tell Slow Initial Loads, Slow Downloads, and Disconnects Apart
“Slow” can mean at least three different things: DNS lookups or connection setup take too long, transfer throughput is too low, or connections fail intermittently. If a page stalls on its first load but works after a refresh, check DNS and the handshake first. If a download starts quickly but stays slow, look at bandwidth and congestion. Frequent video reconnects call for checks for packet loss, timeouts, and network switching.
Any step in this chain can slow access. v2rayN is a desktop client; the selected core handles traffic forwarding. On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Latency readings in the client usually cover only a specific test target and method, so they don't necessarily reflect the experience of streaming video or downloading large files.
| What you notice | Check first | How to compare |
|---|---|---|
| First load is slow; later loads are fine | DNS, TLS handshake, connection reuse | Request the same URL repeatedly and record the first result separately from later ones |
| Web pages load normally, but large downloads are slow | Node egress, route bandwidth, destination throttling | Try a second download source without changing nodes |
| Slowdowns in the evening; other times are fine | Shared egress load, congestion on the access network | Run the same test under the same conditions at two different times |
| Only one app is slow | App proxy settings, UDP, destination service | Check the logs to confirm the app is using the expected egress |
2. Establish a Repeatable Speed Test Baseline
Pause cloud sync, system updates, and other downloads first. On the same device, use a fixed URL and a large enough test file. Don't run multiple speed tests at once or switch nodes while recording results. The figures below are suggested test conditions, not performance guarantees or measurements from this site.
Record the current setup
Note the client and core versions, node name, network connection, proxy mode, and test time. Back up the current configuration. Before taking screenshots, hide subscription URLs, user IDs, and keys.
Check the local proxy
In v2rayN, go to “Settings” → “Parameter Settings” to find the local listening port and check whether it provides SOCKS or a mixed proxy. Field layouts can vary by version; use the listening protocol and port shown in your current interface.
Run a consistent test
Select the same node and test the same URL three times. Record the page connection time, then use a fixed download source to check the sustained speed over 30 seconds. Don't treat the initial peak as the result.
Compare one change at a time
First change only the node. Then restore the original node and change only the network. Adjust local settings last. Record each result, and revert any changes you don't need after testing.
On Windows, you can explicitly specify the SOCKS proxy with the command below to reduce interference from browser extensions and system proxy settings. This example assumes the local SOCKS listener is at 127.0.0.1:10808; that's not a universal default, so replace it with your actual listening port before running the command. The example URL is for observing request timing, not testing large-file throughput.
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output NUL --silent --show-error --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/3. Check the Node: Separate Shared Load from Destination Limits
A node has both an incoming connection and an egress route to the destination. Low latency and slow downloads can occur together: a small probe can return quickly even when there isn't enough bandwidth for sustained transfers. A geographically close node may also be slower if its interconnection route takes a detour, so don't choose based on location alone.
- Change only the node: Keep the device, network, URL, and test window the same. If another node is consistently more stable across three tests, the bottleneck is more likely to be the original node or its access or egress route. This alone still doesn't prove that server load is the cause.
- Change only the destination: Use the same node to access two different download sources. If only one source is slow, check for per-connection limits, account restrictions, or regional routing at the destination. Don't rush to reinstall the client.
- Test at different times: Keep separate records for evening and off-peak tests. A consistent difference by time of day suggests congestion or competition for shared resources; compare results across networks to narrow it down.
- Check the units: Speed tests usually report Mbps, while download tools often show MB/s. Using decimal units, 8 Mbps is about 1 MB/s; protocol overhead means actual throughput may be lower.
If available nodes use different access addresses but share the same egress, switching nodes may not help. When reporting an issue to your node provider, include the time, access ISP, node name, destination domain, and repeated test results. This is more useful than simply saying “it's very slow.” Never send a full subscription URL or an unredacted configuration.
4. Check the Network Route: Use Network Comparisons to Find Congestion
Switch back to the original node. Test on your home network, then repeat the same requests using a mobile hotspot. A hotspot uses a different carrier, wireless link, and access route, so it provides a useful comparison, not an absolute benchmark. Large downloads use data; check your plan and limit test duration first.
| Comparison result | Likely cause | What to do next |
|---|---|---|
| Same node works on hotspot but is slow at home | Local Wi-Fi, router, or access route | Retest over Ethernet and pause bandwidth-heavy tasks on the router |
| Only one node is slow on the same network | That node or the route to it | Compare other nodes and record the time and destination address |
| All nodes are slow on both networks | Device settings or a shared destination service | Try another destination service, then compare with a second device |
| Slow on Wi-Fi only; works normally over Ethernet | Wireless interference or weak signal | Test near the access point and check the band and wireless retransmissions |
Don't treat packet loss from a regular ping as proof of packet loss for proxy traffic: the destination may restrict ICMP, and actual traffic may take a different route. If small requests succeed but large responses often stall, then investigate MTU, path MTU discovery, and TUN settings. Without comparative evidence, avoid applying a supposed “universal MTU”; it may introduce fragmentation or compatibility issues.
5. Check Local Settings: Proxy Mode, DNS, and Transport
System proxy settings affect only apps that honor them. TUN uses a virtual network interface to capture matching traffic. The two modes handle different traffic, so a working browser doesn't prove that games, download clients, or all UDP traffic is going through the proxy. Check the logs for the destination domain and outbound tag before comparing speeds.
- In the v2rayN main window, go to “System Proxy” → “Automatically configure system proxy” and test browser access. For a system-proxy-only comparison, turn off TUN first and make sure the browser isn't using a separately configured proxy.
- To test TUN, note its original state first. Go to “System Proxy” → “Clear system proxy,” enable TUN, then check the routes and logs. Testing the modes separately makes it easier to identify the cause; it doesn't mean that enabling both necessarily creates a proxy loop.
- On Android, check system VPN permission and the app routing scope. If the tested app is excluded in v2rayNG or v2flyNG, its results can't be used to judge node performance. Reconnect after changing which apps are included.
- Compare requests for an uncached domain with requests made after it has been cached. Check that the node server's own hostname resolves, and determine whether the destination hostname is resolved locally, by the core, or remotely. These are separate stages; changing one DNS server won't fix them all.
In routing, domainStrategy determines whether domains are resolved for IP rule matching; it isn't a “speed boost” switch. For example, IPIfNonMatch attempts resolution when no domain rule matches, so the result can be checked against IP rules. If that resolution path is slow or failing, it can add wait time. This field belongs under routing, not inside an individual rules entry. Before changing it, make sure the direct and proxy outbound tags, DNS routing, and geodata files are all working.
Check device resources too. If CPU usage stays near 100% during the same download and changing networks makes no difference, local processing limits or competition from other programs may be a factor. First close extra traffic analysis tasks, restore the normal log level, and keep existing security checks enabled. Don't disable certificate verification for speed.
6. Compare Mux Settings and Troubleshoot Log Errors
Mux carries multiple logical connections over fewer underlying connections. It can reduce the cost of repeatedly setting up connections, but it can also make multiple requests share congestion on one underlying connection. It doesn't multiply bandwidth. Its effect varies with large-file transfers, packet loss, and transport combinations. Compare actual usage rather than relying on probe latency alone.
- Start with Mux disabled: Record the current Mux setting, turn it off, reconnect, then test initial page load and a single-file download. If the connection hasn't been re-established, the old settings may still affect the results.
- Then test with Mux enabled: Enable it only if the current core, outbound protocol, and transport combination support it, and keep everything else unchanged. Use settings supported by your client; don't copy Mux fields from a different core.
- Keep what works: If enabling Mux makes pages load faster but downloads slower, choose based on your main use case. If you see a compatibility warning, turn it off again. Don't keep increasing concurrency to mask the problem.
If slow speeds come with errors, use the logs to identify the failing stage first. These are common error snippets; the full prefix varies by core, operating system, and where the error occurs. Don't replace your entire configuration based on a single word—check the address, port, and surrounding context.
Error: connection refused
Cause: The destination port refused the connection. If the address is a local loopback address, check the local listener first—not node bandwidth.
Fix: Check the address and port in the logs and confirm the core is running. If the error points to a remote server, check the node port and whether the server is listening.
Error: context deadline exceeded
Cause: An operation didn't finish before its deadline. It could involve DNS resolution, connecting, the handshake, or waiting for a response; this message alone doesn't prove that the node is overloaded.
Fix: Check nearby log entries to identify the stage. Retest the same node on a different network and different nodes on the same network. Don't just increase the timeout.
Error: no such host
Cause: The hostname couldn't be resolved to a usable address. The name may be incorrect, or the current DNS resolution path may be failing.
Fix: First check whether the error refers to the node hostname or the destination hostname. Verify the spelling and DNS reachability, then reconnect and check the initial load time again.
7. Common Questions About Slow V2Ray Connections
Why are downloads slow when latency is only a few dozen milliseconds?
Latency measures round-trip wait time; throughput measures sustained transfer capacity. Keep the node the same, test two file sources for 30 seconds each, then repeat with another node. If only one source is slow, check for destination-side throttling before chasing lower latency numbers.
Will changing DNS stop video buffering?
DNS mainly affects name resolution and address selection; it can't add bandwidth to a congested route. Compare the wait before playback starts with buffering during playback. If playback starts quickly but keeps buffering, compare nodes and routes first, and check which outbound tag the connection actually uses.
Why is TUN slower than system proxy mode?
TUN may capture more background traffic or change DNS and routing paths. Pause background downloads, then test “system proxy only” and “TUN only” separately. If the issue occurs only with TUN, check app routing, the DNS path, and virtual network adapter settings instead of immediately changing subscriptions.
Can changing the core fix every slow connection?
No. First confirm that the selected core supports the node's required protocol and features, then compare with the same configuration. If the server requires REALITY or specific XTLS behavior, you can't use an Xray configuration unchanged with V2Fly. Network congestion and node egress limits won't disappear just because you switch client names.
After troubleshooting, you should be able to narrow the issue down to a reproducible finding, such as “one node is slow across multiple networks,” “multiple nodes are slow on one access network,” or “only one local proxy mode is slow.” Keep the original test notes and any settings that helped, and remove temporary rules. If you still need to report the issue, include redacted logs and your comparison conditions so the next check can start with evidence.