For cases where v2rayN is running or v2rayNG shows an active connection, but websites won't load. First identify whether the issue is with the core, app traffic routing, or node availability. Then use the local port, an explicit proxy request, and logs to narrow it down. Change one thing at a time and keep notes on failures so you can tell what made a difference.
1. Connected status: Find out where the request stops
A core-started message in v2rayN or a running status in v2rayNG only confirms that the process or local VPN service has started. It doesn't mean the browser's request reached the proxy, let alone that the remote server completed a protocol handshake. Also check what a node's latency test actually measures: a TCP connectivity test checks only the port, not whether the proxy works end to end.
Pause downloads and background sync, then choose one node, one browser, and one fixed test URL. On desktop, use a standard local proxy only for now; don't mix TUN mode and the system proxy in the same test. On Android, first confirm VPN mode is enabled and that the browser isn't excluded by per-app rules.
- All apps fail: Check the core, local listener, and node connection first.
- Only the browser fails: Check system proxy settings, the browser's own proxy settings, and extensions.
- Only some domains fail: Check DNS, routing rules, and IPv6 connectivity first.
- Only one node fails: Save its logs, then compare against a known-working node.
2. System time and basic connectivity: Rule out problems outside the proxy
Disable the proxy first and confirm that your local network can reach sites that normally work without it. If not, check for a Wi-Fi sign-in page, gateway issues, network permissions, or an outage from your ISP. A proxy client can't fix a broken underlying connection. On public Wi-Fi, the node may keep timing out until you complete the network's sign-in process.
Check the date, time, and time zone. TLS certificate validation depends on the correct time, and VMess authentication is also sensitive to clock skew. Don't assume that a displayed time zone mismatch is the problem: what matters is whether the device's actual time is correct, not just which time zone the interface shows.
- Windows: Open Settings → Time & language → Date & time, turn on Set time automatically, then select Sync now.
- Linux: Run
timedatectl statusand check the current time andSystem clock synchronized. If the clock isn't synchronized, fix the time service for your distribution. - Android: Search Settings for Date & time and turn on automatic date and time. Menu names and locations vary by device.
- Compare networks: Switch your phone between Wi-Fi and mobile data. If the same node fails on only one network, check that network's connection restrictions or DNS settings.
3. Local port: Confirm the core is listening
Having the v2rayN window open doesn't mean a local proxy listener is active. Go to Settings → Parameter settings and check the listen address, port, and inbound type; labels may differ between desktop versions. The examples below use 127.0.0.1:10808; replace this with the value shown in your settings. Older configurations may use separate SOCKS and HTTP ports, while newer ones may use a mixed inbound.
Run the appropriate command in Windows PowerShell or a Linux terminal. These commands check for a TCP listener, not a node address. Listening on the loopback address is usually enough for local use; there's no need to expose the port on every network interface just to troubleshoot.
# Windows PowerShell: Check which process is listening on TCP port 10808
Get-NetTCPConnection -LocalPort 10808 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
# Linux: Check the same port and its process
ss -lntp 'sport = :10808'| Result | What it means | Next step |
|---|---|---|
| No listener found | The port is incorrect or the core didn't start successfully | Verify the settings and check the startup logs |
| Another program owns the listener | The local port is in use | Stop the conflicting process or choose an unused port |
| The core is listening normally | The local inbound is ready | Continue with an explicit proxy request |
After changing the port, update the system proxy, browser-specific settings, and terminal environment variables too. If you change the client from 10808 to 10818 but an app still uses the old port, the core can run normally while pages continue to fail. Don't disable the firewall just because a port is in use; first check whether the process using it is another running instance of the core.
4. System proxy: Separate inbound issues from node issues with an explicit request
On desktop, choose System proxy → Automatically configure system proxy in v2rayN, then check the proxy address actually set in the operating system. On Windows, go to Settings → Network & internet → Proxy. The HTTP proxy field needs an HTTP or mixed inbound; a SOCKS-only port won't work as an HTTP proxy.
The system proxy doesn't transparently route traffic from every app. Some command-line tools, games, and browser extensions use their own proxy settings or ignore system settings altogether. To bypass those differences, use curl to connect directly to the local SOCKS inbound. The test domain below is only for checking the request path; interpret the status code along with the response body.
# Windows: Use curl.exe to avoid the old PowerShell alias with the same name
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
# Linux: Send the same request through the local SOCKS inbound
curl --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/socks5h sends the target domain to the SOCKS proxy for resolution; whether the core handles DNS or forwards it to the remote end depends on your configuration. The 10-second connection timeout and 20-second total timeout are diagnostic settings, not performance guarantees. If you only have an HTTP inbound, change the proxy argument to --proxy http://127.0.0.1:10808 and use the actual HTTP port.
What it means: If the explicit proxy test works, fix the app's proxy settings first
If curl gets a valid HTTP response but the browser still fails, check the browser's proxy extensions, system proxy address, and bypass list. Don't change nodes or rewrite DNS yet. Some servers don't accept HEAD requests and return 405; that alone doesn't mean the proxy connection failed.
- Connection to the local port is refused: Go back to the previous section and check the listener address and inbound type.
- The local port accepts connections, but the request times out: Check node handshake and outbound logs from the same time.
- The page responds, but only one site fails: Compare the routing outbound, the site's restrictions, and DNS results.
5. v2rayNG: Check VPN permissions and per-app proxy rules
Troubleshooting on Android differs from desktop system proxy checks. v2rayNG's VPN mode uses Android's VPN service to route app traffic, but a running status doesn't mean every app is included. Start the service from the main screen, confirm that Android granted VPN permission, and check whether another VPN service is using the connection.
- Check the operating mode: Open v2rayNG Settings and confirm that VPN mode is selected. Proxy-only mode won't automatically route traffic from every app.
- Check which apps are covered: Find per-app proxy settings under Settings and make sure the browser isn't excluded. In allow-list mode, the browser must be selected; in exclusion mode, the reverse applies.
- Check the system VPN: Search system settings for VPN, confirm that v2rayNG is the active service, and make sure options such as Always-on VPN and Block connections without VPN match your expectations.
- Check background restrictions: If the connection drops when the screen locks, allow background activity in the app's battery settings and test again with the screen locked. The permission labels vary by device.
A successful node connectivity test doesn't prove that per-app routing is configured correctly. The test may be initiated by the client itself while the browser remains excluded. v2rayNG uses the Xray core; if another device uses v2flyNG with the V2Fly core, check protocol support and node settings separately. The same subscription name doesn't guarantee identical runtime configurations.
6. Core logs: Diagnose the actual error, not just a vague message
Clear the old logs, make one failed request, then check the core logs in v2rayN or the logs page in v2rayNG. Note the timestamp, connection stage, and surrounding error context. Error formats can vary between core versions, so the snippets below are common examples, not guaranteed full log lines for every failure.
Error: address already in use
Cause: Another process is using the listening address and port, so the core can't bind to them.
Fix: Use a port-checking command to identify the process, stop the duplicate instance or choose an unused port, and update the app's proxy settings to match.
Error: connection refused
Cause: The connection target explicitly rejected the request. It could be the local inbound or the remote node.
Fix: Check the address in the log. If it's local, check the listener; if it's remote, verify the node's port and service status.
Error: i/o timeout
Cause: A connection or read/write operation didn't complete in time. The issue may be with the network path, server, or handshake stage.
Fix: Compare another network and a known-working node. Keep logs from before and after the failure to distinguish a connection timeout from a read timeout after the connection was established.
Error: x509: certificate has expired or is not yet valid
Cause: Certificate validity checks failed, possibly because the device clock is wrong or the server certificate has a problem.
Fix: Sync the system clock first, then check the server certificate. Don't treat skipping certificate validation as a permanent fix.
Error: no such host
Cause: The hostname couldn't be resolved. Check whether the failing name belongs to the node or the website you're visiting.
Fix: Check the spelling and the DNS resolution path in use. If the node's hostname won't resolve, fix DNS before the proxy connection can be established.
If the logs show a connection to the node followed by a handshake failure, check whether the subscription has expired, the authentication details match, and the transport type, path, and TLS server name are correct. For VLESS nodes using REALITY, also verify the public key, short ID, and flow settings. Don't swap VMess, VLESS, or transport settings at random; use the complete configuration provided by the server.
7. DNS and routing: Fix cases where only some sites won't load
Check DNS and routing only after the local inbound works and at least one proxy request succeeds. On Windows, nslookup example.com; on Linux, getent ahosts example.com can show how the system resolves a name, but neither proves that the core's built-in DNS is working. The browser may also use secure DNS, creating a third resolution path.
Compare how the same domain behaves with system DNS and an explicit proxy request. When changing DNS, note the original setting and change only one thing at a time. Keep in mind that the server hostname must resolve before the node connection can be established; relying on DNS that is only reachable through that same node can create a startup dependency loop.
| Symptom | Check first | How to compare |
|---|---|---|
| System DNS fails, but the proxy request works | System DNS or the browser's resolution path | Check whether the app sends the domain through the proxy |
| Global proxy works, but routing mode fails | Direct-connection rules, rule-set data, and rule order | Check the outbound tag for the request in the logs |
| Fails when the domain has an AAAA record | IPv6 connectivity and outbound support | Check the actual connection address and try an IPv4-only comparison |
| Browser fails, but other apps work | Browser secure DNS and browser-specific proxy settings | Disable relevant extensions temporarily and test the same URL again |
As a temporary test, select Global proxy from the client's Routing menu, test the same URL, then restore the original setting. Global proxy only changes the outbound route for traffic that has already reached the core; it won't make an app that ignores the system proxy start using it. If global mode works but routing mode doesn't, check whether a broad direct-connection rule is matching first. V2Ray/Xray routing rules are evaluated in order, so an earlier match can affect what happens next.
8. Retest and FAQs: Keep a concise troubleshooting record
After making a fix, retest in the same order: basic connectivity, local listener, explicit proxy request, browser, and the site that originally failed. When one change produces a consistent result, it's easier to identify the cause. Subscription updates and node connections are separate: a failed update doesn't necessarily break existing nodes, and a working node doesn't mean the subscription URL is currently reachable.
Why does the node show latency if websites still won't load?
First check whether the latency test only checks TCP connectivity. Then send an explicit proxy request and review the handshake logs. A reachable port can still have mismatched authentication, TLS, or transport settings.
Why can't my browser connect after I exit v2rayN?
Reopen the client, select System proxy → Clear system proxy, then check whether the system proxy address still points to a local port. If your computer is managed by an organization, verify its original proxy settings first.
v2rayNG says it's running, but the browser can't connect. Why?
Open Settings and check whether the browser is included or excluded under per-app proxy settings. Then close and reopen the browser, and confirm that another VPN service isn't handling the connection.
Should I reinstall if changing DNS didn't help?
Restore the original DNS settings first, then check whether the request reaches the core and which stage fails in the logs. Save your configuration and version details before reinstalling; reinstalling usually won't fix a local listener, system proxy, or server configuration issue.
- Record your environment: Operating system, client version, core version, and network type.
- Record the proxy setup: System proxy or VPN mode, local port, and per-app settings.
- Record comparisons: Whether the same request works with another node or on another network.
- Record the logs: Keep relevant lines from before and after the failure. Remove subscription URLs, authentication details, and personal network information before sharing.
For basic setup, see the quick start guide. To investigate DNS and routing, see the DNS settings in the user guide. Identify which layer is failing before changing settings; this is more likely to produce a repeatable result than repeatedly importing subscriptions or changing several options at once.