Use this guide for node test timeouts, websites that won’t load in your browser, or lost connectivity after enabling TUN. Start with one node and one URL, then check the local proxy, routing results, and logs before reviewing server settings. Change one variable at a time so you can identify the cause.
1. Identify Where the Timeout Occurs
A “node timeout” means a test didn’t finish within the allotted time; it doesn’t necessarily mean the server is offline. The request may stall at the local listening port, while resolving the node address, during the transport handshake, or when the proxy tries to reach the test URL. v2rayN manages desktop configurations, but the selected core handles connections. An open client window doesn’t mean the core started successfully.
Record the time, client version, core name and version, node alias, proxy mode, and test URL. Check the version shown under “Help” or in the main window; use the startup log for the core version, not the client version. Treat these three scenarios separately.
- All nodes fail: Check your local network, listening port, system proxy, TUN, and security software first. A shared service outage affecting the subscription is also possible.
- Only one node fails: Compare its address, port, and transport settings, and check whether the server has disabled that entry point.
- The test fails, but websites still load: Check the test URL and where its traffic is routed. Don’t delete a node based on a single latency reading.
2. Restore Direct Connectivity and Set Up One Test Path
On Windows, turn off “Enable TUN” in the v2rayN main window, then choose “Clear system proxy” under “System proxy.” The menu location can vary by version; make sure you disable traffic interception, not just close the window. Then open a website that normally works without a proxy and check whether the Wi-Fi network requires a sign-in page.
-
Check local connectivity
In Windows Settings, go to “Network & internet” and confirm that you’re connected. If direct websites won’t load either, troubleshoot the gateway, captive portal, or network first. Don’t change node settings yet.
-
Check the system clock
Go to Settings → “Time & language” → “Date & time,” turn on automatic time setting, and click “Sync now.” An incorrect clock can interfere with certificate validation and protocols that check timestamps.
-
Check the listening port
In v2rayN, go to “Settings” → “Parameter settings” and check the local listener settings. Use the core startup log to confirm the actual port and protocol. Don’t enter the node’s remote port in your browser’s proxy settings.
-
Keep test conditions consistent
Select one node as the active server and leave TUN off. Enable only the system proxy, or explicitly specify the local proxy in a command. Use one URL, make a single request, then check the logs for that time.
The numbers below are for illustration only, not default values for every version. Assume you’ve confirmed that the local HTTP or mixed listener is on 127.0.0.1:10808 and the destination uses HTTPS. In practice, use the port in your current configuration.
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 15 --head https://example.com/This example uses Windows commands; on macOS and Linux, use curl instead. If the listener supports SOCKS only, change the proxy address to socks5h://127.0.0.1:10808 and verify the port. An HTTP response means the request reached an HTTP service, but you still need the status code and logs to interpret the result. If it times out, continue tracing the connection path.
3. Test the System Proxy and TUN Separately
The system proxy mainly affects apps that honor the system proxy settings; it doesn’t automatically capture traffic from every process. TUN routes matching traffic through a virtual network interface and involves routing tables, permissions, and DNS interception. Enabling both during troubleshooting can cause loops or overlapping traffic capture, making it harder to tell which layer failed.
| Symptom | Check first | Next step |
|---|---|---|
| Explicit proxy request works, but the browser fails | System proxy and browser-specific proxy settings | In Windows Settings, go to “Network & internet” → “Proxy” and verify the address and port |
| System proxy works, but TUN doesn’t | Elevated permissions, virtual interface, routing conflicts | Check permission prompts and startup logs. Close other traffic-capture apps and test again. |
| Stops working after the computer wakes from sleep | Interface recovery, stale connections, DNS state | Stop traffic capture, wait for the network to recover, then restart the core and reconnect. |
| Android disconnects only in the background | VPN permission, battery optimization, per-app routing | Check v2rayNG’s VPN status, its battery settings, and whether the target app is excluded. |
v2rayNG uses Android VpnService with the Xray core; v2flyNG uses the v2fly core. Check that the configuration is compatible with the core in use. Another VPN service can take over Android’s VPN connection, so the app still appearing in the notification shade doesn’t prove it’s active. Test before and after locking the screen rather than immediately switching node protocols.
Bottom line: verify the local proxy first
If an explicitly specified local proxy works but regular apps fail, fix the app’s proxy settings or traffic-capture scope first. Don’t start by changing the remote UUID, TLS, or transport settings.
4. Check That Routing Sends Requests to the Expected Exit
Routing rules generally match in order, but the conditions and default outbound depend on the core configuration. Selecting a node doesn’t mean every request will use it. Domain, IP, and process rules, as well as direct and blocked outbounds, can change the route. Check the version-specific behavior and logs to see which outbound handles a connection-latency test.
- Temporarily simplify routing: In v2rayN, open “Routing” and choose a preset for global proxying. Preset names vary by configuration; make sure no direct or block rule matches the test URL first.
- Check what actually happened: Look in the logs for the destination domain, port, and outbound tag. Confirm that the expected proxy outbound appears before drawing conclusions about the node connection.
- Distinguish the two DNS lookups: The node server’s domain must resolve first; the destination website may also need to be resolved through the proxy. The fixes differ depending on which lookup fails.
- Check routing resources: If the logs report a missing rule resource, fix the resource loading first. Don’t mistake a resource-loading failure for an unreachable remote port.
Don’t replace a node’s domain with an old IP just to “rule out DNS.” Services using domain-based entry points may rotate addresses, and TLS may still require the original server name even when you connect by IP. A safer approach is to check the DNS result and the provider’s published entry point, then run a reversible comparison if needed.
5. Use Core Logs to Locate the Connection Failure
Save the client log entries surrounding one failed request. If the current log level doesn’t show the connection process, look for the log-level setting under “Settings” → “Parameter settings,” temporarily enable more detail, restart the core, and reproduce the issue once. Restore the usual log level afterward to avoid generating excessive logs. Error snippets may be surrounded by additional context; keep the destination address and operation type before and after the error when diagnosing it.
dial tcp: lookup ...: no such host
Cause: The current resolver couldn’t find the host. The address may be misspelled, its DNS record may be invalid, or the resolution path may be failing.
Fix: First determine whether the host in the log is the node endpoint or the destination website, then check the relevant domain settings and DNS. Don’t change both resolution paths at once.
connect: connection refused
Cause: The connection was refused, commonly because nothing is listening on the port or a device actively rejected it. The error alone doesn’t prove the rejection came from the final server.
Fix: If the address is 127.0.0.1, check the local core and port first. For a remote address, verify the node port and whether the server is listening.
i/o timeout
Cause: A network operation exceeded its time limit. This can happen during dialing, reading or writing, or the handshake; the message alone doesn’t prove a protocol incompatibility.
Fix: Check the preceding operation and destination address, then test the same node over another network to distinguish a network-path issue from a server-side issue.
x509: certificate has expired or is not yet valid
Cause: The certificate validity period doesn’t match the local time. The system clock may be wrong, or the remote certificate may have expired.
Fix: Sync the system clock first. If the time is correct, ask the service provider to check the certificate. Don’t bypass certificate verification as a substitute for fixing the issue.
6. Verify Node Settings and Server Listeners
Once you’ve ruled out the local proxy, routing, and network, check the node settings. VMess and VLESS are different protocols; changing only the protocol name won’t make an old configuration work. The transport, TLS, and security settings must match the server, and a configuration that imports successfully may still use features unsupported by the selected core.
| Setting group | Fields to check | Common misconception |
|---|---|---|
| Endpoint and credentials | Server address, remote port, UUID, or protocol-specific credentials | Assuming an open TCP port means authentication will succeed |
| TLS and server name | Whether TLS is enabled, server name, certificate validity | Assuming the connection address and TLS server name are always the same |
| Transport layer | WebSocket path and Host, gRPC service name, and similar settings | Checking only the UUID and overlooking reverse proxy forwarding settings |
| Protocol-specific security settings | For REALITY, check the public key, server name, and shortId; if using flow, verify its value | Expecting the client to guess or fill in server settings arbitrarily |
In Windows PowerShell, use Test-NetConnection to check the node’s TCP port. Set -ComputerName to the node’s actual address and -Port to its actual port. This only tests whether a TCP connection can be established; it doesn’t validate VMess, VLESS, TLS, or access to the destination. It also can’t tell you whether a UDP-based transport works.
- Subscription users: Update the subscription group from a trusted source and compare the address, port, and transport settings. After importing, make sure you haven’t selected an older node by mistake.
- Server administrators: Check that the service is running and its configuration loads, the target port is listening, and both the host firewall and cloud inbound rules allow traffic.
- Using a reverse proxy: Check the certificate, DNS resolution, and forwarding target. An open public port doesn’t guarantee that the backend service is available.
- Request reached the server: Check server-side outbound DNS, routing, and the connection to the destination. The server may complete the handshake but still fail to reach the requested website.
7. Cross-Test and Keep Reproducible Notes
Finish with a few controlled comparisons: try another network on the same device, another device on the same network, and another node in the same client. Change only one condition at a time. If another network works, investigate the original network path, but don’t assume the ISP is to blame; device differences, DNS, and traffic-capture settings may also change when you switch networks.
- The same node fails on two networks, but other nodes work: Note the time, node alias, and error snippet, then ask the provider to check the endpoint and server status.
- Only one device fails on the same network: Recheck that device’s listening port, routing, system proxy, TUN permissions, and security software logs.
- Only one website fails: Check the site’s availability, routing result, destination DNS, and server-side access. Don’t rebuild the entire client configuration as a first step.
- After connectivity is restored: Reset the temporary log level, remove test rules, then restore your usual routing and traffic-capture settings one at a time. Confirm the problem doesn’t return.
Bottom line: Report the failing step, not just “it won’t connect”
A useful report includes the time, client and core versions, traffic-capture mode, test destination, exact error, and cross-test results. Identifying whether the request stopped at the local proxy, remote handshake, or destination is far more useful than repeatedly refreshing latency tests or changing settings at random.