For users who can connect but experience slow page loads or inconsistent download speeds. Keep the test target and local proxy entry point fixed, then compare nodes, switch networks, and review logs to narrow the cause to the node's exit, the access route, or local settings. Test DNS, routing, and Mux separately to avoid changing several options at once and losing track of the cause.
1. Tell Slow First Loads, Slow Downloads, and Intermittent Drops Apart
“Why are downloads so slow when latency is only 80 ms?” There’s no contradiction. A client’s latency test usually measures just one connection or request; it doesn’t reflect sustained throughput. Speeds shown in a node list also depend on the test server, duration, and number of concurrent connections. Identify the symptom first, then choose the right test—it’s more useful than sorting by latency and switching nodes repeatedly.
| Symptom | What to check first | First comparison |
|---|---|---|
| First page load takes a few seconds; refreshes are much faster | DNS lookup, connection setup, and remote response | Request the same domain several times and note time to first byte |
| Pages load, but large downloads stay slow | Node exit capacity, route throughput, and rate limits | Download the same file through another node without changing local settings |
| Slow in the evening, back to normal during the day | Shared node load and access-network congestion | Retest the same node and target at different times |
| All nodes drop connections intermittently | Wi-Fi, router, or other tunneling software | Try Ethernet or another access network |
Before testing, pause cloud sync, system updates, and other downloads. Disable any proxy extensions configured in your browser, then choose one familiar webpage and one large file that can be downloaded. Ideally, use the same file URL each time. Different sites have different servers, caches, and rate limits, so their speeds aren’t directly comparable.
These figures are suggested sampling guidelines for troubleshooting, not measured node performance or pass/fail thresholds. Keep units consistent: 10 MB/s in a download manager is about 80 Mbps in decimal units. A broadband plan’s advertised speed is a link maximum; actual file transfers are also affected by protocol overhead, Wi-Fi signal, and the remote server.
2. Node Layer: Compare Load and Exit Routes, Not Just Protocol Names
Start with two nodes that use different exits from the same subscription, keeping the routing mode, test target, and test time roughly the same. If only one node is slow, suspect its exit bandwidth, shared load, or route to the target site. If both are slow, compare against an available node from a different provider to avoid mistaking an upstream issue for a problem with every node.
- Record the baseline: Note the node label, protocol, transport, test time, and median download speed. Remove server addresses, user identifiers, and subscription links before sharing the results.
- Keep the target consistent: After switching the active server in v2rayN, start a fresh download rather than reusing an existing long-lived connection. If needed, quit and reopen the browser completely.
- Cross-check: Test two independent sites through the same node. If only one is slow, the issue may be the route between the node’s exit and that site, or a limit imposed by the site itself.
- Check device load: Look at Task Manager or Activity Monitor. If the core process is using a lot of CPU over time, rule out a local performance bottleneck before blaming the remote server.
VMess and VLESS are proxy protocols; TCP, WebSocket, and gRPC are transport-related options, while TLS provides part of the transport security. They aren’t interchangeable “speed modes.” The same protocol can perform very differently through different entry points or exits. Transport, path, and TLS settings must match the server—don’t switch them arbitrarily on the client.
Takeaway: First confirm whether only one node is slow
On the same device, network, and target, if switching exits improves speeds across three consecutive rounds, keep the faster node and report the time and target to your provider. There’s no need to immediately change DNS, Mux, or system network settings.
3. Route Layer: Use Another Access Network to Check for Congestion
A working node doesn’t guarantee a stable route to it. Wi-Fi interference, router load, carrier interconnection, and evening congestion can all cause retransmissions and lower throughput. The most useful comparison is to switch access networks on the same computer while keeping the same node—for example, switch from home broadband to a mobile hotspot. This makes the results easier to interpret than changing both the node and network at once.
- Check your local network first: On Windows, use
ipconfigto find the default gateway. On macOS, find your router address under System Settings → Network. Test that address to check whether the local Wi-Fi link is stable. - Then check the node entry point: Test connectivity to the node address if probing is permitted. A node that doesn’t respond to ICMP isn’t necessarily unreachable through the proxy; check an actual TCP connection and the client logs too.
- Finally, switch access networks: Disconnect any other active tunnel, then retest over a hotspot. Use the same node and download URL on both broadband and hotspot, and note whether the connection was re-established.
# Windows: Replace the address below with your actual default gateway
ping -n 30 192.168.1.1
# macOS: Replace the address below with your actual default gateway
ping -c 30 192.168.1.1192.168.1.1 is a common gateway address, but use the one shown on your device. If requests to the gateway repeatedly time out, move closer to the router or use Ethernet. If the gateway is stable but all remote connections are slow, investigate the external route next. Don’t treat one timeout or high packet loss at a single intermediate router as proof of a route failure; some devices give probe packets a lower response priority.
Takeaway: If the same node works on another network, check the access route first
If home broadband is slow but the hotspot works, leave the node settings alone and check your Wi-Fi environment and carrier route. If only one node is slow on both access networks, focus on that node instead of resetting your local network again.
4. Local Entry Point: Confirm Test Traffic Is Actually Proxied
Browsers, command-line tools, and system apps may not use the same proxy settings. v2rayN’s system proxy mainly affects apps that read the system proxy settings; TUN mode routes traffic in a different way. For troubleshooting, choose one clearly defined entry point. Don’t stack a browser proxy extension, system proxy, and another set of tunnel rules at the same time.
- In v2rayN, open Settings → Parameter Settings and check the local listening address, port, and inbound type. The relevant options may be on a basic settings page in some versions, so follow the labels in your current interface.
- The command below assumes
127.0.0.1:10808is a local entry point with SOCKS enabled. If your port is different, update the command first. Don’t use this SOCKS command for an HTTP-only entry point. - Select the active node and check the logs for a connection to the test target. After making a request, compare the result with what you see in the browser.
# Windows PowerShell
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} start=%{time_starttransfer} total=%{time_total}\n" https://example.com/
# macOS Terminal
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --output /dev/null --silent --show-error --write-out "connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n" https://example.com/example.com is used here only to demonstrate a small page request; it isn’t a bandwidth test server. socks5h passes the target hostname to the SOCKS proxy instead of resolving it locally with curl; this doesn’t determine which DNS server the core ultimately uses. When using a local proxy, time_connect mainly measures the connection to the local proxy entry point, not the round-trip time to the node. time_starttransfer includes time spent on subsequent proxy negotiation, the remote connection, and the server response.
curl: (7) Failed to connect
Cause: Often the local listener isn’t running, or the address or port is wrong. The full log should identify the destination. Fix: Confirm the core is running, enter the port from Parameter Settings, and check the inbound protocol.
curl: (28) Operation timed out
Cause: The request didn’t finish within the configured time limit. The node connection, DNS lookup, or remote response could be responsible; this line alone isn’t enough to tell. Fix: Check the core logs from the same time, then try a different target and node in turn. Don’t just increase the timeout.
dial tcp: lookup
Cause: This is a common fragment in DNS resolution errors from Go-based cores; the domain and error details that follow are what help pinpoint the issue. Fix: First determine whether the failed lookup was for the node’s server domain or the target domain, then check the relevant DNS route and network reachability.
5. DNS and Routing: Trace Where Traffic Goes Before Changing DNS
DNS is worth checking when the first page load is slow, but it doesn’t explain every slow connection. Once a download is underway, changing DNS alone usually won’t improve throughput on that same connection. A different DNS result may change the destination address used for a later connection—that’s a separate effect. First distinguish a slow DNS lookup from slow transfers after the connection is established.
| What to check | What to verify | Common misdiagnosis |
|---|---|---|
| Node server address | Before connecting to the proxy, can the server domain be resolved over an available route? | Routing the node’s own DNS lookup through a proxy that hasn’t connected yet |
| Target domain lookup | Is the lookup handled by the app, the local system, or the core—and does that match expectations? | Changing only system DNS, then comparing it with a result resolved through the proxy |
| Routing rules | Which rule matches the target, and which outbound tag is actually used? | Assuming every request uses the same exit just because the system proxy is on |
| Browser secure DNS | Does the browser make a separate encrypted DNS request? | Treating different DNS behavior between the browser and command line as a random failure |
In v2rayN, open Settings → Routing Settings and review the enabled rule sets. If the menu moves in your version, look for “Routing Settings.” V2Ray/Xray routing rules are usually matched in order, and outboundTag must correspond to a defined outbound tag. If the logs show that the target is sent through a direct outbound, check the rules before switching proxy nodes again.
- Back up the current rules first. For temporary changes, target just one test domain, then restore the original settings so changes to the full routing setup don’t skew the results.
- Check that the DNS server itself is reachable. With encrypted DNS, also consider how its server hostname is resolved initially and whether the connection goes direct or through the proxy.
- On Windows,
ipconfig /flushdnsclears only the system DNS cache; it may not clear browser or core caches. If needed, close the browser, restart the core, and make a fresh request.
6. Mux: Turn It Off to Establish a Baseline, Then Decide Whether to Keep It
Mux reuses connections; it doesn’t increase a node’s bandwidth. It can reduce connection setup overhead for many short connections, but it can also make multiple logical connections share the effects of blocking on the underlying transport. It may not help with sustained large-file downloads. Results depend on the core implementation, node protocol, and transport settings, so there’s no universally optimal concurrency value.
- Record the current settings: Note the Mux status for the client, core, and node. Client and core versions are separate; record both when reporting an issue.
- Retest with Mux off: Look for Mux options under Settings → Parameter Settings in v2rayN. If there’s no such option, don’t guess at a configuration field; confirm whether the current core and configuration type support it.
- Make sure the change takes effect: Save, restart the core, and establish a new test connection. The scope of settings may differ for subscription nodes, individual nodes, and custom configurations; check the generated configuration and logs.
- Compare separately: Repeat each test three times under the same conditions, recording short page loads and sustained downloads separately. If turning Mux off reduces drops and improves everyday use, leave it off—there’s no need to turn it back on just to add complexity.
7. Common Questions and Final Checks
The node with the lowest latency downloads the slowest. Which should I choose?
Choose based on how you’ll use it. For video and large files, prioritize sustained throughput and connection stability; interactive tasks also depend on response time. Test the same file three times on each node instead of treating one latency result as an overall ranking.
Speed tests hit full speed, but pages load slowly in the browser. What should I do?
First check browser proxy extensions, secure DNS, and connection reuse. Quit the browser completely and try again, then compare with a curl request that explicitly uses the local proxy. If only one site is slow, check the route between that site and the node’s exit.
My Android phone is slow too. Can I copy the computer’s settings?
Use the same layered troubleshooting approach, but don’t copy local ports or traffic-routing modes. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. First compare equivalent nodes and targets on the same Wi-Fi network, then check whether other tunnels or battery-saving restrictions are affecting the phone.
It’s only slow in the evening. Can changing Mux or DNS fix it?
First compare the same node during the day and in the evening, then try another access network or a node from a different provider in the evening. If slowness tracks the time of day and route, suspect congestion or shared capacity. Test DNS separately only if the initial lookup is unusually slow.
When you finish troubleshooting, keep a brief record: time, client and core versions, access network, node label, target domain, results from three runs, actual outbound, and relevant error lines. Before sending it to your provider, hide subscription links, user identifiers, and sensitive server details. Reports such as “the same node works on a hotspot” or “switching exits fixed it on the same network” are usually more useful than simply saying “the internet is slow.”
- Node-level differences: Keep a working exit and report when and where the slow node is affected.
- Route-level differences: Fix the Wi-Fi or access route instead of changing protocols at random.
- Local differences: Undo unrelated changes and keep only settings that have been verified in repeated tests.