For users whose client is running but websites won’t load. First distinguish client logs from core logs, then check each layer in turn: local listener, routing rules, DNS resolution, remote connection, and protocol handshake. This guide includes recognizable error snippets, port-check commands, and retest steps. Change one setting at a time to avoid mixing up port, DNS, and node issues.
1. Find the Logs First: Client Messages Aren’t Core Errors
v2rayN is a graphical client that typically delegates connections to the selected core. On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. The client handles subscriptions, configuration generation, and process management; the core handles listening, routing, and forwarding. That means “subscription download failed” and “connection to server timed out” may appear in different logs. Don’t assume a node is down based only on the last message in the window.
In v2rayN, start with the log or information area in the main window. Then open Settings → Parameter Settings and look for the log level and logging options available in your version. Group names vary across versions and desktop interfaces, so don’t expect every version to have the same buttons. On Android, check the connection details on the client’s log screen. If the current interface only shows brief messages, look for available core logs or an export option.
- Client logs: Check for failed subscription requests, configuration generation errors, core startup failures, and process exit details.
- Access logs: Check whether an application connection was received, its destination, and which outbound was selected. Available fields depend on the core and configuration.
- Error logs: Look for errors during resolution, dialing, TLS, and protocol handling. A single request may produce multiple nested causes.
- Log files: A file is created only when file output is configured and the directory is writable. Not finding a file in one particular directory doesn’t mean the core isn’t running.
2. Log Levels and Reproducing the Error: Capture One Complete Request
Common error log levels in V2Ray and Xray include debug, info, warning, error, and none. Start with info to observe the connection. If that isn’t enough, enable debug briefly, reproduce the issue, then restore the original setting. Access logs are usually controlled separately; setting error logs to debug doesn’t necessarily enable them.
- Note the client name, the core actually in use, the node protocol, proxy mode, and local listening port. Don’t change the node yet.
- Note when you start testing. Close pages that refresh continuously and pause background downloads to reduce unrelated connections.
- Make sure the core has restarted and applied the logging settings, then access one known destination once.
- Capture the complete error chain around that time. Start with the most specific underlying cause, not just the outer “operation failed” message.
- Change one factor, repeat the same request, and compare whether the error shifts from “local connection refused” to “remote timeout” or another stage.
The snippets below are examples from a core JSON log, provided to explain the fields—not a complete configuration. When using a graphical client, change settings through the client where possible. Direct edits to an auto-generated runtime configuration may be overwritten when you switch nodes or restart.
{
"log": {
"loglevel": "info"
}
}3. Troubleshoot from Local to Remote: Find the Stage Where the Request Stops
This flow is a troubleshooting model, not a guarantee that every configuration follows these stages in exactly this order. For example, a routing rule may trigger a DNS query first, and the proxy server’s hostname may be resolved differently from the destination website’s. The key is to distinguish three connections: application to local client, client to proxy server, and proxy server to destination website.
If there’s no matching log when you visit a website, check whether the application honors the system proxy, bypasses local addresses, and whether access connections are being logged. The system proxy affects only applications that follow that setting; enabling it doesn’t automatically route traffic from every program through the core. TUN mode also involves a virtual interface, permissions, and routing. Test it separately to avoid confusion from enabling multiple traffic-capture methods at once.
These are diagnostic examples, not ports that every client must use. First check the actual inbound protocol and port in the settings. If 10808 isn’t configured as a SOCKS inbound, don’t use the commands below as-is. Use curl.exe in Windows Terminal and curl in macOS Terminal.
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 15 -I https://example.com/socks5h tells the SOCKS proxy to resolve the destination hostname, but the proxy server’s own hostname may still need to be resolved locally. An HTTP response means this request reached at least the destination service. A refusal or error status code doesn’t necessarily mean the proxy connection failed.
4. Port Conflicts and Connection Refused: Fix the Local Entry Point First
Error: bind: address already in use
Cause: Another process is already using the address and port the core is trying to listen on. On Windows, you may also see “Only one usage of each socket address.”
Fix: Identify the process using the port, exit any duplicate client instance normally, or change the local listening port and update the application’s proxy settings to match.
Error: connect: connection refused
Cause: The connection was actively refused, usually because nothing is listening at that address. A firewall may also explicitly reject it, so first identify the destination address in the error.
Fix: If the destination is 127.0.0.1, check the local core and port. If it’s a remote server, verify its listening port and inbound rules.
On Windows, first check whether anything is listening on local port 10808, then use the PID in the output to identify the process. Don’t terminate an unfamiliar system process just because it’s using the port; first check whether it’s another client instance that’s still running.
netstat -ano -p tcp | findstr ":10808"
tasklist /FI "PID eq 1234"The 1234 in the second command is an example PID. Replace it with the actual process ID from the first command, and check whether the status is LISTENING. On macOS, run lsof -nP -iTCP:10808 -sTCP:LISTEN to see what’s listening. After changing the port, restart the core and rerun the single-request test above.
5. Connection Timeouts and Resolution Failures: Separate Address Issues from Network Issues
Error: dial tcp: lookup …: no such host
Cause: The hostname being contacted couldn’t be resolved. It may be the proxy server’s hostname or the destination website’s.
Fix: Check the hostname spelling and subscription details, and identify which resolver handled the query. First verify that the proxy server’s address resolves, then investigate the destination website’s DNS path.
Error: dial tcp …: i/o timeout
Cause: The connection wasn’t established in time. Possible causes include an unreachable network, packet loss, a firewall dropping traffic, or an unresponsive remote service.
Fix: Confirm the address and port in the error belong to the expected node, then test the same node on another network. If it fails across multiple networks, ask the server administrator to check the listener and access rules.
Error: context deadline exceeded
Cause: An operation exceeded its time limit. This message alone doesn’t tell you whether it happened during a subscription download, DNS query, or proxy connection.
Fix: Read the surrounding log lines to identify the operation, then test the subscription URL or node connection separately. Don’t assume every timeout means the node is at fault.
On Windows, run nslookup example.com to check the system’s DNS resolution. This shows only how the current system resolver behaves; it doesn’t prove the DNS path configured in the core is working. To test a remote port, use PowerShell’s Test-NetConnection. Replace the example hostname below with the node’s actual server address.
Test-NetConnection -ComputerName node.example.net -Port 443A true TcpTestSucceeded value means only that a TCP connection was established; it doesn’t confirm a successful VMess, VLESS, TLS, or REALITY handshake. Conversely, a basic TCP test won’t cover every scenario that uses another transport. Don’t replace the server address with an arbitrary IP to “bypass DNS”—that can introduce new issues, such as a TLS hostname mismatch.
6. Certificate Errors and Handshake Failures: Check the Underlying Cause
Error: x509: certificate has expired or is not yet valid
Cause: The current time falls outside the certificate’s validity period. The device clock may be wrong, or the server certificate may have expired.
Fix: Enable automatic time synchronization and check the date. If the time is correct and the error persists, have the server administrator renew the certificate and confirm the service is using the new one.
Error: x509: certificate signed by unknown authority
Cause: The certificate’s trust chain couldn’t be verified. The server may be missing part of the certificate chain, or a network device may be substituting its own certificate.
Fix: Check the server’s certificate chain and your device’s trust store. If needed, retest on another network. Don’t disable certificate verification instead of finding the cause.
Error: tls: handshake failure
Cause: TLS negotiation was rejected or didn’t complete. You may be reaching the wrong service, the server name may not match, or the TLS settings may be incompatible.
Fix: Compare the address, port, server name, and transport settings with the server’s configuration. Restore a known-matching set of parameters first, then test changes one at a time.
Error: EOF / connection reset by peer
Cause: The remote side closed or reset the connection. This can happen during transport, a handshake, or normal connection shutdown; by itself, it doesn’t prove that credentials are incorrect.
Fix: Check when the failure occurred and the surrounding log context, verify the protocol and transport settings, and review the server logs for the same time.
VMess and VLESS identity fields, transport settings, and security-layer parameters must match the server. A WebSocket path, Host header, and TLS server name are separate settings. Don’t set them all to the same value just because they look like domain names. For VMess, also check the system clock and synchronize it before continuing.
- Standard TLS: Check the server name, certificate name coverage, validity period, and trust chain. The node’s display name isn’t the name used for TLS verification.
- REALITY: Check the server-provided public key, short ID, server name, and client support. Don’t apply standard TLS certificate troubleshooting steps.
- Core compatibility: v2rayNG and v2flyNG use different cores. Importing the same link doesn’t mean they support all the same features. For REALITY, confirm that the active Xray configuration and core support it.
7. Subscriptions, Routing, and Partial Failures: Common Questions
The subscription update timed out, but existing nodes still work. Should I change the node?
Not yet. A subscription update is a connection from the client to the subscription server; it doesn’t test a node. Check that the subscription URL is valid. If the client offers an option to update through the proxy, enable it and retry while an existing node is working. Don’t enter a subscription URL as a proxy server address in a node.
Speed test passes, but the browser still won’t load pages. What should I check first?
First check whether the browser request reaches the local listener, then check which outbound was selected. A speed test may measure only latency or use a specific destination; it doesn’t prove browser traffic follows the same path. Retest with this guide’s command that specifies a SOCKS port to rule out ambiguity from system proxy settings.
Only some websites fail. Is it DNS or routing?
Record one working destination and one failing destination, then compare their hostnames, resolution results, and outbound tags over the same time period. If the failed request went direct, check the rule order first. If it went through the proxy and still failed, check resolution, the handshake, and the destination service’s response. Don’t clear all routing rules.
Warnings keep appearing in the logs. Should I leave debug on?
No. First check whether the warnings correspond to actual failed requests; a browser cancelling a connection or a background health check can also leave log entries. Enable debug briefly, reproduce the issue once, then restore the original level. Clear old logs containing browsing records if needed.
8. Before Reporting an Issue: Keep the Smallest Reproducible Log
The goal isn’t to remove every red line from the logs. It’s to identify which part failed and which change reliably affects the result. If the local listener works, the server address resolves, and TCP connects, focus next on the protocol and handshake instead of repeatedly reinstalling the client. If there’s no local listener at all, start by fixing startup errors and port conflicts.
- Environment: Operating system, actual client and core versions, and whether system proxy or TUN mode is enabled.
- Configuration details: Protocol, transport, and whether TLS or REALITY is used. Don’t share credentials.
- Reproduction steps: Test time, local port used, request destination, and whether the issue reproduces consistently.
- Comparison results: What specifically changed after switching networks, trying a known-working node, or restoring the original settings.
- Log context: A short, redacted excerpt from the start of the request through the error. Don’t share only the final “connection failed” line.