For when v2rayN is running and a node is selected, but your browser still times out. First test the local proxy and node connection with an explicit proxy request, then check the system proxy, DNS, routing rules, and TLS time requirements. On Android, also check VPN permissions and per-app routing. Change one setting at a time and record each result so you can pinpoint the cause.
1. Distinguish “running” from “working”
A running icon or kernel log output usually means only that the local process has started. A successful latency test doesn't guarantee that a website is reachable: a TCP probe, an actual HTTP request, and a browser visit test different parts of the connection. V2Ray/Xray is the core; v2rayN is the configuration and management interface. Your browser must also send requests to the correct local proxy.
Note the current node, routing mode, system proxy status, and local listening port. Then test a familiar HTTPS page that normally works. The three port numbers below illustrate their respective roles; they aren't default values for every version. Use the actual ports under Settings → Parameter Settings and the listening address shown in the startup log.
- All websites fail: Check the local listener, system proxy, and node connection first.
- Only some domains fail: Check which routing rule matches, DNS results, and the target website's status.
- Browser works, but one app doesn't: Check whether the app follows the system proxy before changing protocols.
- Internet still doesn't work after closing the client: Check whether a manual proxy pointing to a local port is still enabled.
2. Pinpoint the failing layer with an explicit proxy request
Specifying a proxy explicitly eliminates uncertainty about whether your browser is using the system proxy. Run these commands in Windows PowerShell. Using curl.exe avoids conflicts with a command alias of the same name. The example requests https://example.com/; you can substitute a page you know is reachable. The 10-second limit is for connection setup, while 20 seconds is the total request timeout—not a speed measurement.
# First, check whether the example ports used in this guide are listening
Get-NetTCPConnection -State Listen -LocalPort 10808,10809 -ErrorAction SilentlyContinue
# Run only if 10808 is confirmed as a SOCKS or mixed port
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -v -o NUL https://example.com/
# Run only if 10809 is confirmed as an HTTP or mixed port
curl.exe --proxy http://127.0.0.1:10809 --connect-timeout 10 --max-time 20 -v -o NUL https://example.com/If your version uses a single mixed port, change both commands to the actual port. Don't enable an extra listener just to match the example. socks5h sends the destination domain to the proxy for handling, but the core may still resolve it according to routing rules. Check the logs to interpret either result.
| Test result | What it means | Next step |
|---|---|---|
| Local connection refused immediately | The local listener isn't running, or the port is incorrect | Check the core startup log and whether another process is using the port |
| Proxy request receives an HTTP response from the destination | The request made it through the proxy | Check the browser and system proxy settings |
| Request fails after CONNECT 200 | Only the HTTP proxy tunnel was established | Check the TLS handshake and subsequent response |
| Local proxy connection succeeds, then times out | The issue may be the node, DNS resolution, or outbound routing | Compare with the core log entries from the same time |
Bottom line: If the explicit request works, check the proxy settings first
If the same destination returns a page through an explicit proxy but fails in your browser, fix the system proxy or the browser's separate proxy settings first. Switching between VMess, VLESS, or transport types is usually not the right first step.
3. Match the system proxy to the local listening port
The Windows system proxy serves apps that honor that setting; it doesn't automatically handle all traffic. Browser extensions, app-specific proxy settings, and terminal environment variables can override it. For troubleshooting, close other apps that change proxy settings and temporarily disable TUN so only one traffic-routing method is active. If you rely on another VPN to reach a private network, save your work and check what may be affected first.
-
Check the listener
In v2rayN, open Settings → Parameter Settings and check the local listening ports. Depending on the version, they may be labeled SOCKS, HTTP, or mixed. Restart the core after making changes and confirm the log shows no startup errors.
-
Set the proxy
In v2rayN's main window, open the System Proxy menu and choose “Set system proxy automatically.” “Clear system proxy” does not route browser traffic through the proxy.
-
Check Windows settings
Open Windows Settings → Network & Internet → Proxy → Manual proxy setup. The address should usually be
127.0.0.1, and the port should match an HTTP or mixed listener—not a SOCKS-only listener. -
Check for overrides
Temporarily disable browser proxy extensions. If your browser has separate network settings, set it to use the system proxy. Close and reopen the browser, test the page again, and compare the result with the explicit proxy command.
If an app supports SOCKS5, enter the actual SOCKS port in that app. Don't enter the node server address and remote port in Windows manual proxy settings; those settings need the local listener, not server details from your subscription. netsh winhttp show proxy displays the WinHTTP proxy and can't, on its own, confirm that your browser's system proxy is correct.
4. Check system DNS and core DNS separately
DNS problems generally fall into two categories: the node server's domain can't be resolved, or the destination website's domain can't be resolved. The first prevents the core from connecting to the node; the second may affect only certain websites. Browser secure DNS, Windows DNS, and core DNS may use different paths, so a successful nslookup doesn't prove that DNS resolution through the proxy is working.
# Check how the system resolver responds for the test domain
nslookup example.com
# Windows: clear the system cache after changing system DNS
ipconfig /flushdns
# Compare with the socks5h test above: this command resolves the destination domain locally first
curl.exe --proxy socks5://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -v -o NUL https://example.com/- Local resolution fails, but letting the proxy resolve the domain works: Check your system DNS settings and network connectivity first. Don't reset the node.
- Log says the node domain couldn't be resolved: Check the node address for extra spaces, then check whether the DNS resolver used for the node needs a proxy connection that hasn't been established yet. Avoid creating a startup dependency loop.
- Only the browser fails: Temporarily turn off the browser's custom secure DNS and test again using the system resolver. Decide whether to restore it after testing.
- No change after adjusting settings: Clear the system cache, then restart the browser and core. Clearing the system cache does not clear the browser's or core's own cache.
5. Check whether routing rules send requests the wrong way
In v2rayN, System Proxy determines how an app connects to the local proxy; Routing determines which outbound route the core uses after receiving a request. They're separate settings. Even when your browser is using the local port, a direct or block rule may still match the destination domain.
Note the current routing profile. In the main window's Routing menu, temporarily select a test profile that sends the destination through the proxy. Profile names vary by version, so inspect the rules instead of relying on the word “Global.” Keep any necessary local network rules, then restore the original profile after testing.
| Symptom | What to check | How to verify |
|---|---|---|
| Works after switching to a test routing profile | Domain rules, IP rules, and rule order | Restore the original profile and disable suspicious custom rules one at a time |
| Log shows direct | Check whether a direct rule matches the destination | Confirm the log entry belongs to the current test request |
| Log shows block | Ad-blocking or custom blocking rules | Adjust the rule only for the domain that was incorrectly blocked |
| Still times out through the proxy | Node connection, server status, and protocol settings | Keep routing unchanged and compare with a known-working node |
If the log level isn't detailed enough, temporarily increase it and reproduce the issue once, then restore it when you're done. Before sharing logs, redact subscription URLs, UUIDs, tokens, and sensitive server details. VMess and VLESS authentication details, transport type, TLS server name, and required REALITY parameters must match the server configuration. Randomly switching protocols won't fix the problem.
6. Use the exact error to check ports, time, and TLS
When an error occurs, note the time and save the surrounding log lines. The examples below are common system or network error messages; actual logs may include the destination address and additional context. Don't assume it's DNS based only on the final word “failed.”
Error: Address already in use
Cause: The local address or port you're trying to bind is already in use. Fix: Identify the process using it, close any duplicate client instances, or change the listening port and update the system proxy to match. Don't terminate an unfamiliar system process.
Error: Connection refused
Cause: The destination port refused the connection. This can happen at the local listener or the remote server. Fix: Check the address in the error. If it's 127.0.0.1, check the listener; if it's the node address, check the remote port and server status.
Error: no such host
Cause: A domain couldn't be resolved. Fix: Check whether the domain in the error is the node or the destination website, then troubleshoot node address resolution or core DNS resolution separately. Don't replace all DNS settings at once.
Error: x509: certificate has expired or is not yet valid
Cause: The system clock is incorrect, or the server certificate is genuinely outside its validity period. Fix: Sync the system clock first. If the error persists with the correct time, ask your service provider to fix the certificate. Don't disable certificate validation.
In Windows, go to Settings → Time & language → Date & time, turn on Set time automatically, and select Sync now. Check the date, year, and time zone as well. A displayed time zone error doesn't necessarily mean the system clock itself is wrong, but setting the time manually can introduce an actual clock offset. Accurate time is essential for TLS certificate checks and time-based authentication.
- Certificate name mismatch: Check that the TLS server name matches the server's requirements. Don't change it to the node IP without a reason.
- One node keeps timing out: Check whether the subscription has expired, the data allowance is exhausted, or the server is unavailable.
- All nodes fail at once: Check the local listener, basic network connectivity, and firewall rules. Don't change node settings in bulk.
7. Android and other common cases
v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. On Android, the VPN icon in the notification bar only confirms that the VPN service is running; it doesn't prove that every app's traffic is routed through it. First confirm VPN permission, then check the client's per-app routing list. Settings names may vary by device manufacturer.
v2rayNG shows a VPN icon, but the browser still can't connect?
In v2rayNG, open Settings → Per-app proxy and check whether the browser is excluded. Confirm whether the list is set to proxy selected apps or bypass selected apps. Note the original setting, temporarily turn off per-app proxy, reconnect, and test the same page.
Browser works on your PC, but terminal commands don't use the proxy?
Terminal tools don't always use the Windows system proxy. First run the explicit curl.exe --proxy test from this guide, then check the tool's own proxy settings and whether the HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY environment variables still point to an old port.
Internet stops working only after enabling TUN?
Turn off TUN first and return to a baseline test using the local listener and system proxy. If that works, check the virtual network adapter, DNS interception, and routing conflicts with other VPNs. Don't enable multiple traffic-routing methods at once to test them together.
Regular websites stop working after you exit v2rayN?
Restart the client, choose Clear system proxy from the System Proxy menu, then exit. If the client won't start, go to Windows Settings → Network & Internet → Proxy and turn off any leftover manual proxy. If your organization manages the proxy, contact your administrator first.
On Android, also check Settings → Network & Internet → VPN for another connection that may be routing traffic. “Always-on VPN” or “Block connections without VPN” may prevent access even after the VPN disconnects. If the issue occurs only after the screen turns off, check battery optimization; that's different from pages failing immediately at startup.
- Retest the same page that failed originally so differences between websites don't make it look as though a setting fixed the issue.
- Restore any temporary changes to the log level, test routing profile, and browser DNS settings.
- If the issue persists, gather the client and OS versions, actual port numbers, explicit proxy test results, and redacted logs before asking for support.