For users who have imported a subscription but encounter timeouts in v2rayN's real connection test, can't load webpages in a browser, or see the core fail to start. Check the local listener first, then verify the subscription and node, and finally check the system proxy and network restrictions. Change one setting at a time and use command output and logs from the same test to pinpoint the issue—don't start by reinstalling the client.
First, identify the issue: local port, node timeout, or browser proxy settings
Keep your current configuration and note the selected node, test time, and error. Pause batch latency tests, reproduce the issue with one node, then check the corresponding entries in the main window's log. Batch tests create many connections at once, which can make errors from other nodes look like the current issue.
v2rayN is a graphical client; the selected core handles the actual connection. An open interface and visible subscriptions don't mean the core is running. Latency values in the node list also depend on the test method: a TCP connection test only indicates that the destination port may be reachable, while a real connection test also involves the proxy protocol, handshake, and test URL.
| Symptom | Check first | What this doesn't prove |
|---|---|---|
| All nodes fail immediately; logs report a listener error | Local port, core process, configuration loading | This doesn't mean the entire subscription is invalid |
| TCP test returns a value, but the real connection test times out | Protocol settings, TLS, test URL, server egress | A reachable TCP port doesn't mean the proxy works |
| Real connection test succeeds, but the browser still fails | System proxy, browser-specific proxy, routing rules | A browser failure alone doesn't mean the node is offline |
| Only one node keeps timing out | That node's address, port, credentials, and service status | You usually don't need to change global system settings first |
Layer 1: Check the system clock, local port, and core startup
These steps use v2rayN on Windows as an example. Interface labels may differ between versions; use the port shown in your actual configuration. Go to Settings → Parameter Settings and find the local listener settings. Check the SOCKS or mixed listener port; don't enter the remote server port in the system proxy settings.
-
Sync the system clock
Open Windows Settings → Time & language → Date & time, turn on Set time automatically, then select Sync now. Check the date and time zone. A significant clock offset can affect certificate validity checks and some protocol authentication. A different time zone alone doesn't mean the system clock is wrong.
-
Check the listening port
In v2rayN, go to Settings → Parameter Settings and check the listener address and port. This guide assumes the SOCKS or mixed listener is at
127.0.0.1:10808. If the interface shows a different port, update it in the commands below too. -
Find the process using the port
Run the query below in PowerShell. After finding the listening status and PID, check the process in the task list. A listener belonging to the current core is usually expected. If it's an old client instance or another program, exit the conflicting program normally or assign the current listener an unused port.
-
Reload the core
Save your settings, select the node again, and check the logs. If needed, exit and restart the client. After changing the port, update the port in your browser's proxy settings and command-line commands too. If nothing is listening, fix the core startup error before testing remote nodes.
Get-NetTCPConnection -State Listen -LocalPort 10808
netstat -ano | findstr ":10808"
tasklist /FI "PID eq 1234"The 1234 at the end is an example PID; replace it with the process ID returned by the first two commands. In netstat output, distinguish the local address from the remote address and confirm the state is LISTENING. Seeing the number 10808 doesn't prove another process has taken the port. Don't force-quit an unfamiliar system process.
Layer 2: Confirm the subscription updated successfully—not just that it still appears in the list
The subscription list may show data saved during the previous update. If an update fails, old nodes remain visible, so having dozens of nodes doesn't prove the subscription is currently valid. Go to Subscription Groups → Subscription Group Settings and check the group URL. Then use the update action under Subscription Groups and check the result and last-updated time.
- Returns 401 or 403: Check the subscription token, access permissions, and provider restrictions first. These status codes mean the request reached an HTTP service; they aren't simply a sign that the local port isn't running.
- Returns a webpage or login page: Make sure you copied the subscription URL, not an account management page. A page loading successfully doesn't mean its contents are a node configuration the client can parse.
- Request times out: First check whether the subscription domain requires a proxy. If a node works, try the menu option to update through the proxy. If no nodes work, repeatedly choosing update through the proxy creates a catch-22.
- Update succeeds, but nodes still fail: Check whether your provider account has expired, your data allowance is depleted, or nodes have moved. Downloading the subscription and authenticating with a node are separate steps.
Back up your existing configuration before updating; don't delete every group just to test. If the list is empty after an update, check the response content and format compatibility first. Changing system proxy settings won't turn an invalid subscription response into working nodes.
Layer 3: Check node settings and use logs to distinguish connection failures from handshake failures
Double-click the current node to open its settings, then compare each field with the original parameters from your provider. Check the address and port first, then the protocol and transport. Don't guess the protocol from the node name, or copy TLS and transport settings in bulk from a working node to other nodes.
- VMess: Check the UUID, encryption method, and any other fields required by the server. When migrating an old configuration, re-import it according to the server's current instructions. Don't change authentication settings at random.
- VLESS: Check the UUID, flow settings, and any required TLS or REALITY parameters. For REALITY nodes, also match the public key, short ID, server name, and other fields provided by your service.
- TLS: Check that the server name matches your provider's requirements. The node's connection address may differ from the domain on its certificate; don't assume they should be the same.
- WebSocket: Check the transport type, path, and Host. Paths are usually case-sensitive; a missing leading slash or incorrect Host can cause the handshake to fail.
- Core compatibility: Confirm that the current core supports the protocol and transport combination required by the node. v2rayN is the client name; V2Ray and Xray are core projects. They aren't different names for the same version.
Error: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
Cause: The current listener address and port are usually already in use. Fix: Find the listening process, exit duplicate instances or change the local port, then reload the core.
Error: dial tcp: lookup
Cause: This is a common fragment of a name resolution error; the full log line usually includes a domain and specific error. Fix: Check the server address, test the domain with a system DNS lookup command, and review the core's DNS settings to confirm the resolution path.
Error: i/o timeout
Cause: A network read or write operation exceeded its timeout. This alone doesn't prove the server is down. Fix: Check the destination address and operation in the same log line or nearby entries, then test the server port and a destination URL through the proxy separately.
Error: x509: certificate has expired or is not yet valid
Cause: The system clock is wrong, or the server certificate is outside its validity period. Fix: Sync the clock first. If the issue persists with the correct time, ask your provider to renew the certificate; don't routinely bypass certificate verification.
Use PowerShell's Resolve-DnsName to check the server domain and Test-NetConnection to test the port. Use the actual server address and remote port from the node settings—not local port 10808. A successful system lookup only confirms that the system's DNS path works. If the core uses its own DNS, check the core logs too.
What it means: If TCP is reachable, focus on the handshake settings
If the server port test succeeds but proxy requests consistently fail, check authentication, TLS, and transport settings instead of repeatedly changing the local port. A successful TCP test doesn't rule out server-side rate limits or network interference, but it does narrow down what to check.
Layer 4: Test the proxy entry directly, without relying on system proxy settings
Once the core is listening, run the command below in PowerShell. It connects directly to the local SOCKS entry, regardless of whether your browser uses the system proxy. The 10808 port here must support SOCKS. If it's a dedicated HTTP entry, use the HTTP syntax below and enter the actual port.
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 --head https://example.com/socks5h sends the destination domain to the proxy for resolution, reducing the effect of local DNS lookups for the destination site. Receiving an HTTP status line usually means the request got an HTTP response through this entry. Still check the logs to confirm routing: connecting explicitly to the client doesn't guarantee the request ultimately uses remote proxy egress.
curl.exe --proxy http://127.0.0.1:10809 --connect-timeout 5 --max-time 15 --head https://example.com/The second command is for an HTTP entry only. 10809 isn't a fixed port available in every version; don't copy it unless that entry is enabled. Choose a test URL that your network and service policy allow. If one URL fails, try a separate site for comparison so you don't mistake a destination service outage for a node failure.
- Command succeeds, browser fails: In the v2rayN main window, select Auto configure system proxy under System Proxy at the bottom. Then check whether Windows Settings → Network & Internet → Proxy points to the current local entry. Also check any proxy configured directly in the browser.
- Fails only in routing mode: Temporarily test with a rule that clearly sends the destination through proxy egress, then restore your original rules. Use the logs to check rule order, domain matching, and the final outbound route; don't rely on the mode name alone.
- All local requests are refused: Go back to Layer 1 and confirm the core is still listening. A browser's proxy connection error doesn't necessarily mean the remote node was involved.
- System proxy works, but some apps fail: The app may not use the system proxy. Check its own network settings first. TUN is a separate traffic capture method; don't enable it on top of an unverified basic connection.
Still timing out? Compare networks and gather concise diagnostic details
After checking all four layers, test the same node on the same computer over your current network and a phone hotspot. Change only the network each time; don't also change DNS, node settings, and routing mode. If it fails on just one network, check that network's DNS, outbound restrictions, captive portal, or connection quality first. If the same node fails on every network, contact your provider.
| Item | What to record |
|---|---|
| Client and core | Record the actual client version, core type, and core version—not just “latest” |
| Time of issue | Include the exact minute and time zone so it can be matched to server logs |
| Local checks | Listening port, process name, and result of the explicit proxy command |
| Network comparison | Whether the issue occurs on your current network and hotspot, and whether only one node fails |
| Error context | Include a few log lines before and after the same request; redact authentication fields and subscription tokens |
Bottom line: Keep each step reproducible
A working local listener, a successful subscription update, matching node settings, and a successful explicit proxy request are more useful than a single latency number. Once the connection works, restore any temporary test rules and network settings, then save the working configuration. There's no need to keep changing a stable connection just to chase a lower test result.