“Connected” usually means the core is running or a proxy interface is up—not that the destination website is reachable. This guide uses v2rayN on Windows to check the node and system clock first, then isolate DNS, routing, and local listener issues. Android users can follow the same troubleshooting order. Change one setting at a time and retest the same URL to avoid mistaking a temporary fix for a correct configuration.
1. Tell a Running Core from a Successful Web Request
Keep your current configuration and note the selected node, proxy mode, test URL, and time of failure. Open the client logs, then reload the page once. New log entries reveal more about where the request went than a “Running” status in the system tray. Don’t update subscriptions, change DNS, and enable TUN all at once; even if access returns, you won’t know what fixed it.
v2rayN is a client for configuring and managing connections; the selected core handles the actual connection. V2Ray and Xray aren’t status-button names. On Android, v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Even after they establish a VPN interface, connections can still fail during node authentication, name resolution, or outbound connection.
| What you see | What it tells you | Next step |
|---|---|---|
| Core is running | The process has started; the request may still fail | Reload the page and check for new log entries |
| The node shows a latency value | A probe received a response | Try a real HTTPS request |
| Browser reports a proxy connection failure | The local proxy endpoint may be unreachable | Check the listening address and port |
| Only some websites won’t load | Could be a domain rule, DNS, or the destination site | Check the outbound record for the failing domain |
2. Check the Node: An Open Port Doesn’t Mean Authentication Succeeded
Turn off the proxy and visit a site that already works on your current network to confirm your computer has basic internet access. Then enable the proxy and test the current node and another known-working node using the same HTTPS URL. If only the second node works, investigate the first node’s configuration or server before reinstalling the client.
-
Confirm the active node
In the v2rayN main window, check which server is actually active. Selecting a row doesn’t necessarily make it the active server. Use the option to set the active server for your version, then check the logs again.
-
Check the connection settings
Open the server editor and compare the address, port, authentication details, transport, and TLS settings with the subscription source. For WebSocket, also check the path and Host. Don’t treat Host and the TLS serverName as the same field or swap them arbitrarily.
-
Compare with another node
Change only the node; leave routing, DNS, and proxy mode as they are. If all nodes fail, check the system time and local proxy setup next. If just one fails, update its subscription or contact the service provider.
-
Confirm core compatibility
If the configuration fails to load, check whether the current core supports the protocol and transport combination. VMess and VLESS may look similar, but their authentication and configuration fields aren’t interchangeable. Don’t manually change a node’s settings to use a different protocol.
A latency test may check only whether a TCP connection can be established; some tests send an HTTP request instead. It depends on the test you select. A reachable node port doesn’t rule out TLS handshake, user authentication, or server-side outbound failures. A successful subscription update only confirms that the configuration was downloaded—not that every node in it works.
3. Sync the System Clock, Then Check TLS and Authentication Logs
Correct the computer’s actual clock before troubleshooting certificate or authentication errors. In Windows 11, go to Settings → Time & language → Date & time, turn on Set time automatically, and select Sync now. Check the date, year, and time zone. Changing only the displayed time zone may not correct a system clock that’s out of sync. Restart the core after syncing, then try another request.
- VMess: Authentication includes time-based checks, so a large clock difference between the client and server can cause failures. The allowed difference depends on the implementation; don’t assume one fixed number of seconds applies to every node.
- TLS: An incorrect system date can make a certificate appear not yet valid or expired. If the error persists after correcting the clock, check serverName, the server certificate, and possible network interference.
- Other authentication: VLESS authentication doesn’t follow the same rules as VMess. However, if the connection also uses TLS, the system clock still needs to be correct.
Error: x509: certificate has expired or is not yet valid
Cause and fix: The local clock is incorrect, or the server certificate has an invalid validity period. Sync the system clock first. If the error persists, check the certificate dates in the logs and contact the service provider. Don’t disable certificate verification as a workaround.
Error: tls: handshake failure
Cause and fix: The remote side rejected the TLS handshake. Possible causes include serverName, protocol parameters, or server configuration. Restore the original settings from the subscription and investigate using server logs; this error alone doesn’t prove a DNS problem.
4. Check System DNS and Proxy-Core DNS Separately
First identify which hostname fails to resolve: the node server or the website you’re trying to visit. If the node hostname can’t resolve, the tunnel can’t be established. If the destination hostname fails, only some requests may be affected. On Windows, nslookup checks system-level resolution, but its results don’t tell you whether the core’s remote DNS or the browser’s encrypted DNS is working too.
nslookup example.com
curl.exe --connect-timeout 10 --max-time 20 --proxy socks5h://127.0.0.1:10808 -I https://example.com/These are diagnostic examples, not speed-test results. First confirm that 10808 is the actual SOCKS or mixed port currently listening, then run the second command. Replace the URL with the site that’s actually failing so the results are meaningful. socks5h sends the hostname to the proxy for resolution, while socks5 typically resolves it locally with curl. Different results indicate that you should investigate the resolution path further, but check the logs too.
- System DNS fails, but the proxy request works: Check system DNS, browser DNS settings, and whether the request is bypassing the proxy. Don’t assume the node is broken.
- System DNS works, but proxy-side resolution fails: Check the core’s DNS address, access path, and routing. If remote DNS also needs the proxy, make sure its connection doesn’t depend on a resolution step that hasn’t completed yet, creating a startup dependency loop.
- Only the node hostname fails to resolve: Check that the node address in the subscription is spelled correctly and that its DNS record is still valid. Don’t permanently replace the hostname with an IP from a one-time lookup; this can break certificate checks or load balancing.
Error: no such host
Cause and fix: The current resolution path couldn’t find a valid result for that hostname. Check which hostname appears in the error, then verify its spelling, DNS response, and resolution settings. This doesn’t mean all network connections are down.
5. Check Routing: Is the Request Going Out Through the Wrong Route?
Temporarily switch to global proxy routing for comparison, then restore your original split-tunneling setup. “Global” here refers to the routing policy; it doesn’t mean enabling the system proxy or TUN. An app must first send its request to the core for the core’s routing rules to take effect. Apps that aren’t intercepted by the system proxy won’t automatically use the proxy just because you changed the core’s routing.
Note your current routing profile in v2rayN, switch to the global proxy option available in your version, and test the same URL. If global routing works but split tunneling doesn’t, focus on domain rules, IP rules, and the default outbound. Menu names vary by version and core, so use the actual outbound records rather than relying on the profile name.
| Test result | Check first | What to do |
|---|---|---|
| Global works; split tunneling fails | Rule order, domain matching, and default outbound | Check which outbound handled the failed request, then narrow the scope of custom rules |
| Traffic is sent directly in split-tunnel mode | Overly broad direct-connection rules for domains or IPs | Fix the relevant rule, then test related subdomains |
| Destination is blocked | A blocking rule or rule set is matching incorrectly | Adjust only the rule that’s matching incorrectly; keep other valid rules |
| Both routing modes fail | Node, DNS, local listener, and app interception | Return to the failure logs instead of piling on routing exceptions |
Bottom line: Change split-tunnel rules only after a comparison test works
If neither global nor split-tunnel routing can complete the same HTTPS request, stop adding domain rules. Use an explicit proxy request to test the local endpoint and node, narrow down the failure, then restore split tunneling.
6. Check the Local Port and System Proxy Endpoint
Finally, check that the local port is actually listening and that the browser points to it. You can change v2rayN’s ports, and settings vary across older configurations and versions. The values below are examples only; replace them with the values currently shown in your client. Don’t enter the node’s server port in Windows’ local proxy settings.
Run the two commands below in Windows PowerShell. The first shows the listening port and process ID; the second checks whether an HTTPS request can pass through that proxy endpoint. If only a SOCKS port is listening, don’t enter it as a regular HTTP proxy in system settings. Check the current core configuration to see whether a mixed port supports both protocols.
Get-NetTCPConnection -State Listen -LocalPort 10808 |
Select-Object LocalAddress, LocalPort, OwningProcess
curl.exe --connect-timeout 10 --max-time 20 --proxy socks5h://127.0.0.1:10808 -I https://example.com/Error: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
Cause and fix: The listening address and port are already in use. Identify the process by its ID, close any duplicate client instance, or change the local port and update the app’s proxy settings. Don’t terminate system processes you don’t recognize.
Error: Failed to connect to 127.0.0.1 port 10808
Cause and fix: The request couldn’t connect to the specified local endpoint. Check that the core is running, the port matches, and the listening address includes the loopback interface; then investigate the remote node.
If the explicit proxy command works but the browser doesn’t, open Windows 11 Settings → Network & internet → Proxy and check the configured local HTTP or mixed endpoint. If you used v2rayN’s tray menu option System Proxy → Automatically configure system proxy, return to Windows settings and confirm the result. Menu wording varies by version. Browser proxy extensions may override system settings, so temporarily disable them while testing.
- Command-line tools don’t necessarily use the system proxy: Specify the endpoint with
--proxyto avoid interference from environment variables and system settings. - Test TUN separately: Turn off TUN and verify the explicit proxy first, then enable TUN and compare. If only TUN fails, check the virtual adapter, DNS interception, and routing conflicts instead of changing node authentication again.
- Don’t run multiple traffic-interception tools at once: Keep only the network tools you need while troubleshooting to avoid duplicate changes to system proxy, routing, or DNS. Ask your administrator about security policies on managed devices.
7. Common Questions and Checks After Restoring Access
Why won’t websites load even though the node shows a latency value?
A latency probe and a complete web request are different tests. Keep the same node, use a curl command with --proxy to request the URL that’s actually failing, and check the core logs for that time. An HTTP status code means the server returned an HTTP response, but codes such as 403 or 405 still need to be assessed against the destination site’s rules.
My phone works with the same subscription, but my PC doesn’t. Should I reinstall?
First confirm that both devices are using the same node, then test them on the same network. The same subscription doesn’t guarantee the same active node, core capabilities, or DNS settings. On the PC, check the local listener and an explicit proxy request first. Save the logs before considering rebuilding the configuration.
Android says the VPN is connected, but none of my apps can load anything. What should I check?
In v2rayNG or v2flyNG, confirm the active node, then check whether per-app proxy settings exclude your browser. Temporarily disable per-app filtering for comparison and review the core error logs. The VPN icon only indicates that the interface is up; it doesn’t confirm successful remote authentication or DNS requests.
What should I do if regular websites stop working after I close the client?
Reopen v2rayN, clear the system proxy from the tray menu’s System Proxy option, then exit. You can also open Windows Settings → Network & internet → Proxy and turn off any manual proxy or setup script you added while troubleshooting. Don’t change settings managed by your organization. If you used TUN, make sure the client has stopped intercepting traffic cleanly.
After access is restored, revert temporary global proxy settings, debug logging, and test DNS settings one at a time to your intended configuration. Test after each change. A short record of “symptom → change → retest result” is more useful than a collection of unexplained exceptions.
- Test at least one site that failed before and one site you use every day; don’t assume a fix for one domain solves everything.
- Restart the client and test again to confirm the changes were saved and the system proxy still points to the right endpoint.
- When reporting the issue, include the client and core versions, time of failure, and redacted logs. Remove subscription links, UUIDs, passwords, and other authentication details.