For users who have imported a node but get connection timeouts or can't load web pages. First, use commands to confirm that the local proxy accepts requests. Then check that app traffic reaches the core, and finally verify the node settings and remote port. Change one setting at a time and test again to distinguish local configuration issues from handshake or server failures. This helps avoid assuming every problem means the node is down.
1. Identify where the timeout occurs
v2rayN manages configurations, starts the core, and sets the system proxy. The selected core handles the actual connection. A working interface or successful subscription update doesn't mean proxy traffic is flowing; subscription downloads and visits to target websites may also take different network routes. Troubleshoot a specific request instead of relying on a status indicator in the node list.
Choose one node, one destination, and one test method. Pause batch tests and automatic switching, and note when the issue occurs. If only the client's test reports a timeout but browsing works, first check whether the test URL is reachable through that node. An unreachable test target doesn't prove that all websites are inaccessible.
- All nodes fail: Check the local port, core startup, and system proxy first. Don't start by editing nodes one by one.
- Only one node fails: Check its configuration, remote port, and server status under the same test conditions.
- Only one app fails: Check whether it uses the system proxy or has its own proxy or DNS settings.
- Only some websites fail: Check routing rules, DNS resolution, and restrictions on the destination site. Reinstalling the client is unlikely to help.
2. Local port: Confirm the core is listening
In v2rayN, go to “Settings” → “Parameter settings” and check the local listening port and proxy type. Field locations may vary between versions, so rely on the settings and startup logs for your version. The example below uses a mixed inbound at 127.0.0.1:10808. If you use separate HTTP or SOCKS inbounds, substitute the corresponding port; the example port isn't a fixed default for every version.
On Windows, run these commands in PowerShell. The first checks whether a port is listening; the second identifies the program associated with the process ID in the results. The port is listening only if you see LISTENING. A connection entry without a listening entry doesn't count as a pass.
netstat -ano | findstr ":10808"
tasklist /FI "PID eq 1234"In the second command, 1234 is an example process ID. Replace it with the actual ID in the last column of the first command's output. On macOS and Linux, use the commands below. If lsof isn't installed on Linux, use ss.
lsof -nP -iTCP:10808 -sTCP:LISTEN
# Alternative check on Linux
ss -lntp 'sport = :10808'- No listener: Check the core startup logs and fix configuration loading errors, a missing core, or permission issues. Then enable the node again.
- Port in use by another program: Identify the process, then stop the conflicting program or change the inbound port. If you change the port, update the app's proxy settings too.
- Listening address mismatch: If the listener is bound only to the IPv6 loopback, requests to the IPv4 address
127.0.0.1may fail. Make sure the address and inbound settings match.
3. System proxy: Isolate the issue with a direct request
Once the local listener is working, bypass the system proxy settings and send a request directly to the proxy port. On Windows, use curl.exe to avoid differences caused by aliases with the same name in some PowerShell environments. On macOS and Linux, use curl. example.com is just a sample destination; use the port configured for your inbound.
# Windows: for HTTP-capable inbounds only
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com
# macOS / Linux: for SOCKS5-capable inbounds only
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.comsocks5h sends the destination hostname to the proxy for resolution. These commands test different inbound protocols; don't use HTTP proxy syntax with a SOCKS-only port. An HTTP response header means the request reached an endpoint that returned a response. If you get a status such as 403, check the site's policies rather than treating it as a connection timeout.
-
Check the proxy port
In v2rayN, go to “Settings” → “Parameter settings” to check the local inbound port and type, then run the matching explicit proxy command.
-
Enable the system proxy
On Windows, open the v2rayN tray menu and choose “System Proxy” → “Automatically configure system proxy” to enable it, then reopen your browser and test again.
-
Check the system settings
On Windows, go to “Settings” → “Network & Internet” → “Proxy”. Confirm the address and port match the client, and check whether another program keeps changing the settings.
-
Check for app-level overrides
Check browser proxy extensions and the app's own network settings. Temporarily disable any separate proxy configuration, use just one traffic-routing method, and test again.
Result: Direct proxy works, so fix the app's proxy settings
If the command works but the browser still fails, check for differences in browser proxy, system proxy, and app DNS settings. Changing nodes usually won't help if traffic isn't reaching the local proxy in the first place.
On macOS, go to “System Settings” → “Network” → select the current network service → “Details” → “Proxies” to check the settings. On Linux, whether the system proxy affects a particular program depends on the desktop environment and how the app is implemented. Command-line tools may not use desktop proxy settings, so use explicit options or proxy environment variables supported by the tool.
4. Client logs: Find the failing stage, not just the last line
Send a request again while watching the v2rayN log area or the log window available in your version. Keep several lines before and after the request, especially the inbound address, destination, routing outbound, and innermost error. A summary such as “failed to process connection” often hides the actual DNS, TCP, or TLS error in the following lines.
bind: address already in use
Cause: The local address and port the program tried to bind are already in use.
Fix: Identify the process using the port and confirm what it's for. Resolve the conflict and restart the core. If you changed the port, update the system proxy settings.
connect: connection refused
Cause: The connection was actively refused. Common reasons include no service listening on that port, or an active rejection by a device or firewall.
Fix: Check whether the address in the error is local or remote, then check the listener and rejection rules on the relevant endpoint.
i/o timeout
Cause: A network read or write didn't complete before the timeout. This message alone can't tell you whether the node is down or the destination site isn't responding.
Fix: Use nearby log entries to find out whether the failure occurred during DNS resolution, connection, or data transfer. Then test the node port and target website separately.
x509: certificate has expired or is not yet valid
Cause: The certificate validity check failed. The local system clock may be wrong, or the server certificate may have expired.
Fix: Sync the system date and time first. If they're correct and the error persists, ask the server administrator to check the certificate and certificate chain.
Error messages vary by system and core. The examples above are common error snippets, not exact full log lines that every version will produce. If access logging is enabled but the request doesn't appear, check the app's proxy settings first. If access logging is disabled, the absence of a visible request alone doesn't prove traffic never reached the core.
5. Node configuration: Check the protocol and transport settings
A successful TCP connection to the remote port doesn't guarantee that proxy authentication or the transport handshake will succeed. VMess, VLESS, Trojan, and Shadowsocks use different authentication and security mechanisms. Transport, TLS, and protocol are separate settings. Changing the protocol dropdown alone can't convert a node to another protocol.
| Item to check | What to verify | How to fix it |
|---|---|---|
| Address and port | Server hostname or IP address and server listening port | Match the provider's details. Don't enter the local port 10808 as the node's remote port. |
| Protocol and authentication | UUID for VMess/VLESS, password for Trojan, and method and password for Shadowsocks | Reimport the complete configuration to avoid typos, extra spaces, or missing characters from manual entry. |
| Transport settings | Transport type such as TCP or WebSocket, plus the corresponding path and Host | Match each setting to the server. Path capitalization and the leading slash must also match. |
| TLS settings | Whether TLS is enabled, server name, and certificate hostname | Use the server's required settings, distinguishing the connection address from the TLS server name. |
| Core support | Whether the selected core supports the node's protocol, transport, and security settings | Check which core actually starts and review any errors. Don't infer support from the client name alone. |
If the subscription has been updated, refresh it from “Subscription Group” and make sure the active node isn't an old entry. Don't remove the TLS server name or disable certificate verification just to try to connect; this can hide configuration errors and weaken connection security. VMess authentication also depends on a reasonably accurate system clock, so time sync is a basic check—not just something to try when a certificate error appears.
- Windows: Go to “Settings” → “Time & language” → “Date & time”. Check that automatic time is enabled, then sync the clock.
- macOS: Go to “System Settings” → “General” → “Date & Time” and check the time source and current time.
- Android: If you use v2rayNG or v2flyNG, check the system time, node fields, and connection logs too. Desktop system proxy steps don't apply directly to Android's VPN-based traffic routing.
6. Server reachability: Separate port access, handshake, and forwarding
After checking the local listener, app entry point, and node settings, test whether your current network can connect to the remote server. In Windows PowerShell, run the command below. Replace example.com and 443 with your node server's address and actual port. Running the example unchanged doesn't prove that your node is working.
Test-NetConnection -ComputerName example.com -Port 443Check TcpTestSucceeded. A result of True means only that the TCP connection was established; it doesn't confirm the UUID, password, TLS, WebSocket path, or server forwarding settings. If the result is False, continue by checking name resolution, the server listener, security groups, and firewalls. For UDP-based transports, this TCP test isn't a substitute for checking the relevant protocol.
- Check DNS resolution: Run
nslookup example.comto check the server hostname. Replace it with your node's hostname and verify that the result matches the server setup. If it resolves to multiple IPv4 or IPv6 addresses, check which address the connection actually uses. - Check the listener: On a self-managed Linux server, use
ss -lntpto check TCP listeners, orss -lnupfor UDP services. Make sure the listening address, port, and process match the deployment. - Check inbound rules: The cloud security group and system firewall must allow the actual server port and protocol. Don't leave all firewalls disabled as a substitute for troubleshooting.
- Check the handshake path: If you're using a reverse proxy, also verify the hostname, TLS certificate, forwarding path, and backend service status. An open entry port doesn't guarantee the backend is working.
- Check server egress: If the handshake succeeds but the destination remains inaccessible, check server DNS, outbound connections, routing policies, and the target site's response.
Result: Compare networks using the same node
Keep the node, device, and destination website unchanged, and test again on another trusted network. If the issue occurs on only one network, check its DNS resolution, IPv6 path, and outbound restrictions first. If the failure occurs at the same stage on multiple networks, focus on the node and server.
ping uses ICMP, which servers or intermediate networks may block. A failed ping alone doesn't prove the proxy port is unreachable, and a successful ping doesn't mean proxy authentication works. Don't use one probe as a substitute for checking the entire connection path.
7. Retest after changes and keep a working baseline
After making a change, repeat the original request path: confirm the listener, run the explicit proxy command, then test the actual app. Change one setting at a time and note whether the error changes. If a connection timeout becomes an authentication error, you've moved to a different stage of troubleshooting—don't undo every change and start over.
- Confirm the fix is repeatable: Send the same request more than once and check that the same error no longer appears in the logs.
- Confirm the route: Check whether the request used a proxy or a direct connection so a successful direct connection isn't mistaken for a working node.
- Restore normal settings: Turn off temporary debug logging, remove unused proxy overrides, and keep only the firewall rules you need.
- Keep details for support: Note the client version, core type and version, node protocol, failure stage, exact error, and results from testing on another network. Don't include authentication credentials.
If the cause is still unclear, see the troubleshooting guide. If you haven't confirmed the import, activation, and system proxy steps, start with the quick-start guide to create a basic setup you can reproduce, then return to the logs. This is usually more effective than changing the node, DNS, and core all at once.