For desktop users whose core is running and a node is selected, but whose browser still times out or reports a proxy connection failure. Start with an explicit proxy request to determine whether the app is sending traffic to the proxy and whether the proxy can complete the request. Then check the listening port, system time, routing, and node settings. The steps below use Windows as an example; use the port shown by your client. Change one setting at a time and record the result.
1. “Connected” doesn’t mean web requests are working
The v2rayN status, node latency test, and website availability are three different things. A running core process only confirms that the program can start. A TCP latency result usually shows only that a connection to the remote port can be established. Authentication, the transport handshake, DNS resolution, and access to the destination website may still fail. Test a real request instead of repeatedly running the latency check.
Newer configurations may use a mixed port that accepts both HTTP and SOCKS, while older ones may use separate inbound ports. 10808 is not a universal default; if the interface shows HTTP on 10809, use that port for HTTP tests. The node’s server port is set by the server—don’t change it to 443 just to match this example.
- First, confirm that sites normally reachable without a proxy still open when the proxy is off.
- Note the current node, routing mode, local port, and time the problem occurred.
- Temporarily use only one traffic-capture method. When troubleshooting the system proxy, turn off TUN to avoid interference between the two paths.
- Open the client log, make one request, and check for errors from the same time.
2. System proxy: Check where the browser sends requests
The system proxy determines whether an app sends requests to a local port. The routing mode determines which outbound is selected once traffic reaches the core. They are not interchangeable. A browser that follows system settings may connect directly if a proxy node is selected but the system proxy is not configured. Conversely, if the system proxy points to a stopped port, sites that normally work may become unreachable.
-
Check the inbound settings
In v2rayN, open “Settings” → “Parameter Settings” and check the local listening address, port, and inbound protocol. Section names vary between versions; use the values shown in your client rather than guessing from an older guide.
-
Set the system proxy
In the main window or tray menu, open “System Proxy” and select “Set system proxy.” This writes the system proxy settings; it does not mean every version enables PAC or captures traffic from every app.
-
Check the system settings
Go to Windows “Settings” → “Network & internet” → “Proxy” and check the current manual proxy or setup script. The manual proxy address should match the local listener. An HTTP proxy cannot point to a SOCKS-only port.
-
Rule out browser overrides
Temporarily disable proxy-switching extensions, check the browser’s own proxy settings, and reopen the test page. If the system proxy settings keep changing, quit other programs that may be modifying them.
Command-line tools don’t necessarily use the Windows system proxy. A successful or failed terminal request doesn’t tell you whether the browser is configured correctly. The explicit --proxy option below bypasses that difference so you can test the local inbound and the connection beyond it separately.
3. Local port: Use an explicit request to isolate the inbound from the outbound
Run these commands in PowerShell. Use curl.exe explicitly to avoid environments where curl resolves to a different command. The first command is for HTTP or mixed inbound; the second is for SOCKS or mixed inbound. Run only the command that matches your inbound protocol—you don’t need both to work.
curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/socks5h sends the destination hostname to the SOCKS endpoint for resolution, which helps distinguish it from local DNS resolution. However, it doesn’t prove that the request uses remote DNS. If an HTTP test returns only 200 Connection established, check the TLS handshake and destination response too. That message confirms the proxy tunnel was established, not that the web request completed.
| Result | Check first | Next step |
|---|---|---|
| Local connection refused immediately | Listening port and core status | Check the port and identify the listening process |
| Local connection succeeds, then times out | Node, handshake, DNS, and routing | Check core logs from the same time |
| Received an HTTP response from the destination | Browser proxy path | Check extensions, system proxy, and cache |
| Returned 403 or 451 | Site access policy | Try another test site; don’t assume the node is down |
Takeaway: If the explicit proxy request works, check the app’s proxy path first
If an explicit proxy request reaches the same destination but the browser fails, fix the browser and system proxy settings first. Resetting the subscription or replacing the core is usually not the first step.
If the port is reported as in use, use the following command to find the process listening on it. Check the local address column and the LISTENING state; the last column is the PID. Then find the process under Task Manager → Details. Don’t force-quit an unknown system process based on its PID alone.
netstat -ano | findstr ":10808"If an old core process is still running, exit the corresponding client normally and restart it. If you change the local port, update both the system proxy and any app-specific proxy settings. Changing only one can turn a port conflict into a connection refusal. For a single computer, keep the listener on 127.0.0.1; there’s no need to expose it to your local network.
4. Time and handshake: Use logs to distinguish authentication from transport errors
An incorrect system clock can affect VMess authentication and cause TLS certificates to appear not yet valid or expired. In Windows, go to “Settings” → “Time & language” → “Date & time,” turn on automatic time, and select “Sync now.” Check the date and time zone too. The clock must show the correct time, not just look close enough.
Error: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
Cause: A common Windows error caused by a conflict between listening addresses and ports. The full log may include an address prefix.
Fix: Use netstat to check the PID, exit the duplicate process, or change the local port and update the system proxy to match.
Error: x509: certificate has expired or is not yet valid
Cause: The system clock may be wrong, or the server certificate may have an invalid validity period. This line alone doesn’t show which side is at fault.
Fix: Sync your system clock first. If the error persists, ask the service provider to check the certificate. Don’t disable certificate validation as a workaround.
Error: dial tcp: lookup …: no such host
Cause: This is a common format for a hostname lookup failure. The omitted part shows the actual hostname, which could belong to the node or the destination site.
Fix: Identify which hostname failed, then check its spelling, system resolution, and the core’s DNS path. Don’t change every DNS setting at once.
Error: context deadline exceeded
Cause: An operation exceeded its timeout. This line alone doesn’t prove the node is down.
Fix: Check the surrounding log entries to see whether the timeout occurred during DNS resolution, the remote connection, or access to the destination, then test that stage.
For VLESS, VMess, or Trojan, importing a node isn’t enough—check its address, port, authentication details, and transport settings. TLS serverName, the WebSocket path, and gRPC serviceName must match the server configuration. REALITY also requires matching the server-provided public key, shortId, and other parameters. Changing protocols isn’t a universal fix, and the client core must support the configuration.
5. Routing and DNS: Check whether requests are using the wrong outbound
If logs show requests reaching the core but some domains fail, check traffic routing. V2Ray/Xray evaluates routing.rules in order and selects an outbound when a rule matches. outboundTag must reference an existing outbounds[].tag. Check the default outbound too—don’t assume unmatched traffic will use the proxy.
- Compare routing first: Note the current mode, temporarily select a routing mode that sends requests to regular sites through the proxy, test the same URL, then restore the original setting. The v2rayN routing mode and system proxy menu are separate controls.
- Check blocking rules next: If regular sites work but one domain fails, check whether it matches a direct or block rule, especially broad domain rules and the order of IP rules.
- Identify which hostname is being resolved: If the node uses a hostname, DNS must work before the client can connect to it. Changing DNS for destination websites may not fix a node hostname lookup failure.
- Understand what the setting does:
routing.domainStrategycontrols how domain names are resolved for routing matches. It doesn’t enable app traffic capture and can’t guarantee that no DNS queries will be sent outside the proxy. - Keep evidence of the request: Temporarily check the destination address and outbound tag in the logs. If the GUI generates the configuration automatically, change the corresponding routing setting; edits to a temporary generated file may be overwritten.
Browser secure DNS, system DNS, and core DNS can use different resolution paths. nslookup shows which resolver the system uses, but it doesn’t prove that DNS inside the proxy works or show where every browser DNS request goes. If only the browser fails, temporarily change its secure DNS setting for comparison, then restore the original setting after testing.
6. Node availability: Distinguish a reachable port from a working protocol
If the local listener is working but an explicit proxy request still fails, test the remote connection. PowerShell’s port test establishes a TCP connection but doesn’t verify VMess, VLESS, or Trojan authentication or transport settings. So TcpTestSucceeded: True narrows down the problem but can’t replace a real web request.
$nodeHost = Read-Host "Enter the current node's server address"
$nodePort = [int](Read-Host "Enter the current node's server port")
Test-NetConnection -ComputerName $nodeHost -Port $nodePort- Check the subscription: Make sure it’s up to date, the account hasn’t expired, and the data allowance hasn’t run out. Don’t share your subscription URL, UUID, password, or full configuration with strangers.
- Try another known-working node: Keep the same local port and routing settings, then test the same URL again. If only one node fails, check its settings and server status first.
- Try another network: Compare your current connection with a mobile hotspot. If the hotspot works but your regular network doesn’t, check the network’s egress restrictions, DNS, and firewall policies.
- Check blocked-connection logs: Security software may allow the interface but block the core from connecting to the internet. Check the program path and logs, then add the necessary allow rule. Don’t permanently disable the firewall as a fix.
If all nodes fail at once and the logs show that the core won’t start, troubleshoot configuration parsing or core compatibility first instead of repeatedly refreshing the subscription. Back up your configuration before upgrading, then confirm that the selected core supports the node protocol. A software upgrade won’t fix an expired certificate, exhausted account allowance, or incorrect server settings.
7. Common questions and checks after restoring access
Why does the latency test show a result when websites still time out?
A TCP test may not complete protocol authentication or reach the destination site. Run the explicit proxy request in this guide, then check the logs from the same time. Verify the local connection, remote handshake, and destination response separately; a latency figure alone doesn’t show whether the service is usable.
Why does only the browser work while other apps still can’t connect?
Some apps don’t use the system proxy. Check the app’s network settings; if it supports HTTP or SOCKS, enter the actual listening address and matching port. Enable TUN only if needed, then check routing and DNS again. The system proxy doesn’t capture traffic from every app.
Why can’t I open regular websites after exiting v2rayN?
Reopen the client, select “Clear system proxy” from the “System Proxy” menu, then go to Windows “Network & internet” → “Proxy” and check whether it still points to an old local port. If your device is managed by an organization, keep the required settings and contact your administrator.
Do I need to reinstall if it breaks again after a restart?
First check the startup order, port conflicts, and whether another program has changed the system proxy. When the issue recurs, record the listening PID and logs to determine whether the core failed to start or the browser’s proxy path stopped working. Reinstalling before finding the cause may only remove a working configuration.
After restoring access, remove any temporary global routing rules and debugging settings added during troubleshooting, while keeping the system proxy mode you need. Retest at least one site that normally connects directly, one that requires a proxy, and the app that failed before. Once all three behave as expected, record the changes that fixed the issue.
- Include when reporting the issue: Client version, core version, operating system version, actual local port, routing mode, and test time.
- What to include from the logs: Share only the relevant lines from around the failure. Before posting, redact subscription URLs, authentication details, and any server information you don’t want to make public.
- Check configuration fields: To understand how inbound, outbound, and routing settings relate, see the JSON Configuration Manual. For basic setup steps, see the Getting Started Guide.