v2rayN Connected but Websites Won’t Load: Troubleshooting Checklist

At a Glance

Use this checklist when a server is selected and the core appears to be running, but your browser times out or refuses the connection. First confirm that the browser is sending requests to v2rayN, then check the local listener, remote server, and TLS handshake. Finish by reviewing routing and firewall settings. Change one thing at a time and test the same URL each time so you can tell a real fix from a temporary recovery.

1. System Proxy: Make Sure Browser Requests Reach the Core

A “connected” status does not prove that websites are reachable. Selecting a server sets the configuration for outbound connections, and a running core confirms that the process is active. Whether the browser uses the proxy, the server accepts the connection, and the destination returns content are separate steps. Temporarily turn off “Enable TUN” in the main window and run a basic test with the system proxy first. This avoids the added complexity of having both traffic-routing methods active at once.

Set the System Proxy

In the v2rayN main window, select “System Proxy” → “Automatically Configure System Proxy.” In some versions, the option is at the bottom of the window or in the tray icon’s right-click menu. Don’t leave it set to “Clear System Proxy” or “Do Not Change System Proxy.”
Check Windows Settings

In Windows 11, go to “Settings” → “Network & internet” → “Proxy” → “Manual proxy setup.” Make sure the proxy server is enabled, the address is 127.0.0.1, and the port matches the HTTP or mixed listening port actually used by the client.
Rule Out Browser Overrides

Temporarily disable browser proxy extensions. Edge and Chrome usually follow the system proxy; in Firefox, also go to “Settings” → “General” → “Network Settings” → “Settings” and check whether “Use system proxy settings” is selected.
Check for New Log Entries

Open an HTTPS page that previously failed and watch the main-window log or connection list. A new request for that domain means the request has at least reached the core. If nothing appears, check how the browser is routed before switching servers.

Some versions may hide access entries depending on the log level, so no entry is a clue, not proof. The explicit proxy command later in this guide bypasses the system proxy settings and tests the local entry point directly.

2. Listening Ports: Check Whether the Core Is Running or the Port Is in Use

Go to “Settings” → “Parameter Settings” and check the local listening port. Recent versions of v2rayN commonly use 10808 as a mixed port for both HTTP and SOCKS requests. Some older configurations use 10808 for SOCKS and 10809 for HTTP. Don’t copy a port from an older guide into your current system settings. The commands below assume the actual mixed port is 10808.

netstat -ano | findstr :10808
curl.exe -I --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://www.microsoft.com/

The netstat output should include a LISTENING line for the local address; the last column shows the process PID. In “Task Manager” → “Details,” find that PID and confirm the listener belongs to the core you just started, not another client instance. The command’s 10-second value is the connection timeout and 20 seconds is the total request timeout; neither represents measured network latency.

What You See	Likely Cause	Next Step
No LISTENING entry	Wrong port or core failed to start	Review the startup log, fix any configuration errors, and select the server again
The listening PID belongs to another program	Port conflict	Close the conflicting instance, or change the local port and update the system proxy to match
The explicit proxy command receives an HTTP response from the site, but the browser still fails	The local entry point and this request are likely working	Check browser extensions, per-browser proxy settings, and cached connections
The local listener works, but requests keep timing out	The remote connection, DNS, or routing may still be failing	Test the server again and check the error log for the same time

Takeaway: Lock Down the Entry Point Before Changing the Outbound Route

If the explicit proxy command receives a response from the destination, keep the current server and port and focus on the browser’s proxy path. A message showing that an HTTP CONNECT tunnel was established is not enough: verify the subsequent TLS handshake and destination response before considering the request successful.

3. Server Availability: Tcping Doesn’t Prove the Proxy Works

Select a server in the list, right-click, and choose “Test Server Real Connection Latency.” You can also compare it with “Test Server Latency (Tcping).” The wording may vary slightly by version; the key is to distinguish an open TCP port from a successful end-to-end proxy request. Successfully importing a subscription only confirms that the configuration was read, not that the remote service is still working.

Tcping succeeds, but the real connection test fails: Check the protocol, port, user ID, transport, TLS serverName, and any other authentication parameters required by the server. A TCP handshake does not validate these settings.
Both tests time out: Check whether the server hostname resolves and the remote port is still accepting connections. Then test the same server over another available network for comparison.
The real connection succeeds, but one website won’t load: Try another HTTPS site. A speed-test URL may match a different routing rule, so its success does not rule out a routing issue or server-side restriction for the target domain.
Another server works: Keep the working server as a baseline, then check the subscription details for the failing server. Don’t reinstall the client, reset DNS, and change the firewall all at once.

VMess and VLESS are protocol configurations, not interchangeable options. Don’t switch a server’s protocol or remove TLS verification settings just to see what happens. If the provider has changed the address or authentication parameters, update the relevant subscription from the “Subscription Group” menu, then confirm the active server uses the updated entry.

Error: connection refused

Cause and fix: The address in the error actively refused the connection. Check that address first: if it is 127.0.0.1:10808, fix the local listener; if it is the server address, check the remote port and service status.

Error: i/o timeout

Cause and fix: A read or write operation exceeded its time limit. This message alone doesn’t identify where the failure occurred. Check the destination address in the full log to narrow it down to the server connection, DNS lookup, or destination response.

