Start with a failed request and use its timestamp, destination, outbound tag, and underlying error to pinpoint the problem. This guide is for users who have imported a subscription but can’t connect or load web pages. Learn to distinguish local listener, node connection, TLS handshake, and DNS issues, then check each one in your client without changing multiple settings at once.
Find the right logs: client vs. core
First distinguish a failed client operation from a failed proxy connection. v2rayN manages subscriptions, generates the configuration, starts the core, and sets the system proxy. Connections themselves may be handled by the Xray or V2Fly core. A subscription download timeout doesn’t mean a node handshake failed, and switching websites won’t fix a core that failed to start.
In the v2rayN main window, find the log area at the bottom. Check the startup entries for the core name, version, and start time, then reproduce the issue. Depending on the version, logs may appear in a bottom tab or a separate window, and the menu labels may differ. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. On Android, open the log page from the main-screen menu; desktop menu locations may not apply.
- Subscription: Check the update messages to see whether the request, authentication, or content parsing failed. Don’t share your full subscription URL.
- Startup: Check configuration loading, protocol fields, listener ports, and core exit messages. If the core hasn’t started successfully, don’t troubleshoot the remote website yet.
- When accessing a site: Check inbound requests, routing decisions, remote connections, and response reads. Match each error to the destination you just tried to access.
Understand log levels, addresses, and error chains
Identify which layer the error belongs to, then check its severity. Common Xray and V2Fly log levels include debug, info, warning, and error; none disables the corresponding log output. Access and error logs don’t always use the same output channel. An accepted entry means only that the local request was accepted—not that the remote page loaded successfully.
| Level or entry | Purpose | What to do |
|---|---|---|
debug | Inspect internal processing in greater detail | Enable briefly to reproduce the issue, then turn it off |
info | Monitor startup and some runtime activity | Use this first to check whether the core started and requests are reaching it |
warning | Flag unusual events or failures | Check the destination to see whether the issue affects the current request |
error | Record more serious errors | Prioritize configuration loading and listener failures |
| Access log | Shows the source, destination, and routing tag | Use it to confirm where traffic enters, not as proof of success |
The example below illustrates the format; it’s not a real test result. Field order varies by version, core, and configuration. 127.0.0.1:53124 is a temporary source port used by an application; don’t change the client’s listening port to 53124. Port 443 is the destination port for this request, not necessarily the node server’s port.
2026/08/14 10:15:30 from 127.0.0.1:53124 accepted tcp:example.com:443 [socks -> proxy]
[Warning] ... failed to process outbound traffic > ... dial tcp 192.0.2.10:443: connect: connection refusedAn error chain often starts with a high-level failure and then adds the underlying cause. Find the specific error at the end, then check which destination and outbound it belongs to. 192.0.2.10 in the example is a documentation-only address; don’t use it as a node address. If the log includes a connection ID, use it to link related lines. Otherwise, match entries by timestamp and destination to avoid mistaking a background update request for a browser request.
Connection refused or timed out: check the failing address first
When you see connection refused, first check the address before the colon. If it points to 127.0.0.1:10808, the app may still be using an old proxy port, or the local core may not be listening. If it points to the node address and port, check whether the node is available and whether its port changed in the subscription. 10808 is just a common example; use the actual listening port shown in your client.
Error: connect: connection refused
Cause: The connection attempt was refused. The destination port may have no service listening, or a network device may have actively rejected the connection.
Fix: First determine whether the address is local or belongs to the node. For local issues, check the listener and system proxy. For node issues, refresh the subscription and compare with another known-working node.
Error: i/o timeout
Cause: A connection, read, or write operation didn’t finish in time. This message alone doesn’t prove there’s a DNS problem.
Fix: Check the preceding module and destination to determine whether the timeout happened while connecting or reading. Then try the same node on another network for comparison.
Error: bind: address already in use
Cause: Another process or client instance is already using the local listening address and port.
Fix: Close duplicate instances. If the conflict persists, open “Settings” → “Parameter Settings,” find the local listener port, change it, and save. Update any apps that use a manually configured proxy as well.
On Windows, a port conflict may also trigger a system message such as “Only one usage of each socket address is normally permitted.” It points to a similar listener conflict. Don’t terminate an unknown system process or keep trying random ports without first investigating.
Diagnosis: Stop at startup if the local listener fails
If the core can’t bind to 10808, switching between VMess and VLESS or changing remote DNS won’t fix the listener conflict. First make sure the startup log no longer reports a bind failure, then test whether a request appears in the log.
Handshake failures: check TLS and transport settings separately
A handshake error occurs after a connection is established, but not necessarily during protocol authentication. TLS certificate validation, transport paths, and user authentication are separate checkpoints. Don’t assume every handshake error means “wrong password,” and don’t disable certificate verification as a universal fix.
Error: x509: certificate has expired or is not yet valid
Cause: The certificate validity period doesn’t match the device’s clock. The device time may be wrong, or the server certificate may have expired.
Fix: Enable automatic system time, sync the clock, and try again. If the time is correct and the error persists, ask the node provider to address the certificate issue.
Error: remote error: tls: handshake failure
Cause: The remote server rejected the TLS handshake. The server name, TLS parameters, or server policy may be involved.
Fix: Open the node editor and compare the TLS setting and server name (SNI) with the original configuration. Then test again with an updated subscription.
Error: websocket: bad handshake
Cause: The WebSocket upgrade didn’t receive the expected response. Common causes include a mismatch in the path, Host, or reverse-proxy endpoint.
Fix: Check the transport, path, and Host. Preserve the leading slash and original capitalization in the path, and don’t assume SNI and Host refer to the same field.
- Check the protocol first: VMess and VLESS are different protocols. Changing only the protocol name doesn’t make the rest of the settings compatible.
- Then check the transport: WebSocket, gRPC, and other transport settings must match the server. For gRPC, check the service name too.
- Finally, check the security layer: TLS and REALITY use different fields. For a REALITY node, verify the public key, short ID, and server name against the provider’s details. Don’t apply troubleshooting steps for ordinary certificate errors.
EOF or unexpected EOF only means the connection ended or the data stream was cut off early; it doesn’t by itself prove an authentication failure. If that’s the only message, keep the surrounding log lines and check the transport type and node status. Don’t repeatedly generate new user IDs to try to connect.
DNS timeouts: distinguish node hostnames from destination domains
The right fix depends on where name resolution fails. If the node address is a hostname, the client must resolve it to an IP before connecting. If the destination is a hostname, resolution may be handled by local DNS, the core, or the remote side. The configuration determines which; don’t change everything to a public DNS server just because you see “DNS” in the log.
Error: lookup example.com: no such host
Cause: The resolver couldn’t find a valid address for the domain. The name may be misspelled, the record may not exist, or the current resolution path may be returning an unexpected result.
Fix: First determine whether this is the node hostname or a website domain. Check the spelling and the result on your current network before changing all DNS rules.
Error: context deadline exceeded
Cause: The operation exceeded its deadline. Treat it as a DNS timeout only if the preceding log lines clearly identify the DNS module.
Fix: Check whether DNS requests go direct or through the proxy, and whether that route can reach the selected resolver. Change only the relevant DNS setting.
| Observed symptom | Check first | How to verify |
|---|---|---|
| Node hostname won’t resolve | Resolution path before the node connection | Switch networks and retry the same node; don’t change protocols at the same time |
| Only some domains fail to load | Rules and resolution results for the affected domains | Compare outbound tags for a failing domain and a working one |
| DNS fails only when the proxy is enabled | DNS outbound dependencies and routing loops | Restore a known-working DNS configuration, then enable custom rules one at a time |
Traditional DNS commonly uses UDP port 53; DNS over HTTPS commonly uses TCP port 443. A reachable port doesn’t guarantee correct DNS results, and a timeout on port 443 doesn’t necessarily mean web access is broken. Watch for circular dependencies—for example, resolving the node hostname through the proxy when connecting to that node already depends on resolving its hostname.
Retest in five steps, changing one variable at a time
Turn logs into a repeatable troubleshooting record. The desktop steps below use v2rayN as an example; setting names may vary by version, so follow the labels in your current interface. You don’t need to edit core configuration files by hand. On Android, follow the same verification order and check whether the system VPN permission was granted when connecting.
-
Record the current state
Note the client and core versions, selected node, network type, and time of failure. Open the log area in the main window, save the existing errors, then clear the display to avoid confusion from older entries.
-
Check the startup result
Open “Settings” → “Parameter Settings” and check the actual listening port. To see more detail, find the log level setting and temporarily switch it to
infoordebug. Save and restart the core if prompted, then make sure there are no configuration loading or port binding errors. -
Use a consistent traffic entry point
In the tray menu, open “System Proxy” and select “Automatically configure system proxy.” Turn off TUN during testing to avoid stacking the two traffic entry points. The system proxy affects only apps that honor system proxy settings; check apps with separately configured proxies individually.
-
Reproduce one request
Use a browser that honors the system proxy to open the same HTTPS page. Note the time and find the matching destination in the log. If there’s no entry at all, check the app’s traffic path and log level before assuming the node is down.
-
Change one setting and retest
Use the error chain to choose one setting to change, such as the node, SNI, or DNS path. Compare the same request before and after the change. Once it works, restore the original log level and keep the configuration that resolved the issue.
If the access log shows a request going through direct when you expected it to use the proxy, check the routing rules and their order instead of changing the node certificate. Outbound tags are customizable; proxy and direct are just common names. Check the generated configuration and selected routing mode in your client.
Diagnosis: Compare how the same request progresses
If a change turns a “node connection timeout” into a “TLS handshake failure,” the failure has moved to a different stage; that doesn’t mean it’s fixed. Follow the new error to its underlying cause. Consider this round of testing complete only when the same page loads and the related requests stop failing.
Common questions about log troubleshooting
There are no errors in red. Why won’t the page load?
First check whether the log contains an access entry for the destination. If there isn’t one, check whether the browser honors the system proxy and whether the proxy ports match. If there is an entry, check its outbound tag and the errors that follow. A high log level or disabled access logging can also make entries appear sparse.
I keep seeing warnings. Should I delete all my nodes?
No. First close apps making background network requests, then reload one page and find warnings from the same time. Some failures may come from canceled requests or unreachable destinations; the number of warnings alone doesn’t mean every node is broken.
Should I troubleshoot a failed subscription update as a handshake error?
First distinguish subscription downloads from node connections. Check the update result under “Subscription Groups” and make sure the subscription URL is still valid and accessible on your current network. If the interface offers an option to update through a proxy, try it only when you already have a working proxy connection; otherwise, you may depend on a node you haven’t imported yet.
The latency test succeeded. Why does browsing still time out?
A latency test may check only the connection or a specific test destination. It doesn’t prove that every website, DNS request, and transport is working. Keep the same node, reproduce the failure in your browser, compare the domain, destination port, and outbound tag, then inspect the error chain for the actual request.
What should I keep in a log when sharing it for help?
Keep the client and core versions, error timestamp, protocol and transport types, ports, and the complete error chain. When replacing sensitive addresses, use consistent labels such as “node hostname” and “destination domain”; don’t replace different destinations with the same label. Don’t include subscription URLs or user credentials in screenshots.