Goal: pinpoint whether the connection failure lies with the local listener, traffic entry point, node configuration, time and handshake, or remote network. This guide focuses on v2rayN on Windows, with notes on differences in v2rayNG and v2flyNG on Android. Change one variable at a time and retest with the same request, so you can tell what fixed the issue instead of changing nodes, routes, and DNS all at once.
Step 1: Confirm the local proxy port is listening
Local entry point: an open client window does not mean the proxy core has started. v2rayN manages the configuration, while the selected core handles the connection. If the core fails to load its configuration or the port is already in use, your browser cannot send requests through the node just by setting a proxy address. Check the startup result in the client log, then verify the listening port.
Check the port: In v2rayN, go to “Settings” → “Parameter Settings” and check the local listen address, port, and inbound type. Section names may vary by version. The example below uses a SOCKS inbound at 127.0.0.1:10808. Port 10808 is not fixed across installations, nor is it the server port; replace it with the actual listening port before running the command.
netstat -ano | findstr ":10808"- No output: Check whether the actual port is different, the core has exited, or the log shows a configuration parsing or startup error. Don’t try to fix a listener that isn’t running by changing your browser settings.
- LISTENING appears: Note the PID at the end of the line, then check “Task Manager” → “Details” to identify the process. Another program may be using the port; matching numbers alone don’t mean the listener is working correctly.
- Different listen address:
127.0.0.1is the IPv4 loopback address. A listener on[::1]alone does not guarantee that IPv4 loopback connections will work; test using an address that matches the listener.
Error: bind: address already in use
Cause: The local address and port are already in use, commonly because the client was started twice or another proxy process is still running.
Fix: Identify the process using the port by its PID. Close duplicate instances or change the local listen port, then restart the core and update the app’s proxy settings to match.
Android differences: v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. First confirm that the app has started a connection and received system VPN permission. Android VPN routing and the Windows system proxy are different entry points, so Windows port-check results do not directly apply.
Step 2: Separate system proxy, app proxy, and TUN
Traffic flow: The system proxy affects only apps that follow that setting, while TUN routes traffic through a virtual network adapter. If a browser works but other apps fail, the node may not be at fault. Conversely, a successful latency test in the client does not mean the browser is using the proxy.
Isolate the test: Note the current system proxy and TUN settings, temporarily disable TUN, then send a request with a command that explicitly specifies the SOCKS proxy. This removes uncertainty about whether the app follows the system proxy, but client-side routing rules can still affect the result. To verify proxy egress, also check the log for the actual outbound route.
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://v2raymark.com/What the parameters mean: socks5h sends the destination hostname to the proxy for resolution, so it does not prove that local DNS is working. The 10-second limit applies to the connection phase; 20 seconds is the limit for the entire request. These are diagnostic settings for this test, not network performance benchmarks. Even a 403 or 405 response means an HTTP response was received, so the issue should no longer be classified as a connection timeout.
-
Record the setup
Note v2rayN’s listening port, selected node, system proxy status, and TUN status. Keep the original conditions on hand if the test fails.
-
Run an explicit test
With TUN disabled, run the command above. If the local connection is refused, return to Step 1 and check the port and SOCKS inbound type.
-
Restore the system proxy
After the explicit proxy test succeeds, select “Automatically configure system proxy” under “System Proxy” in v2rayN. Then check that the client status matches Windows “Settings” → “Network & Internet” → “Proxy.”
-
Test TUN separately
Enable TUN only if needed, and confirm the permissions and network adapter status as prompted by the client. If only TUN fails, focus on routing, DNS, and conflicts with other VPNs instead of changing node settings right away.
Result: Explicit proxy works? Check the app’s entry point
If the explicit proxy request works but the browser still fails, check browser extensions, app-specific proxy settings, and the system proxy address. Changing the server won’t fix a local entry point that isn’t taking effect.
Step 3: Check subscription settings and the node in use
Configuration source: A successful subscription update only confirms that the configuration was fetched and parsed; it does not guarantee that every node works. A failed update does not mean existing nodes have stopped working. First check which subscription group the selected node belongs to and whether it is an outdated entry. Then confirm whether the provider has changed the address, port, or authentication details.
Core compatibility: In v2rayN, check which core is actually being used and review its logs. On Android, v2rayNG and v2flyNG are not the same app under different names. Xray and v2fly do not support exactly the same protocol extensions and fields. Importing a configuration into the app does not guarantee that the core can run it fully. Check compatibility carefully for configurations using VLESS, REALITY, and similar features.
| Check | What to verify | Common misdiagnosis |
|---|---|---|
| Server address and port | Check the node address and server listening port; 443 is only a common example | Using local port 10808 as the remote port |
| Protocol and authentication | VMess or VLESS type and the corresponding user ID and other fields | Assuming authentication is current because the node name matches |
| Transport settings | Check the actual transport—TCP, WebSocket, gRPC, or another type—and its required fields | Changing only DNS despite a transport mismatch |
| TLS settings | Check whether TLS is enabled, the server name, and certificate requirements | Assuming an open TCP port means the handshake is configured correctly |
| Outbound routing | Confirm that the test request uses the intended proxy, not a direct or blocked route | Treating a failed direct connection to the destination website as a node timeout |
Update the subscription: In v2rayN, open “Subscription Group” and update the relevant group. Then select the node again and check the logs. If your version offers separate options to update through or without the proxy, choose based on whether the subscription URL is reachable. If your only node has stopped working, relying on it to download the subscription can create a failure loop. Subscription URLs and complete node configurations are sensitive; hide authentication fields in troubleshooting screenshots.
Step 4: Sync the system clock and identify TLS handshake errors
Why time matters: A significantly incorrect system clock can make a certificate appear not yet valid or expired, and may affect time-based VMess authentication. VLESS does not use the same time-validation rules as VMess, but TLS connections are still subject to certificate validity checks. Changing the displayed time zone does not correct the system clock itself.
- Windows: Go to “Settings” → “Time & language” → “Date & time,” turn on “Set time automatically,” click “Sync now,” and confirm the result.
- Android: Search system settings for “Date & time” and turn on automatic time. The exact menu path depends on the device.
- After syncing: Retry the same request and check the core log from that time. If certificate errors persist, check the certificate’s validity period and server name.
Error: x509: certificate has expired or is not yet valid
Cause: The certificate validity period does not match the current system time. The local clock may be wrong, or the server certificate may genuinely need renewal.
Fix: Sync the local clock first. If the error persists with the correct time, the server administrator should check the certificate and its deployment.
Error: x509: certificate signed by unknown authority
Cause: The certificate chain does not lead to a trusted root. Possible causes include a missing intermediate certificate, a private certificate, or the local trust store.
Fix: Check the server’s certificate chain and expected issuer. Configure trust for private certificates through a trusted channel; don’t bypass validation as a substitute for fixing the problem.
Check SNI: The connection address and TLS server name can differ, but both must match the server setup and certificate requirements. Don’t enter an arbitrary reachable domain. Don’t use allowInsecure as a timeout fix: skipping certificate validation will not resolve a TCP connection failure or incorrect transport path, and it weakens authentication.
Step 5: Check server reachability and remote listeners
Test the remote endpoint: After confirming the local entry point, traffic routing, and configuration in the first four steps, test the node address and destination port. The following PowerShell commands are for Windows; enter the actual node address and port, not the full subscription URL. This test checks TCP connectivity only—it cannot verify credentials, TLS, the WebSocket path, or the gRPC service name.
$nodeHost = Read-Host "Enter the node server address"
$nodePort = [int](Read-Host "Enter the node server port")
Test-NetConnection -ComputerName $nodeHost -Port $nodePort -InformationLevel Detailed- TcpTestSucceeded is True: The address and port used by this test accepted a TCP connection. Next, check TLS, authentication, transport settings, and server logs; this alone does not mean the node is fully operational.
- TcpTestSucceeded is False: Possible causes include address resolution, a service that is not listening, a firewall, a security group, or packet loss along the route. Check the resolved remote address and error details; this result alone does not prove that the service is down.
- Ping fails but TCP succeeds: The target may not respond to ICMP. Don’t use a failed Ping as a substitute for testing the proxy port, or a successful Ping as proof that the proxy service is working.
- For UDP: A TCP probe says nothing about UDP availability, and a successful web request does not prove that every UDP-dependent app will work.
Error: i/o timeout
Cause: A network read or write did not finish before its deadline. Check nearby log entries to determine whether the timeout occurred while connecting to the node, during the TLS handshake, or while accessing the destination service.
Fix: Keep the log entries around the same request and compare the remote address and stage where it failed. Check the port, handshake, or destination service as appropriate; don’t change DNS based on this line alone.
Compare networks: Keep the node, destination address, and test command unchanged, switch the local network to a phone hotspot, and run the test again. If the result changes, focus first on restrictions at the original network’s egress, DNS responses, and address-family differences. This still does not prove a specific cause. If the domain has both IPv4 and IPv6 addresses, record which address was actually used rather than comparing only the domain name.
Working with the server administrator: If you have admin access, check that the process is running, the expected port is listening, the firewall and security group allow traffic, and the certificate and reverse proxy settings match. If you don’t have access, give the administrator the failure time and time zone, protocol and transport type, redacted logs, and port test results. Don’t share user IDs, subscription URLs, or other authentication details.
Result: If the port is reachable, move on to the handshake and configuration
If the TCP probe succeeds but proxy requests keep failing, focus the next round of troubleshooting on TLS, protocol authentication, transport settings, and the actual outbound route in the logs. Increasing the wait time repeatedly usually just delays the same error.
Retest: Confirm the fix with the same request
Retest criteria: After making one change, run the explicit proxy request from Step 2 again, then test the browser or app you actually use. Success with an explicit proxy covers only that request path; it does not replace separate checks for the system proxy, TUN, DNS, or other apps. The client’s latency test has its own target and method, so it cannot establish that all apps are working.
- Record the changes: Note what you changed, the test time, selected node, and relevant logs so you don’t have to start from scratch next time.
- Restore settings: Restore TUN and the system proxy as needed, and undo temporary changes. Don’t leave workarounds such as disabled certificate verification in place.
- Narrow it down: If only one website fails, check its route and response status. If only one app fails, check its app-specific proxy settings and traffic type.
- Keep the evidence: Before-and-after tests should use the same destination, entry point, and timeout settings. Don’t present one successful test as proof of long-term reliability.
Next steps: For more on how the system proxy, TUN, and routing rules work together, see Advanced Setup. If you haven’t completed the initial configuration, start with the guide to establish a repeatable connection, then add routing and DNS settings gradually.