For users who have imported a subscription and can connect, but experience slow page loads or downloads. Start with repeatable test conditions, then narrow down the cause by changing one thing at a time: the node, the network connection, or a local setting. By the end, you’ll be able to distinguish latency, throughput, and DNS resolution issues—and keep a reproducible record instead of switching protocols at random.
First, identify the slowdown: high latency, slow downloads, or a long wait before pages load
The latency shown by a client is not the same as download bandwidth. A TCP connection test usually measures how long it takes to establish a connection; an HTTP test through a proxy may also include the handshake and the destination server’s response time. These test methods aren’t directly comparable, and neither can tell you whether a node can sustain video playback. When V2Ray feels slow, first note exactly which action is taking too long.
| What you notice | Likely cause | Next step |
|---|---|---|
| The first visit is slow, but subsequent downloads are normal | DNS, connection handshake, or destination response | Compare load times on the first and repeat visits |
| Pages load, but large files download slowly throughout | Node load, speed limits, or network congestion | Try another node with the same file and network |
| Download speeds repeatedly drop, or the connection occasionally disconnects | Wireless interference, packet loss, or an unstable route | Retest over a wired connection or another network |
| Only one website is slow | The destination, its CDN, or a specific routing rule | Check the domain’s outbound route, then compare with another destination |
Another common source of confusion is units. Internet plans are often advertised in Mbps, while download tools may show MB/s; the numbers differ by a factor of about 8. For example, 80 Mbps converts to a theoretical 10 MB/s. Actual transfer speeds are also affected by protocol overhead and shared links. This conversion helps standardize units; it doesn’t mean a node should reach the advertised bandwidth of your internet plan.
Establish a baseline: keep the destination fixed and change one condition at a time
Before testing, pause system updates, cloud sync, and bandwidth-heavy tasks on other devices. Record your connection type, client and core versions, node name, and test time. v2rayN is a desktop client. On Android, v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Record the client and core versions separately; “latest V2Ray” isn’t specific enough.
These are testing recommendations and a unit conversion—not results measured by this site. Choose a fixed HTTPS file that you’re authorized to access and that can transfer continuously for long enough. Keep the test tool and number of concurrent connections the same. A small file may finish before the connection stabilizes, while speed-test sites that automatically switch servers introduce extra variables.
- Check your local baseline: Turn off the proxy and access a fixed resource that can be reached directly to confirm that your internet connection itself is working normally. This only reflects your local connection; it says nothing about the cross-border route.
- Test the current node: Restore your original proxy settings and test a fixed destination through the proxy for 3 rounds, observing each for about 30 seconds. Record the sustained speed and any interruptions.
- Change just one variable: Keep the network the same and switch nodes, then keep the node the same and switch networks. Don’t change DNS, routing, and transport settings at the same time.
- Restore your original settings: Revert temporary changes when testing is complete so troubleshooting settings aren’t left in the client.
Layer 1: Check node load and server-side limits
If only one node stays slow on the same network and to the same destination, start by checking that node and its route. Possible causes include a busy server CPU or bandwidth, account speed limits, congested egress, or issues along the route from the node to the destination. Clients usually can’t show the server’s actual load, so switching nodes and seeing an improvement narrows down the cause but doesn’t prove the server is overloaded.
- Choose a node that’s meaningfully different: Nodes with different ports but the same name may still share a server or egress route. Where possible, compare available nodes that the provider identifies as being in different regions or on different routes.
- Check the service terms: Check your remaining data allowance, plan speed limits, and concurrent connection limits. If you’ve hit a limit, changing your local DNS is unlikely to help.
- Test at different times: For example, run the same test at 10:00 and 21:00. If speeds drop significantly only in the evening, record the pattern and compare results on another network.
- Don’t update settings while testing: A subscription update may change the server address or parameters. If you need to update it, start a new set of test records afterward.
What to do: Report reproducible differences between nodes
If node A is slow in all 3 rounds while node B works normally under the same conditions, send the provider the test times, your internet provider, the destination, and both sets of results. This is more useful than reporting only “low latency but very laggy.” Don’t include subscription links, UUIDs, or other authentication details.
Choosing VMess or VLESS won’t replace this comparison. VMess has different authentication and encryption mechanisms from the transport security configuration used with VLESS, but total throughput also depends on server capacity, transport, round-trip time, and packet loss. The protocol must match the server; changing the protocol field in the client alone won’t make it faster.
Layer 2: Compare networks to identify congestion and packet loss
If several nodes slow down at once, check your local connection first, then investigate the upstream route. A full Wi-Fi signal doesn’t rule out interference or queuing on the router. When local upload bandwidth is saturated, acknowledgments and interactive requests can be affected, making web pages feel noticeably sluggish. On desktop, try a wired connection. On Android, switch between Wi-Fi and mobile data, keeping data usage in mind.
This sequence shows the different stages a request may pass through; it doesn’t mean every connection uses a separate relay. Keep the node and destination unchanged and switch networks. If performance improves, the difference is likely related to your access network or the route beyond it. If switching nodes helps but switching networks doesn’t, the node’s server or route is a more likely cause. If both changes help, continue cross-testing rather than forcing a single explanation.
- Check your local gateway: On a network where diagnostics are permitted, briefly test latency to the actual default gateway. If wired connections are stable but Wi-Fi is not, start by troubleshooting the wireless connection.
- Interpret ICMP with care: A gateway or server may limit ICMP replies. Packet loss in ping tests doesn’t necessarily mean application traffic is being dropped, and no reply doesn’t mean the proxy port is unreachable.
- Use route tracing as a clue, not proof: Packet loss at one intermediate router followed by normal results at later hops often means probe packets are being rate-limited. Don’t assume that hop is the source of the problem.
- Pause bandwidth-heavy tasks first: If latency improves after uploads stop, check shared local bandwidth and router queues before changing core settings.
Layer 3: Check system proxy, TUN, routing, and DNS
Start local troubleshooting by confirming where requests are actually going. A system proxy relies on apps honoring the system proxy settings; TUN uses a virtual network interface to capture matching traffic. A status indicator that says “started” doesn’t prove either method is working. Enable logs, reproduce the issue once, then check the inbound connection, matched rule, and outbound route so other background connections don’t obscure the results.
- Check how traffic is routed into the client: On desktop, check the System Proxy setting and current routing choice in the v2rayN main window. On Android, confirm that the VPN service for v2rayNG or v2flyNG is running and check which apps are covered by per-app proxy settings. Labels may vary by version.
- Check the listening port: Read the local port shown by the client. If an app is configured manually with
127.0.0.1:10808, confirm that the client is listening at that address and port and using the expected proxy protocol. Port 10808 is an example, not a fixed default across versions. - Simplify traffic capture: Temporarily quit other proxy or VPN tools and retest with one clear traffic-routing method. Using the system proxy and TUN together isn’t necessarily a problem, but during troubleshooting, avoid extra forwarding and routing loops that can complicate diagnosis.
- Confirm the routing rule: Check whether the slow site is accidentally going direct, or whether a local resource that should connect directly is being sent through the remote proxy. If needed, briefly switch to a test rule that routes traffic through the proxy, compare it with the original rules, then restore your settings.
- Then check DNS: Distinguish resolution of the node server address from resolution of the destination domain. If the node address can’t be resolved, the connection won’t start. Slow resolution of the destination domain is more likely to cause a long wait on the first visit. Use the logs to identify which is happening; don’t replace every DNS setting at once.
DNS changes can affect resolution time, the returned IP address, and subsequent routing, but they can’t create more server bandwidth. If only one domain is slow, consider whether the returned CDN address is a good fit for your current egress route. Don’t use a hard-coded IP as a permanent replacement for a domain: HTTPS certificate validation, SNI, and virtual hosting may rely on the original domain, and connecting directly to an IP can introduce different errors.
Use logs to distinguish slow connections from connection errors
Repeated retries can make a page look slow when the underlying problem is actually a failed connection. The following are common error snippets as they appear in logs; surrounding text varies by core, operating system, and version. Check the destination address, port, and stage of the connection as well. The same timeout message can occur during DNS resolution, a connection to the node, or a connection to the destination.
Error: i/o timeout
Cause and fix: A network read or write operation exceeded its timeout. First, check the same log entry to see whether the connection was to the node or the destination. Keep the destination fixed and test another node or network instead of masking the issue by simply increasing the timeout.
Error: connection refused
Cause and fix: The destination or an intermediate device actively rejected the connection, often because the address, port, or service state is incorrect. Check the server port in your subscription. If the error involves a local loopback address, make sure the client core has started and is listening.
Error: address already in use
Cause and fix: The local address and port to be bound are already in use. Quit any duplicate client instances or change the listening port, then update any apps configured to use that port.
Error: no such host
Cause and fix: The hostname could not be resolved. Check the hostname and node address in the logs for typos, then check DNS connectivity. Don’t assume this means the node lacks bandwidth.
Return logs to their normal level after troubleshooting. Before sharing logs, redact authentication fields, subscription URLs, and personal browsing records; include only the time, relevant error context, and necessary network details. For routine v2rayN checks and maintenance, see the guide to testing and maintaining nodes.
Common questions: Why is real-world performance slow when speed tests look fine?
The node’s latency is only a few dozen milliseconds. Why does video still buffer?
A latency test doesn’t measure sustained throughput and may not connect to the CDN used by the video service. Keep the video quality fixed and observe sustained playback, then try another destination through the same node. Also check whether the app is included in your proxy settings.
TUN made things slower. Should I keep adjusting the MTU?
Turn off TUN first and compare with an app that works through the system proxy. Check routing and DNS capture as well. Investigate path MTU only if you see clues such as transfers stalling at a particular data size. Don’t copy a value blindly, and record the original before changing it.
My computer works fine, but Android is slow. Is the core to blame?
First, use the same node, network, and destination, then check per-app proxy settings and routing rules. v2rayNG and v2flyNG use different cores, but Wi-Fi conditions, background restrictions, and configuration differences can also affect results. The platform alone isn’t enough to identify the cause.
It gets slow every evening. Will updating the subscription fix it?
Updating a subscription may help only if the provider has changed an address or port, or added available nodes. Keep the 3-round test results from daytime and evening, then compare another network and another node. If the congestion pattern is consistent, choose a different route or contact the provider.
Wrap-up: Keep a concise troubleshooting record
Record the time, network, client and core versions, node, test destination, results from 3 rounds, and the one change made. First confirm that traffic is being routed correctly, then compare nodes and networks to narrow down the cause. Change DNS, routing, or transport settings only when the evidence points to them.