For users who have imported a config and can connect, but experience slow page loads, stalled downloads, or background disconnects. Keep the test conditions consistent, compare nodes and networks, then check the proxy entry point, routing, and DNS. Change one setting at a time and use logs and repeat requests to narrow down the cause. A node's listed latency doesn't tell you its sustained throughput.
1. Tell Connection Delays, Slow Transfers, and Background Disconnects Apart
“Slow” is too vague to diagnose on its own. A long wait when first opening a page may point to DNS resolution or connection setup. If the page loads but downloads keep stalling, check for network congestion or limited server egress. If the connection drops only after your phone locks, start with background restrictions. Classify the symptoms first instead of blaming every issue on the node.
Before testing, pause other downloads and cloud sync. Use the same device, destination, and network each time. Choose a destination you can access and that is normally reliable; one site's temporary issue doesn't tell you whether the whole route is slow. Note the client version, core, node name, and time of the issue. Updating the client or core also changes a variable, so don't do it alongside routing changes.
| Symptom | Check first | How to compare |
|---|---|---|
| First page load is slow; later loads are normal | DNS, handshake, destination response | Compare the first request with repeat requests |
| Pages load, but transfers keep stalling | Node egress, access network, device load | Retest after switching nodes on the same network |
| Only one app is slow | App proxy entry point, per-app rules | Compare the app's logs with the browser's |
| Disconnects when the screen locks; resumes when it wakes | Battery settings, background network access | Compare while keeping the app in the foreground |
The TCP latency shown in a node list usually measures only how long it takes to connect to a port. “Real connection latency” also depends on the test destination selected by the client. Neither figure directly reflects sustained transfer performance. A timeout may mean the test destination is unavailable; low latency doesn't prove the node's egress is uncongested.
2. Node: Compare Availability and Server Status
On the same network, compare node A with node B, ideally using configs with different server addresses or egress routes. Different names don't guarantee different routes; several nodes in a subscription may share an entry point. Don't run a batch of speed tests in parallel and draw conclusions right away—concurrent tests compete for bandwidth and connection resources.
- Check that your subscription is active. In v2rayN, update the relevant group under “Subscription Groups.” Check for update failures, expiration, or exhausted traffic. Select a node from the refreshed list instead of testing an old entry that may have been replaced.
- Verify the node settings. Check the address, port, authentication details, TLS, server name, and transport settings against the provider's configuration. VMess and VLESS are protocol types, not speed tiers. You can't reuse one config just by changing its protocol name.
- Check server metrics. If you manage the server, review CPU, memory, egress bandwidth, connection count, and service logs. If the provider manages it, send them the time of the issue and redacted error details, and ask about limits or egress problems.
- Retest at different times. If the same config slows down only at certain times, the node may be under load or an upstream route may be congested. Repeat the test under the same conditions before changing anything; reinstalling the client is unlikely to help.
Takeaway: Narrow it down to the node before changing local settings
If node A consistently has problems while node B works on the same device and network, check A's config and server status first. This result alone can't distinguish server load from a network route issue between you and that server.
v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Support for specific transports and security options depends on the core version. If importing a config produces an unsupported-field error or the core won't start, check compatibility first; increasing connection concurrency won't fix it.
3. Network Route: Keep the Node, Switch Networks
After comparing nodes, keep node A selected and compare your home network with another available network. When switching between Wi-Fi and mobile data, make sure the client reconnects before visiting the same destination. On a computer, you can also compare using a phone hotspot, but watch your data usage.
- Problems occur on just one Wi-Fi network: Move closer to the access point or try a wired connection. Rule out weak Wi-Fi, router load, and traffic from other devices before blaming the upstream route.
- The same node works on another network: Suspect the route between the access network and the node first; don't assume the server is faulty.
- The same destination is slow on different networks: Check the destination's status, regional egress differences, and which routing rule matched.
- Only UDP-based traffic has problems: Check the app's entry point, core config, and whether the access network supports that traffic. A working web page doesn't mean every type of traffic is working.
The transport settings must match the server. For example, if the server uses WebSocket, the path and Host must be correct. If TLS is enabled, the server name and certificate validation must also meet the config requirements. Incorrect transport settings often cause handshake failures or retries, which can look like a long wait.
Regular ping traffic is different from the traffic used by a proxy connection. A server that doesn't respond to ping may still accept proxy connections; a successful ping doesn't prove that an app request will work. Evaluate the route using real requests and core logs, not a single latency result.
4. Local Settings: Check the Proxy Entry Point and Routing Rules
In v2rayN, “System Proxy” and “Routing” do different jobs. The system proxy tells apps that follow system settings which local entry point to use. Routing determines whether requests received by the core go through the proxy, connect directly, or get blocked. Enabling the system proxy doesn't mean every app will use it—or that every destination will go through the proxy.
- Check the listening port. In “Settings” → “Parameter Settings,” check the local listener options or review the startup log. The example below uses
127.0.0.1:10808as an HTTP proxy. Use the port and entry point configured on your system. - Check the system proxy. In the main window, open “System Proxy” and select “Set system proxy automatically.” For comparison, make a request that explicitly targets the local entry point, so a separate proxy setting in a browser extension doesn't interfere.
- Check the routing result. Review the current routing mode and custom rules, especially earlier-matching domain, IP, and app rules. Temporarily use a rule that explicitly sends the destination through the proxy, then restore your original mode.
- Check other entry points. If TUN is enabled, note its status, then test the regular local proxy entry point separately. Don't let multiple proxy apps manage the system proxy or virtual network interface at the same time.
Run the request below in Windows Terminal to rule out whether an app is ignoring the system proxy. example.com is a public example domain; this request checks whether the connection completes, not its bandwidth. If your entry point supports SOCKS only, use the appropriate SOCKS options instead of copying the HTTP proxy command.
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 30 --head https://example.com
netstat -ano | findstr ":10808"The first command allows up to 10 seconds to connect and 30 seconds total. A timeout is just the result of this test, not direct evidence of server load. The second command checks connections related to the port; look for the corresponding listening entry and its PID. If the explicit proxy request works but the browser doesn't, check its proxy extensions, outdated auto-configuration scripts, and network settings first.
5. DNS and Android Per-App Settings: Check Whether Requests Reach the Core
DNS problems often show up as a long wait on the first visit or failures for some domains. Distinguish between resolving the server address before connecting to the node and resolving the destination website. A failure in the first can prevent the node connection; a failure in the second may affect only certain destinations. They don't necessarily use the same DNS route.
- Check which domain is failing. Determine whether the failed lookup is for the node address or the destination site. Remove private domains, subscription URLs, and authentication details before sharing logs.
- Check that DNS and routing work together. In v2rayN, open the DNS settings under “Settings”; the menu name may vary by version. Check whether the DNS server is reachable and whether its traffic should connect directly or go through the proxy.
- Check for app-specific DNS. A browser's Secure DNS, an app's built-in resolver, and system DNS may use different routes. Change one setting at a time, then restart the affected app and test again.
- Don't copy an unfamiliar config blindly. If remote DNS depends on the proxy, but resolving the node address also depends on that DNS, a misconfiguration can prevent startup. Make sure the node address can be resolved initially.
On Android, also check that the app you're testing is included in the VPN tunnel. In v2rayNG, open “Settings” → “Per-app proxy” and check the feature toggle, selected apps, and “Bypass mode.” With per-app proxy enabled and bypass mode off, selected apps use the proxy; with bypass mode on, they bypass it. Stop and reconnect after changing the settings, then test the same app again.
If the issue occurs only after the screen locks, go to the battery or background management settings under system “Settings” → “Apps” → “v2rayNG” and allow background activity. The exact labels vary by device. Also check that VPN permission is still active and another VPN connection hasn't replaced it. Check system VPN and background permissions for v2flyNG too, but don't assume its in-app menus are identical to v2rayNG's.
Takeaway: If app requests don't reach the core, check the entry point first
After enabling a sufficient connection log level, if a test request still doesn't appear in the logs, check the system proxy, VPN, and per-app settings first. Switching remote nodes won't fix an app bypassing the proxy.
6. Read the Error Logs to Find Where the Request Fails
Keep the log entries from just before and after a request in the client log panel. Look for the innermost error and its destination address. The same error text can occur at different stages: a refused connection to the local proxy and one to the remote server require completely different fixes. Here are some common error snippets; full logs usually include timestamps, protocol details, and addresses.
Error: connection refused
Cause and fix: The destination actively refused the connection or has no service listening. First check whether the address is local or remote. For a local address, check that the core started and the port is available; for a remote address, verify the node port and service status.
Error: i/o timeout
Cause and fix: A network read or write exceeded its timeout. Check the surrounding log entries to see whether it occurred during DNS resolution, connection setup, or the response. Retest with the same node on another network; don't assume the node is down based on this message alone.
Error: address already in use
Cause and fix: The address and port can't be bound because another process is using them. Find the process with a port lookup, close the duplicate instance or change the listening port, then update the system proxy and app entry point to match.
Error: x509: certificate has expired or is not yet valid
Cause and fix: Certificate validity checks failed, possibly because the device clock is wrong. Sync the system date and time zone first. If the error persists, check the server certificate; don't disable verification as a routine fix.
If needed, briefly increase the log detail, reproduce the issue, then restore your usual level to avoid recording too much browsing activity. When contacting your provider, include the client and core versions, time of the issue, network type, node comparison results, and redacted errors. That's more useful than simply reporting “slow speeds.”
7. Common Questions and a Final Troubleshooting Checklist
The node has low latency. Why does the page keep loading?
A latency test doesn't measure a complete page request. First use an explicit local proxy request to check the connection, then verify that the browser uses the same entry point and the destination domain is routed to the expected outbound. Finally, compare with another website.
Switching to global proxy fixed it. Should I leave it on?
Treat that as a routing comparison, not necessarily a permanent fix. Restore the original mode, check the direct-connection rule for the domain, IP rules, and rule order, then adjust the specific rule that matched incorrectly. Global proxy isn't a universal fix for DNS or network route problems.
My computer works, but my phone is slow. Is the node incompatible with my phone?
First, connect both devices to the same Wi-Fi network and use the same node config. Then check the phone's VPN permission, per-app proxy settings, and battery restrictions. Check core version and config compatibility only if you see an unsupported-field or handshake error.
I changed DNS, ports, and routing, and now it won't connect. What should I do?
Use your change history to revert settings one at a time, starting with the last config that started successfully. Make sure the listening port matches the proxy entry point, then restore the original routing and DNS. Reconnect and test after each change instead of piling on more adjustments.
- Record the symptoms and test conditions, then confirm the client core starts normally.
- Compare two nodes on the same network, then compare two networks with the same node.
- Check the system proxy or VPN entry point, and confirm the test app reaches the core.
- Check routing, DNS, and transport settings, then use the logs to pinpoint the failure.
- Keep changes that work and revert tests that don't. Submit relevant troubleshooting details only when evidence points to the server or network route.