4. System Time and TLS: Don’t Bypass Errors by Disabling Verification

A significantly incorrect system clock can cause certificate validity checks to fail and may also affect protocols with time-based authentication. In Windows, go to “Settings” → “Time & language” → “Date & time,” turn on “Set time automatically,” check the time zone, and select “Sync now.” Make sure the actual date and time are correct—not just that the hour looks about right.

Error: x509: certificate has expired or is not yet valid

Cause and fix: The certificate has expired, is not yet valid, or the system clock is wrong. Sync your system time first. If the error persists with the correct time, ask the server administrator to check the certificate’s validity period.

Error: x509: certificate signed by unknown authority

Cause and fix: The certificate chain can’t be trusted, or HTTPS traffic may be inspected by the network. Check the server’s certificate chain and your network environment. Don’t enable certificate verification bypass.

With TLS, the connection address and the serverName used for certificate verification may differ; use the value specified by the server configuration. Don’t replace serverName with a popular website’s domain. For REALITY servers, also check the public key, shortId, and serverName specified by the server. Changing the local listening port won’t fix incorrect parameters.

5. Routing and DNS: Use Global Mode Only as a Diagnostic

After the first four checks pass, review the “Routing” selection in the main window. Note the current rule set, then temporarily switch to the built-in “Global” mode and test the same URL again. For standard proxy requests, this can reveal whether the original direct, proxy, or block rule is misapplied. It does not mean that all apps or DNS requests are being routed through the proxy.

Test Result	Possible Cause	Where to Check
Global mode works; the original rules don’t	The destination is going direct, being blocked, or matching an unsuitable outbound route	“Settings” → “Routing Settings”: check rule order and destination-domain conditions
The log shows no such host	The domain name could not be resolved	Determine whether the unresolved hostname belongs to the server or the destination site, then check the corresponding DNS path
Only the custom routing configuration fails to start	Invalid rule syntax or an unavailable required data file	Restore the built-in rules and check the startup log for the specific field or file error
Both Global mode and the original rules fail	Routing may not be the cause	Review the server handshake and local entry point instead of piling on more domain rules

Routing rules are generally evaluated in order, so an earlier broad rule can override a later, more specific one. For rules such as geosite:cn and geoip:private, confirm that the current core can read the required data. Xray and other cores don’t use identical configuration formats; don’t paste entire configurations between different cores.

Running nslookup www.microsoft.com in Windows Terminal only shows how the system resolves the name; it does not confirm that the core’s remote DNS is working.
If you suspect the system DNS cache, adjust the relevant settings, then run ipconfig /flushdns and reopen the browser to test again. Clearing the cache won’t fix server authentication errors.
Restore your original routing rules after testing, then fix them one at a time. Don’t leave temporary Global mode enabled as a long-term fix for every DNS issue.

6. Firewall and TUN: Check Permissions and Blocks Last

Check security software’s block history only after confirming that the local listener, server settings, and DNS are working. Go to “Windows Security” → “Firewall & network protection” → “Advanced settings,” then look under “Outbound Rules” for a block rule targeting the current core executable. Client updates may change the program path, so verify the actual file location rather than relying on an old rule name.

Testing the local proxy only: You generally don’t need to expose the listener to your local network or forward 10808 on your router. Don’t enable “Allow connections from the LAN” to fix website access.
A specific block rule is present: Add a narrowly scoped allow rule only for the trusted client and current core. Don’t permanently turn off the entire firewall or all security protections.
System proxy works, but TUN doesn’t: Grant the administrator permissions requested by the client, check the virtual network adapter and route-creation logs, and test again after closing other traffic-routing software.
On a work or campus network: Follow the network administrator’s policies. If the same configuration works on another network, note the difference and ask the administrator to check the network’s egress policy instead of granting broader permissions on your PC.

7. Common Follow-Up Questions: Verify the Fix

Why does my browser work, but terminal commands still time out?

Many command-line tools don’t automatically use the Windows system proxy. First use the curl.exe --proxy command above to specify the entry point explicitly. Once it works, configure the tool using its own proxy settings; a working browser alone doesn’t prove terminal traffic is using the proxy.

After closing v2rayN, why can’t I open regular websites?

Check whether the system proxy still points to the local port that is no longer running. Reopen v2rayN and select “System Proxy” → “Clear System Proxy,” or turn off the manual proxy in Windows settings, then reopen the browser and test again.

Why does the real connection test show a latency value while the page keeps loading?

A latency test covers only its test address and the request made at that time. Check the log while testing the same failing domain, and temporarily compare it in the built-in “Global” routing mode. If only that site fails, focus on its routing rules and the destination service. A latency result doesn’t prove that every site is reachable.

What information should I provide if it still doesn’t work?

Record the exact v2rayN and core versions, Windows version, proxy mode, local port, and log entries from around the time of the failure. Before sharing, redact subscription links, user IDs, authentication parameters, and private addresses. Include the original error, the stage where it occurred, and the steps you tried.

After fixing the issue, undo your changes in reverse order: restore your usual routing rules, revert temporary settings, confirm that the browser and other apps that need the proxy can connect, then exit the client and check that the system proxy was cleared correctly. Note the working port, server, and rule-set name so you can compare against this baseline after the next update.