For users who have imported a subscription and can connect, but experience slow page loads, low download speeds, or frequent slowdowns in the evening. This guide uses v2rayN on Windows as its reference. Start by keeping test conditions consistent, then check the node, network path, and local proxy separately. By the end, you’ll have repeatable test notes to help decide whether to switch nodes, change networks, or adjust local settings.
First, distinguish latency, throughput, and connection failures
“Slow” isn’t a single metric. A long blank screen after opening a page may point to DNS resolution, connection setup, or a slow response from the remote server. A large download that starts quickly and then slows down is more likely a throughput issue. Disconnects every few minutes call for checks of packet loss, network changes, and core logs. Describe the symptom first to avoid using a single latency test to explain every problem.
| Symptom | Check first | What you can’t conclude |
|---|---|---|
| Pages take a long time to open | DNS resolution, connection setup, time to first byte | Doesn’t necessarily mean the node has low bandwidth |
| Downloads are consistently slow | Sustained download speed, destination rate limits, exit-node load | Doesn’t necessarily mean the local proxy port is faulty |
| Noticeable slowdowns in the evening | Compare multiple nodes and networks at the same time of day | Time of day alone doesn’t prove the server is oversubscribed |
| Latency test times out | Test whether the destination is reachable; check node settings and log errors | Doesn’t mean every destination is unavailable |
v2rayN’s TCP connection latency mainly reflects the connection to the node’s address and port. “Real connection latency” tests a destination through the proxy, making it closer to an actual request, but it still doesn’t measure large-file download performance. Neither test guarantees a good experience on a particular video or download site. If the real connection test succeeds but one site is slow, compare that destination first instead of repeatedly changing protocols.
Set up a repeatable test baseline
Change only one variable at a time. Pause cloud sync, system updates, and other downloads, and close proxy tools you aren’t testing. Use the same browser, destination, and connection type throughout. The steps below refer to the common v2rayN desktop interface; menu wording may vary by version, so follow the labels shown in your current window.
-
Record your current settings
Open Settings → Parameter Settings and note the local listening port. Also record the system proxy status, routing mode, and TUN status shown at the bottom of the main window. Note the active node name, client version, and core version, and keep them unchanged for comparisons.
-
Set the active node
Select a node in the server list, right-click it, and choose “Set as active server.” Make sure the active indicator moves to that node, then run “Test server real connection latency” on the selected entry. Don’t rely on the selection highlight alone to tell which node is in use.
-
Run three rounds of tests
Test the same node three times, about 10 seconds apart. Record the number of successful tests and the median latency, then visit the same webpage. For download tests, use the same permitted test file and observe a stable period of about 30 seconds. Don’t draw conclusions from the initial speed spike.
-
Keep comparison notes
Switch to another node and repeat the same steps. Record the time, network, destination, latency, speed, and any error logs. Don’t change the node and network at the same time, or you won’t know which change caused the difference.
You could record results in this format: “8:30 p.m. / home broadband / Node A / 3 of 3 successful / 180 ms median / 2.0 MB/s sustained.” This is only an example, not a test result from this site or a pass threshold. What matters is the relative change under the same conditions and whether repeat tests produce similar results.
Layer 1: Node load and destination exit
Nodes in the same subscription may share an entry point, exit, or upstream bandwidth. Switching among several similarly named nodes may not change the actual bottleneck. Compare two nodes the provider explicitly identifies as using different routes or exits. Don’t infer physical location, route quality, or available bandwidth from a region label alone.
- Only one node is slow: Keep the destination the same and compare other nodes. If the difference is repeatable, the issue is more likely with that node or its network path. Client-side results alone can’t identify whether the cause is CPU load, rate limiting, or shared bandwidth.
- One site is slow on the same node: Try a different destination. Regional routing, content servers selected for the exit IP, or site rate limits can all affect performance.
- All nodes are slow: First check whether your local network is also having problems, then try a different connection. Multiple nodes may share a route, so slow speeds across all of them don’t rule out remote causes.
- Only slow during peak hours: Retest the same node off-peak and keep records from at least two time periods. Then share the specific times and symptoms with your provider.
VMess and VLESS are proxy protocol names, not speed tiers. Switching protocols often changes the server, transport, and route at the same time, so you can’t attribute the result to the protocol alone. The node address, port, transport, and security settings must match the server configuration. Don’t change them at random just to run a speed test.
Layer 2: Local connection and network routes
Proxy requests pass through several stages, and congestion, packet loss, or slow responses at any stage can make an app appear stuck. Understand the request path before choosing what to compare. The flow below is a conceptual diagram; connection setup isn’t identical for every transport.
On home Wi-Fi, try a wired connection or test closer to the router. If local network transfers and ordinary direct-access websites are also slow, address Wi-Fi interference, router load, or broadband congestion first. For a direct-connection test, use a site that’s normally reachable without a proxy; a destination that requires a proxy doesn’t indicate a broadband problem.
| Keep unchanged | Change only | What the result can tell you |
|---|---|---|
| Node, destination | Switch from home broadband to a mobile hotspot | An improvement points to a difference in the access network or a later part of the route; it doesn’t pinpoint a specific hop |
| Access network, destination | Switch from Node A to Node B | An improvement points to a difference in the node or its network path; it doesn’t prove the server is overloaded |
| Node, access network | Switch from Destination A to Destination B | If only one site is slow, keep checking the route between that destination and the exit |
Windows ping and tracert generally don’t use the proxy just because the HTTP system proxy is enabled. They can help assess the network between your device and the node, but they don’t represent the route from the proxy exit to the destination. A hop that doesn’t respond to ICMP may simply be configured not to respond; that alone doesn’t prove packet loss affecting application traffic.
Layer 3: System proxy, ports, and routing rules
A system proxy is a setting that apps can use; it doesn’t force all programs through the proxy. Browser extensions, app-specific proxy settings, and bypass lists can change the route. TUN is a separate way to route traffic. For troubleshooting, turn off TUN and establish a baseline with the system proxy first. To test TUN, enable it separately and repeat the test so results don’t get mixed together.
-
Check the listening port
Open Settings → Parameter Settings and check the local listening port and protocol. Some versions use port 10808 as a mixed port; older configurations may use 10809 for HTTP. The command below applies only to port 10808 when it actually provides an HTTP proxy. Don’t use it as-is with a SOCKS-only port.
-
Reset the system proxy
At the bottom of the main window, open System Proxy and choose “Automatically configure system proxy.” Then go to Windows Settings → Network & Internet → Proxy and check that the manual proxy address and port point to the current client. Make sure no other tool is repeatedly overwriting the setting.
-
Check which routing rule matches
Check the current Routing option at the bottom of the main window, along with the inbound connection, destination, and outbound tags in the core logs. Log details vary by log level. If traffic is routed directly, update the relevant rule or briefly switch to the global proxy mode available in your current configuration, then retest. Restore your original routing mode afterward.
-
Specify the proxy explicitly
Use the command below to specify the local HTTP proxy directly, eliminating whether the browser reads the system proxy as a variable. If the command works but the browser doesn’t, check browser extensions, its own proxy settings, and cache rather than immediately switching nodes.
netstat -ano | findstr ":10808"
curl.exe --proxy http://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://5v2ray.com/For netstat output, check the local address and listening state; seeing 10808 alone doesn’t prove the port is working. The curl.exe example is for a Windows terminal and tests a small page request, not bandwidth. The NO_PROXY environment variable may also bypass the proxy if it includes the destination domain, so check it first.
Log errors: restore the connection before testing speed
Connection failures and low throughput need to be handled separately. Keep the log panel open, reproduce the issue once, and inspect the full error sequence around that time. The examples below are common snippets; surrounding context and core version can affect the full message. Don’t reinstall the client based on a single word in the logs.
Error: connectex: No connection could be made because the target machine actively refused it.
Cause and fix: The destination port refused the connection. If the log points to 127.0.0.1:10808, first check that the core is running and that the listening protocol and port are correct. If it points to a remote node, verify the node address, port, and server status.
Error: context deadline exceeded
Cause and fix: The operation exceeded its deadline, which can happen during DNS resolution, connection setup, or the request itself. Check the destination in the surrounding log entries, then narrow down the cause by trying the same node on another network and another node on the same network. Don’t just increase the timeout.
Error: lookup …: no such host
Cause and fix: The ellipsis represents the actual domain in the log. DNS resolution didn’t return the required result. Check whether the failed lookup is for the node domain or destination domain, verify the spelling, and review the current DNS settings. If the node domain can’t be resolved, restore node address resolution before testing proxy access.
Error: tls: failed to verify certificate
Cause and fix: TLS certificate verification failed. Check the system date, time, and time zone, along with the server name and certificate settings required by the node. Don’t disable certificate verification as a way to improve speed or as a routine fix.
Changing DNS only affects the relevant resolution path; it can’t fix insufficient node bandwidth. Browser secure DNS, system DNS, and core DNS may also work independently. Change only one DNS source at a time, restart the relevant app, and retest. Don’t change system DNS, routing rules, and nodes all at once, or you won’t know what fixed the issue.
Common questions and when to stop troubleshooting
Latency is only 80 ms. Why are downloads still slow?
Low latency only means that a short request or connection completed quickly. On the same node, try two destinations that allow downloads and check sustained speed for about 30 seconds. If only one destination is slow, look first at its rate limits or the route from the exit to that site. There’s no need to change the local port right away.
It’s only slow at night. Which settings should I change?
Keep the node and destination fixed, and record three tests during the day and three in the evening. Then retest in the evening using a hotspot. If speeds improve noticeably, investigate the home broadband connection and cross-network route. If the same node is slow on different networks, share your test notes with the provider. Don’t start by changing concurrency or buffer settings.
TUN made it faster. Does that mean the system proxy is broken?
Not necessarily. The two modes may cover different apps, use different DNS paths, or match different routing rules. Compare an explicit proxy command with the browser first. Then check whether the browser uses the system proxy and whether both modes use the same node and outbound rules.
Should I use port 10808 on Android too?
Don’t copy desktop settings. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. On Android, keep the node fixed and retest on Wi-Fi and mobile data. Check the app’s VPN connection status, per-app settings, and logs. Configure a local proxy port manually only if you need to connect to one, and use the port shown by the app.
Once the difference between two access networks is consistently reproducible with the same node, destination, and time of day, there’s no need to keep changing local settings at random. If an explicit proxy and the browser produce the same result and the logs show no connection errors, but multiple download destinations remain slow, focus on the node and network route instead of reinstalling the client repeatedly.
- Local settings issue: Restore the original routing mode after fixing the setting, turn off temporary test modes, and verify your usual apps again.
- Node or network route issue: Share the client and core versions, test times, access network, comparison results, and relevant logs with sensitive information removed.
- Only one site is affected: Note the destination domain and where the request fails, then compare using another exit. Don’t change the entire subscription configuration yet.
- Sharing logs: Remove subscription links, credentials, and personal address information. Keep only the errors and timestamps needed to diagnose the issue.