Start by keeping test conditions consistent, then compare nodes, networks, and apps. This guide is for cases like a connection that works but downloads slowly, low latency with frequent buffering, or speeds that drop in the evening. Record latency, sustained download speeds, and log results at each step to narrow down the cause and decide whether to switch nodes, contact your route provider, or adjust Windows proxy settings.
First, distinguish high latency, low throughput, and connection failures
Open v2rayN and stop any bulk tests of other nodes. Select the server you’re currently using and test it. In many versions, right-click a server in the list to find “Test server real connection latency” and “Test server speed”; labels and shortcuts may vary slightly by version. The real connection latency test checks whether a request completes, while the speed test measures transfer performance for its test resource. They are not interchangeable.
V2Ray is a name used for a proxy technology ecosystem; v2rayN is a desktop client for managing server configurations, launching the core, and setting up a proxy. How quickly a webpage loads also depends on server load, the connection to the entry point, the route from the exit node to the destination, and local apps. Find out which part is slow before changing protocols or reinstalling anything.
| What you observe | Check first | What you can’t conclude yet |
|---|---|---|
| Pages take a long time to load, but downloads are fast once started | DNS, connection setup, destination response | A slow initial page load alone doesn’t prove you have insufficient bandwidth |
| Connection succeeds, but large downloads remain slow | Node load, rate limits, network congestion | Low latency alone doesn’t mean the node is working properly |
| Only one website or app is slow | The site’s route, app proxy settings, or destination exit | The entire subscription is not necessarily unusable |
| All nodes and direct connections are slow | Local network, background traffic, Wi-Fi signal | Don’t assume the proxy protocol is the cause |
Keep test conditions consistent and record comparable results
Use the same computer, download resource, and a similar time of day. Pause cloud sync, system downloads, and other speed tests. Start with Ethernet, or keep your Wi-Fi position unchanged. Test one node at a time, run each test three times, record the median, and observe sustained speeds for at least 30 seconds. Speed tests use data, so keep comparisons brief if your plan has a data cap.
Internet plans are usually advertised in Mbps, while download tools often show MB/s. In decimal units, 100 Mbps works out to about 12.5 MB/s in theory, before protocol overhead. This is a unit conversion, not a node speed test or a speed guarantee. Include units when comparing results—a reading of 8 MB/s is not 8 Mbps.
-
Record your setup
Note the v2rayN and core versions, network connection type, test time, and current routing mode. You can start with the startup information in the main window log. Don’t update the client and core at the same time as testing.
-
Test latency
Select a node in the server list, right-click it, and choose “Test server real connection latency.” Run the test three times and record how many succeeded and the results. A single timeout doesn’t mean the node is down.
-
Test speed
Right-click the same node and choose “Test server speed,” then check sustained transfers with an actual download. The built-in test depends on its test server and doesn’t represent the speed limit for every website.
-
Compare results
Record the results for node A, node B, and a direct connection in turn. Keep the file, app, and routing mode unchanged, and change only one variable at a time so you can tell what made a difference.
Layer 1: Check for a single-node issue or a shared entry bottleneck
Start by comparing two or three nodes in the same subscription. Prefer nodes with genuinely different entry points or regions rather than ones that only have different names. A subscription distributes configurations; it is not a separate network route. Multiple nodes may share an entry point, server, or bandwidth pool. If switching names doesn’t change the actual route, speed test results may remain similar.
- Only node A is slow: Switch to B and repeat the same download. If speeds recover and stay up, suspect A’s load, rate limits, or its route to the destination first.
- All nodes hit roughly the same speed ceiling: Check for plan speed limits, local bandwidth constraints, and background traffic. A similar ceiling is a clue, not proof that your provider is throttling you.
- Speed tests look good, but websites are slow: Check another destination. Different sites may use different content delivery nodes, so a test server’s performance doesn’t predict how video or file-hosting sites will perform.
- Latency occasionally drops very low, but downloads keep stalling: Look for retransmissions, dropped connections, or repeated app retries. Logs from the same time period are more useful than a screenshot of the lowest latency reading.
Layer 2: Compare times and networks to locate route issues
If the same node works well during the day but slows down in the evening, check the access network and relay route first. Use the same node and resource to record results in the morning and evening, then test from the same computer using a mobile hotspot. A hotspot changes the access network, but doesn’t necessarily change only one carrier-related factor. Use the results to narrow down the issue, not as definitive proof that a particular link is at fault.
| Comparison result | Likely clue | Next step |
|---|---|---|
| Home network is slow; hotspot is noticeably faster | Home internet connection, router, or route from that network to the entry point | Try Ethernet, check background traffic, then compare different entry points |
| Both connections are slow only in the evening | Peak-hour load on shared nodes, relays, or exit points | Try a dedicated entry point and share results from different times of day |
| Only one destination is slow on both networks | Route from the exit to the destination, or the destination itself | Try an exit in another region and compare with a second destination |
| Direct and proxied downloads both slow down | Local bandwidth, Wi-Fi interference, or access network congestion | Rule out local network issues before continuing proxy tests |
A regular ping to the server address measures ICMP only, which some servers limit or ignore. A relay may also hide the rest of the route. A ping timeout while webpages load normally isn’t a contradiction; likewise, low ping doesn’t guarantee enough bandwidth at the exit. Don’t treat a non-responsive intermediate hop as confirmed packet loss.
Layer 3: Confirm the app is actually using the local proxy
First, check “System proxy” in the v2rayN status bar or tray menu and select “Automatically configure system proxy.” Then open Windows “Settings” → “Network & Internet” → “Proxy” and verify the address and port. The system proxy determines how apps that follow this setting connect through the client; routing rules determine which outbound route they use after entering the client. These are separate settings, and command-line tools may not use the Windows system proxy.
In v2rayN, go to “Settings” → “Parameter settings” and check the local listener settings. The command below uses 10808 as an example of a local SOCKS port; use it only after confirming that the port provides a SOCKS or mixed listener. If your port is different, replace it with your actual value. Don’t guess the port and treat that as a fix.
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -o NUL -sS -w "connect=%{time_connect}s start=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/In Windows PowerShell, run curl.exe explicitly to avoid command alias differences in some environments. socks5h sends the destination hostname to the proxy for resolution; example.com here is for checking the request path, not for testing large-file downloads. time_connect mainly measures the time to connect to the local proxy; it is not the node’s round-trip latency. Time to first byte also includes the later handshake and destination response.
- The command succeeds, but the browser is still slow: Temporarily disable browser proxy extensions, close and reopen the browser, then check the system proxy again. Don’t let extension rules and the system proxy both rewrite the route.
- Connection to the local port is refused: Confirm the core is running and the listening port is correct. Check the logs for a port-in-use error. The request hasn’t reached the server yet, so there’s no need to change your subscription.
- Problems occur only when TUN is enabled: Turn off TUN and establish a baseline using the system proxy. If that works, check TUN permissions, DNS, and routing settings one at a time. Don’t run multiple traffic interception tools at once.
- A specific domain uses the wrong outbound route: Check the active routing preset and the order of custom rules. If needed, briefly test with an explicit proxy outbound rule, then restore your usual routing configuration.
Use logs to distinguish dropped connections from configuration errors
Find the time of the failure in the main window log, reproduce it once, then read the surrounding lines. The examples below are possible errors; prefixes vary by core and version. A single error points to a failure stage, but a timeout can come from the network or the remote service. Don’t assume it means the node lacks bandwidth.
bind: Only one usage of each socket address
Cause: Another process is using the local address and port, so the listener can’t start.
Fix: Exit duplicate client instances, or change the listening port under “Settings” → “Parameter settings.” Restart the core, then check that the app is using the same proxy port.
dial tcp: lookup
Cause: The hostname shown in the log failed to resolve. Check the address on the same line to determine whether it’s the node’s hostname or the destination hostname.
Fix: Check the spelling and DNS reachability first, then inspect the relevant DNS routing. Avoid changing node settings and DNS settings at the same time.
i/o timeout
Cause: A network read or write operation exceeded its timeout. The issue could be the local connection, the server, or the destination’s response.
Fix: Check the address in the error, then retest with another node and another access network. Record whether the errors cluster at the same time of day.
tls: failed to verify certificate
Cause: TLS certificate verification failed, possibly because of the system clock, the certificate chain, or the server name in the configuration.
Fix: Correct the Windows date and time, then check the configuration provided by your service provider. Don’t bypass certificate verification to troubleshoot a speed issue.
Common questions and final checks
Why does video still buffer when latency is only 50 ms?
50 ms is the response time for a single request, not a measure of sustained bandwidth. Check the download graph for 30 seconds, then compare another video quality and a different exit. If only that video site has a problem, check its route and the exit instead of chasing lower latency.
Can updating my subscription fix slow speeds?
Updating can help directly only if your provider has changed node addresses, ports, or configurations. Select “Subscription group” → “Update current subscription (without proxy)” to get the latest configuration. If you can’t access the subscription source directly, use the update-through-proxy option in the menu. Updating won’t increase your plan’s bandwidth.
Will changing DNS make downloads faster?
DNS mainly affects whether a name resolves and which address is returned. It may change the content delivery node you reach, but it won’t add capacity to the route. If the initial page load is slow and logs show resolution failures, troubleshoot DNS. If a download is already stable but slow, check the node and route first.
Should I increase all concurrency and connection limits?
Restore the defaults first and establish a single-connection baseline. More download threads may speed up a particular task, but they can also trigger rate limits or use more resources; they won’t fix a congested route. Change one setting at a time and record sustained speeds before and after.
Summarize the results in one reproducible report: which node, which access network, what time, which destination, what sustained speed, and what change restored performance. If the issue reproduces only on one node, send the report to its operator. If all nodes vary with the access network, keep checking your local setup and access route. If an explicit proxy request works but one app doesn’t, revisit its proxy and routing settings. With these results, you can make a better-informed decision about changing providers.