“Connected” usually means only that the local service or VPN interface is running. It doesn’t confirm that web requests are reaching their destination through the node. First check whether traffic reaches the client, then verify the listening port, DNS resolution, and outbound route. Finally, check the node settings and system time. Change one thing at a time and retest the same address to avoid piling multiple issues together.
First, distinguish connection status from access
v2rayN is a desktop client; V2Ray and Xray are traffic-processing cores. v2rayNG is an Android client that uses the Xray core. A running status, a VPN key icon, or a latency reading for a node doesn’t prove that your browser can access websites. A port connectivity check, a real request, and a download speed test each verify different parts of the connection.
Close the client first and check whether the device can access websites that normally work. Public Wi-Fi may require you to sign in before you can connect; changing nodes won’t help if the underlying network is down. Note which sites fail, when the problem started, what type of network you’re using, and whether all apps fail or just the browser.
- All apps fail: Start with the underlying network, proxy entry point, core startup, and node connection.
- Only one browser fails: Check the browser’s own proxy settings, extensions, and secure DNS before rebuilding the entire configuration.
- Only some domains fail: Check DNS, routing rules, restrictions on the destination site, and IPv4/IPv6 reachability.
- It fails only after switching Wi-Fi networks: Compare with mobile data and check for network sign-in requirements, DNS changes, and whether the node’s port is reachable.
Step 1: Check whether the system proxy is handling traffic
On Windows, launching v2rayN doesn’t necessarily set the system proxy automatically. The system proxy is used by apps that honor that setting; it doesn’t route all traffic. Terminal apps may use environment variables, browsers may have their own proxy settings, and games may ignore the system proxy entirely. TUN mode uses a different traffic-capture path. For troubleshooting, don’t switch between multiple modes at once.
-
Confirm the active node
In the v2rayN node list, select the node you want to use, right-click it, and choose “Set as active server.” Selecting a row alone may not switch the active node. Check the active server shown in the main window too.
-
Set the system proxy
Right-click the v2rayN icon in the taskbar notification area and select “System Proxy” → “Automatically configure system proxy.” The menu location may vary between desktop versions; use the option with the same name in your version.
-
Check the system proxy entry
In Windows, open “Settings” → “Network & internet” → “Proxy” and check the proxy server address and port. Make sure they match the client’s current listening settings. If you use a setup script, check its status separately rather than treating the two modes as interchangeable.
-
Rule out a separate proxy
Temporarily disable browser proxy extensions, then close and reopen the browser. If a command with an explicit proxy works but the browser doesn’t, investigate the browser’s settings before switching nodes.
Step 2: Check whether the local port is listening
The proxy address should point to a listening port on your own device, not the remote node’s server port. The numbers below are examples for troubleshooting, not recommended values to apply universally. In v2rayN, check the local listener settings under “Settings” → “Parameter Settings.” Option names and groups vary by version, so check the startup log as well. Older configurations may use separate SOCKS and HTTP ports; newer ones may use a mixed port.
In Windows PowerShell, run the commands below to check the local listener, then send an HTTPS request explicitly through SOCKS. If your port is different, replace 10808 in the command. This uses curl.exe to avoid PowerShell environments where curl resolves to a different command.
Get-NetTCPConnection -State Listen -LocalPort 10808 |
Select-Object LocalAddress, LocalPort, OwningProcess
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/If no listener appears, check whether the core failed to start. If a listener is present, confirm which process owns it so you can rule out a port conflict. socks5h sends the destination domain to the proxy to resolve, so it doesn’t confirm that local DNS is working. An HTTP status code means an HTTP endpoint responded; check the status, certificate, and logs to confirm whether it was the intended site.
How to read the results: fix the entry point before checking the remote end
If an explicit proxy request succeeds but the browser fails, fix browser or system proxy handling first. If you can’t connect to the local port, fix the listener. Comparing nodes is useful only once you’ve confirmed that the request reaches the core.
Step 3: Tell the two types of DNS resolution apart
At least two kinds of addresses need to be resolved: the node’s server hostname and the destination domain your browser is visiting. If the node hostname can’t be resolved, the core may never connect to the node. If the destination domain fails to resolve, node tests may succeed while specific websites remain unavailable. Browser secure DNS, system DNS, and core DNS don’t necessarily follow the same path.
| What to check | What to do | How to interpret the result |
|---|---|---|
| Local resolution of the destination domain | Run Resolve-DnsName example.com | A result only confirms that this system lookup returned an answer; it doesn’t prove that the node connection works. |
| Proxy-side resolution of the destination domain | Compare requests using socks5:// and socks5h:// | The first resolves the destination domain locally; the second sends it to the proxy to resolve. A difference can point to an issue with the DNS path. |
| Node hostname resolution | Look in the logs for the server hostname and lookup errors | Check the node address, bootstrap resolution, and DNS on the current network—not just the browser cache. |
| Cached results | After correcting DNS settings, run ipconfig /flushdns | Flush the Windows cache and try again. The browser and core may still have their own caches. |
Don’t replace the node hostname with an IP address you found online. With TLS or REALITY, the server address, SNI, and target name have to match the configuration. Changing the IP blindly can turn a DNS issue into a handshake failure. Keep the original node settings and compare them against the parameters provided by the server.
curl.exe --proxy socks5://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/Step 4: Check whether routing selects the right outbound
The system proxy determines whether a request enters the client; routing rules determine which outbound handles it. “Global proxy” is a common application-level term, but its meaning can vary between clients. When documenting your tests, note the routing mode, rules, and outbound tag actually in use.
In v2rayN’s routing selector, temporarily choose a rule mode that sends the test destination through the proxy outbound, then revisit the same address. If it works, check custom domain rules, direct rules, and blocking rules. Restore the original mode after testing; there’s no need to send all local traffic through a remote node permanently.
- Check rule order: Cores commonly match rules in order. A broad rule near the top may match first, preventing more specific rules below it from running.
- Check the tags:
outboundTaginrouting.rulesmust reference an existing outboundtag, with an exact name match. - Distinguish direct from proxied traffic: If the logs show a request going direct, that only confirms the rule selected a direct connection. It doesn’t mean the proxy node is unavailable.
- Check rule data files: If configuration uses region or domain data files and they fail to load, fix the files and their configuration references first. Switching nodes alone won’t solve the problem.
Step 5: Check the node based on the error
Once the entry point, DNS, and routing are confirmed, check the node address, remote port, user ID, transport, and security settings. A successful subscription update only means the configuration was downloaded; it doesn’t mean every node in it is online. Test another node from the same subscription, then try the original node on a different network. This quickly helps distinguish a node issue from a network restriction.
Error: connection refused
Cause and fix: The other end refused the TCP connection. First check whether the address in the error is local or remote. For a local address, check the listener; for a remote address, check the node’s port and whether its service is running.
Error: i/o timeout
Cause and fix: A network read or write operation took longer than the allowed wait time. Check the target address and stage in the logs, then compare with another node and network. Don’t assume it’s a DNS issue.
Error: no such host
Cause and fix: A hostname couldn’t be resolved. First identify whether it’s the node hostname or destination domain, then check the spelling, resolver reachability, and bootstrap DNS settings.
Error: tls: handshake failure
Cause and fix: The TLS handshake was terminated, and there can be several reasons. Check the port, SNI, transport settings, and server configuration. Keep the complete logs from around the same time before drawing conclusions.
VLESS, VMess, and Trojan settings aren’t interchangeable. For VLESS with REALITY, check the public key, short ID, server name, and flow control required by the server. When using XTLS Vision, flow must match the server configuration. The protocol name alone doesn’t tell you whether the current core or node configuration will work.
- Keep the original node for now. After updating the subscription, compare any changes to its settings; don’t delete nodes in bulk without a backup.
- Record the results for node A and node B against the same destination so you don’t mistake an issue with the destination site for a node failure.
- When checking logs, keep the context before and after the error. Before sharing logs, redact subscription URLs, user IDs, sensitive credentials, and personal network information.
Step 6: Check the time and Android traffic capture
TLS certificate validity checks rely on system time, and VMess authentication also involves time. If your computer or phone has the wrong date, you may see authentication or certificate errors even when the network and port are fine. On Windows, go to “Settings” → “Time & language” → “Date & time,” turn on automatic time, and select “Sync now.” On Android, search system settings for “Date & time,” enable automatic time, and check that the date is correct.
A different time zone display doesn’t necessarily mean the actual time is wrong. Check the date and current time instead of changing the time zone to hide a clock discrepancy. Don’t work around the issue by disabling certificate verification; that can mask problems with the time, server name, or certificate chain.
- Confirm VPN permission: When starting v2rayNG, grant the system VPN permission. If another VPN service is running, stop it before testing.
- Confirm the operating mode: Local proxy mode alone doesn’t capture traffic as a VPN. To let regular apps use the proxy, check whether VPN mode is enabled.
- Check which apps are included: In v2rayNG “Settings,” review per-app proxy options and make sure the browser isn’t excluded. The list may work in reverse when a bypass option is enabled.
- Check background restrictions: If it works while the screen is on but fails after the device has been locked for a while, check v2rayNG’s battery and background activity permissions in system app settings, then test again with the screen locked.
- Test each network separately: Test Wi-Fi and mobile data separately. After switching networks, stop and restart the connection if needed to check whether the old connection simply failed to recover.
Common questions and troubleshooting notes
Why won’t websites load when latency is only a few dozen milliseconds?
First, check what kind of test produced that result. A TCP latency test checks only part of the connection; even a successful request test confirms only that its specific target worked at that moment. Use the explicit proxy command in this guide to access the same site, then check the browser and routing paths.
Why does the same node work on my phone but not my computer?
First, connect both devices to the same network and compare the active node settings. On the computer, start with the system proxy and local listener. If a command request works but the browser fails, check browser extensions and separate proxy settings.
Should I reinstall the client if just one website won’t open?
Try another node on the same website, then check which routing rule matches the domain and compare DNS results. A normal HTTP error response may also point to the destination site’s access policy rather than a damaged client installation.
It works again for a while after restarting. What should I check next?
Note when it fails again and check for a connection with sleep, a network switch, or a background service stopping. When the failure happens, check the listening port and core logs before restarting so you don’t lose the most useful evidence.
After a troubleshooting session, a reproducible record is more useful than repeated reinstalls. Don’t change DNS, routing, the core, and the node all at once. Change one thing at a time, use the same test destination and wait time, and record the results before and after each change.
- Environment: Client and core versions, operating system version, and Wi-Fi or mobile data.
- Entry point: System proxy or VPN mode, local listening address and port, and whether per-app settings are enabled.
- Results: Whether the explicit proxy command returned a response, whether the browser worked again, and whether another node worked.
- Evidence: When the error occurred, relevant logs, the outbound actually selected, and the results of each individual comparison.
Client access and basic setup
To verify where to get the client, visit the downloads page and choose your platform. To redo the import and proxy setup, follow the guide to establish a basic connection before restoring custom routing.