Use this checklist when v2rayN has started the core and shows node latency, but websites still won’t load. First check whether the browser is sending requests to the local proxy, then look at routing, DNS, system time and the remote node. Testing with an explicit proxy and comparing results for the same destination helps pinpoint whether the problem is with the local connection or the outbound route—without changing several settings at once.
1. Core Started Doesn’t Mean Websites Are Reachable
v2rayN manages configurations and starts the proxy core. A “core started” status usually means only that the local process launched successfully; latency shown in the node list means only that a particular test returned a result at that time. Browser traffic still has to pass through the local listener, routing rules and node connection before the destination website responds. A failure at any step can leave a page loading indefinitely.
The examples below use Windows desktop. Settings may be grouped differently across versions, so check Help → About for your version, then look for the setting names mentioned here. The examples use 127.0.0.1:10808, but this isn’t a fixed port for every version. Older configurations may use a separate HTTP port, such as 10809. Check the local listener settings under Settings → Parameter Settings and the startup log for the actual values.
| What you see | What it confirms | What to check next |
|---|---|---|
| Core started successfully | The process started and loaded its configuration | Listening port, system proxy and outbound connection |
| A TCP latency value | The server port was reachable during the test | Protocol handshake, authentication, TLS and website response |
| A real connection test succeeded | The specified test request completed | Browser proxy settings, other websites and routing rules |
| The browser reports a proxy error | The browser tried to use a proxy but couldn’t connect | Actual proxy address, port and process status |
For troubleshooting, keep the node, test website and network unchanged, and note the error before and after each change. Don’t enable TUN, change DNS, switch cores and update subscriptions all at once. Even if access returns, you won’t know which change fixed it.
2. System Proxy: Make Sure Browser Requests Reach the Client
The system proxy determines how an app sends traffic to v2rayN; routing determines where that traffic goes next. Selecting a node doesn’t automatically route traffic from every app through it. Some apps follow the Windows system proxy, while others need their own proxy settings. To narrow things down, temporarily turn off TUN and test the standard system-proxy path, then restore your original settings.
-
Enable the system proxy
From the main window or tray menu, select System Proxy → Automatically Configure System Proxy. Avoid PAC mode for now, since site rules can complicate testing the proxy entry point.
-
Check the Windows proxy settings
Go to Windows Settings → Network & Internet → Proxy → Manual proxy setup. Check the address and port entered by the client, and make sure they match the local HTTP or mixed listener.
-
Check for browser overrides
Temporarily disable browser extensions that change proxy settings. If the browser has separate proxy settings, switch it to use the system proxy. Restart the browser and revisit the test site.
-
Test with an explicit proxy
Run the command below in PowerShell. It specifies the HTTP proxy directly, so the test doesn’t depend on whether the browser reads the system settings. If your local port only supports SOCKS, use the SOCKS test later in this guide.
curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/example.com is a sample test destination; replace it with the site that won’t load. --noproxy "" clears any proxy-bypass list for this invocation. An HTTP status code means an HTTP response was received, but doesn’t guarantee that every site resource will load. If the proxy returns an error page, check its contents along with the core log.
If the explicit proxy works, fix the browser’s proxy settings first
If a command-line request through the proxy gets a response from the same destination, but the browser still fails with the same node, check the system proxy, browser-specific proxy settings and extensions first. Don’t switch nodes or rewrite DNS yet.
3. Local Port: Check the Listener and Proxy Type
A local connection refusal usually means traffic hasn’t reached the remote server. Common causes include a stopped core, an incorrect port or another process using the port. On Windows, check which ports are listening and identify the process before taking action. Don’t terminate a process just because you found its ID.
Get-NetTCPConnection -State Listen -LocalPort 10808 |
Select-Object LocalAddress, LocalPort, OwningProcess
# Replace with the OwningProcess ID from the previous command
Get-Process -Id 12341234 is only an example process ID. Use the value returned by the previous command. If there’s no listener, check the v2rayN log for the startup failure. If another program is using the port, exit it normally if possible, or change the local listener port under Settings → Parameter Settings, then reapply the system proxy.
Error: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
Cause: Another process is already using the same listening address and port on Windows, so the core can’t bind to it.
Fix: Find the process using the port and close the duplicate client instance, or change the listener port and update the system proxy to match.
Error: ERR_PROXY_CONNECTION_FAILED
Cause: The browser can’t connect to the configured proxy, possibly because nothing is listening on that port or the proxy address is outdated.
Fix: Check the address and port in Windows proxy settings, then test with an explicit proxy command. Fix the local connection first; there’s no need to switch protocols yet.
4. Routing Presets: Check Where Requests Go
Once the local proxy is working, check where requests are routed. Routing rules are generally matched in order, and the first matching rule determines the outbound route. Custom rules might send a domain directly or route it through a blocked outbound. If switching to a bypass-style preset makes only some sites fail, check the rules rather than assuming the node is at fault.
- Save the current settings: Note the selected preset under Routing at the bottom of the window and whether custom rules are enabled, so you can restore them later.
- Run a temporary comparison: If the client offers a global proxy preset, select it temporarily, wait for the configuration to take effect, then test the same destination again. This changes routing, not the system proxy setting.
- Check the connection log: Confirm the test request reached the core and look for the visible destination and outbound tag. Tags are defined by the configuration, so they aren’t necessarily named
proxyordirect. - Narrow down the rules: If global proxy works but the original preset doesn’t, restore the original preset and check the destination domain, IP rules and any referenced rule-data files one by one.
Don’t assume that the word “global” means every connection is being routed through the proxy. It usually applies only to requests that reach the core; apps that don’t use the system proxy may still connect directly. Domain and IP rules can also behave differently depending on core settings such as domainStrategy. Keep the default strategy while troubleshooting rather than changing routing behavior across the board to fix one site.
5. DNS: Separate Local, Core and Node Address Resolution
DNS problems aren’t limited to website domains failing to resolve. If the node server is identified by a domain name, that name must resolve before the connection can start. Browser Secure DNS, the system resolver and the core’s DNS settings may all use different paths. Clearing the Windows cache affects relevant local cache entries only; it won’t clear every result cached by the browser or proxy server.
# Check the system resolver; this does not test the core's DNS
Resolve-DnsName example.com
# Use SOCKS to resolve the destination domain through the proxy
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
# Compare: resolve the destination locally, then connect through SOCKS
curl.exe --noproxy "" --proxy socks5://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
# Clear the Windows DNS cache if needed after changing related settings
ipconfig /flushdnsBoth SOCKS commands above require a SOCKS port. socks5h sends the destination domain to the proxy for resolution; socks5 resolves it locally first. If the first works but the second fails, investigate local DNS resolution. However, the domain and IP may match different routing rules, so compare the logs too—one test result alone isn’t conclusive.
Error: Could not resolve host
Cause: The resolver used by curl couldn’t find an address for the destination. This error alone doesn’t mean the node protocol is at fault.
Fix: Check system DNS resolution, then compare the two SOCKS tests to determine whether resolution is failing locally or on the proxy side.
Error: no such host
Cause: The domain shown in the log couldn’t be resolved. It could be the node server’s domain or the destination website’s domain.
Fix: Check the full domain near the error in the log, then verify the node address and the DNS configuration actually in use. Don’t replace the domain with an IP from a one-off lookup.
If only the browser fails, look for Secure DNS in its settings, note the current value, then temporarily turn it off for comparison. If the node domain won’t resolve, fix the underlying DNS path needed to establish the proxy connection first. Otherwise, resolution would depend on a proxy connection that hasn’t been established yet.
6. System Time and Node: Rule Out Handshake and Server Issues
A significantly incorrect system date can cause TLS certificate validity checks to fail, and some protocols also rely on accurate time for authentication. The time zone label shown in Windows settings isn’t enough to diagnose the issue; what matters is whether the system clock itself is accurate. Sync the time first, then investigate certificate errors. Don’t work around them by skipping certificate validation.
-
Sync the system clock
Go to Windows Settings → Time & language → Date & time, turn on Set time automatically, check the time zone, then select Sync now. If syncing fails, check the basic network connection and time service first.
-
Check the node settings
Open the current node’s edit window and compare it with the provider’s configuration. Check the server address, port, user ID, transport type, TLS server name and any protocol-specific parameters. Don’t combine fields from different nodes.
-
Compare with another node
Keep the system proxy, routing and DNS settings unchanged; switch to another known-working node in the same subscription. If only the original node fails, check its expiry date, remaining traffic and route status with the provider.
-
Try another network
If the cause is still unclear, test the same node and destination using a mobile hotspot. If the results differ significantly across networks, check for access restrictions, captive portal sign-in or network problems on the current connection.
Error: x509: certificate has expired or is not yet valid
Cause: The system clock is inaccurate, or the remote server’s certificate is actually outside its validity period.
Fix: Sync the system clock and try again. If the error persists, verify the node’s TLS server name and ask the provider to check the certificate deployment.
Error: i/o timeout
Cause: A network operation didn’t finish in time. The timeout may occur during connection, handshake or response reading.
Fix: Use the destination address and surrounding log entries to identify the stage, then compare results with another node and network. A timeout doesn’t automatically mean a DNS failure.
When using VLESS with REALITY, the selected core must support the configuration, and fields such as the public key, server name and short ID must match the values provided by the service. Being part of the V2Ray ecosystem doesn’t mean different cores support identical configurations. A reachable TCP port also doesn’t confirm that the handshake parameters are correct.
If switching nodes fixes it, leave local settings alone
If a different node consistently gets a response with the same proxy entry and destination, keep the existing local settings and focus on the original node’s parameters, service status and route. Don’t change the port and DNS at the same time.
7. Common Questions and Cleanup
The node shows 80 ms latency. Why won’t websites load?
80 ms is only an example latency reading, not proof that websites are reachable. First check whether the test measured TCP latency or made a real connection. Then try the site that fails through an explicit proxy and check whether the request appears in the core log.
Regular websites stopped working after I closed v2rayN. Why?
The system may still be using a proxy that points to a local port. Restart the client and choose Clear System Proxy under System Proxy. Alternatively, go to Windows Network & Internet → Proxy, turn off any leftover manual proxy, then test a direct connection.
Only one website won’t open. Should I reinstall the client?
First, try another HTTPS site with the same node. Then check which routing rule matches the domain, its DNS results and the response status. A 403 or 429 means the server returned an HTTP response; check the site’s access policy or rate limits before reinstalling.
Turning on TUN fixes it. Do I still need to fix the system proxy?
TUN and the system proxy use different traffic paths, so TUN working doesn’t confirm that the system proxy is configured correctly. If you normally use the system proxy, turn off TUN and repeat the port and explicit proxy tests. If you choose TUN, avoid running it alongside other traffic-capture tools.
When you’re done troubleshooting, restore any temporary routing, browser DNS and log-level changes, and remove test settings you no longer need. If the problem persists, note the client and core versions, when it occurred, the proxy entry port, the test destination and a redacted excerpt from the error log. Hide subscription URLs, node credentials and personal network details before sharing screenshots. These details are more useful for diagnosis than simply saying the client shows “connected.”