This guide is for users who have imported a node but cannot connect, open webpages, or maintain a stable connection. The goal is not to translate every log line, but to note when the failure occurred, then find the first anomaly across inbound listening, route matching, and remote outbound connection. Confirm the cause with one-variable tests.
Find the runtime logs that matter
v2rayN, v2rayNG, and v2flyNG all show client status, but interface notifications are not the core runtime log. Messages such as “Started successfully” or “Test completed” only confirm that an action ran. To see where a request stopped, check core output containing the timestamp, log level, destination, and error chain.
In v2rayN 7.x, start with the “Information” area on the main screen. To change the logging scope, open “Settings” → “Parameter Settings” and look for the core log-level options. In v2rayNG 1.10.x, open “Logs” from the side menu; the log level is usually under the advanced options in “Settings.” Names may vary slightly by minor version, but choose core logs rather than relying only on subscription update notices.
Reproduce the issue cleanly before recording logs
- Stop downloads, speed tests, and background sync to reduce unrelated connections.
- Clear the current log, or note the exact time when testing begins.
- Start the target node, wait for the core status to stabilize, then open a specific URL or app feature.
- Reproduce the issue within 30 seconds, stop immediately, and save about 20–50 log lines from before and after the failure.
- Record the node used, system proxy status, TUN status, and local port, but never share a complete subscription URL, UUID, password, or access token.
Read the error chain through inbound, routing, and outbound
A request usually starts in a browser or another app, enters the core through a local SOCKS, HTTP, or TUN inbound, matches routing rules, and is then sent through a proxy node or direct connection. Log errors often combine information from several layers: the outermost message describes the processing failure, while the innermost message is closest to the original cause.
Do not search only for the final error. First check whether a new connection appeared around the same time, then follow the error chain from outside in and look for keywords such as dial, lookup, authentication, routing, and bind. The first anomaly is more useful than the batch of cancellation messages that follows.
Stage 1: Did the inbound receive the request?
If no new connection appears in the log after you open a webpage, the request probably never reached the core. Check whether the system proxy is enabled, whether the browser uses its own proxy, whether the app bypasses the system proxy, and whether the local address and port match. v2rayN commonly uses local port 10808, but after an upgrade, configuration migration, or manual change, use the actual value shown under “Settings” → “Parameter Settings.”
- A connection from
127.0.0.1appears in the log: the app has reached the local inbound. - No new entries at all: first check the app proxy settings and system proxy status.
bindoraddress already in useappears: another process is using the local listening port.- A SOCKS client connects to an HTTP port: you may see a protocol version error or an immediate connection refusal.
Stages 2 and 3: Which outbound did the rules select?
Once the inbound is working, confirm whether the request is sent through the proxy, direct connection, or blocked outbound. If routing rules are ordered incorrectly, the node itself may be fine while the destination domain is caught by an earlier direct or blocking rule. Then inspect outbound dialing: domain resolution, server port, transport, TLS parameters, and user authentication all occur at this stage.
| Where to look | Typical symptom | Check first |
|---|---|---|
| Inbound | No connection record or listening failure | System proxy, port 10808, protocol type |
| Routing | Request uses the wrong outbound | Rule order, domain classification, direct and blocking rules |
| Outbound | Dial timeout or authentication failure | Server address, port, UUID, transport, and TLS |
| Response stage | Connected but disconnects soon after | Remote response, network changes, idle connection closure |
What do rejected, timeout, and invalid user mean?
The wording may vary slightly across the V2Ray and Xray cores, transport methods, and versions. Focus on the action: rejected means a layer explicitly refused the connection, timeout means an operation did not finish within the allowed time, and invalid user points directly to mismatched authentication details.
Error: rejected
Cause and fix: A refusal may come from the local inbound, a routing block, or the remote server. Read the module name after rejected first. If blocked also appears, inspect the routing rules; if it is followed by authentication or invalid user, verify the node’s authentication parameters.
Error: connection timeout
Cause and fix: The core could not establish the connection within the time limit. Check the server address and port first, then test the current network against another available network. If only one node times out, focus on its parameters or remote reachability.
Error: dial tcp: i/o timeout
Cause and fix: The TCP dial did not complete in time, commonly because the destination is unreachable, the port is not responding, or the network path is unstable. Do not change the UUID first; check the address, port, and basic network connectivity.
Error: invalid user
Cause and fix: The server did not recognize the user information submitted by the client. For VMess or VLESS nodes, verify the UUID, additional authentication parameters, and subscription update time, and make sure an old node is not being used with a new configuration.
Error: failed to find an available destination
Cause and fix: The outbound could not find an available destination. Possible causes include address resolution failure, an empty destination list, or failure of every preceding dial attempt. Check the node address and DNS result, then restart the core and test again.
Error: context canceled
Cause and fix: The current operation was canceled by an upper layer, commonly after switching nodes, stopping the core, or an earlier connection failure. It is usually a follow-up result, so look earlier for a timeout, rejected, or authentication error.
Error: address already in use
Cause and fix: The local port selected for listening is already in use. Exit duplicate client processes or choose an unused local port under “Settings” → “Parameter Settings,” such as changing 10808 to another available port, then update the app proxy settings to match.
Do not treat every rejected message as a failed node
Logs may include ad domains, local-network discovery, system connectivity checks, and user-initiated requests at the same time. A request intentionally refused by a blocking rule can also produce a rejected message. Treat it as a primary clue only when its timestamp matches the action and the domain or IP belongs to the target you were accessing.
- One domain fails while other sites work: check that domain’s routing category and DNS result.
- All proxy requests time out: check the node address, server port, and current network.
- Every node reports a port conflict: fix the local inbound instead of editing nodes one by one.
- invalid user appears right after a subscription update: confirm that the client is actually using the updated node.
Narrow the fault with one-variable tests
Reliable troubleshooting depends on repeatable comparisons. If you change DNS, the port, transport, and routing rules at once, even a restored connection will not reveal which change helped. Keep a copy of the original configuration, change one variable per round, and retest with the same destination.
- Confirm the local inbound: After starting the core, verify that it is listening successfully on the configured port and watch whether the browser request appears in the log.
- Confirm the selected node: Select the target node again on the client’s main screen so you do not edit one node while continuing to use another.
- Simplify routing temporarily: With the configuration impact understood, retest using basic proxy rules to determine whether complex split routing is causing the misclassification.
- Verify outbound parameters: Compare the server address, port, VMess or VLESS type, UUID, transport, TLS settings, and server name one by one.
- Compare another network: Keep the node and client configuration unchanged and switch only the network. If a persistent timeout becomes a normal connection, the problem is more likely somewhere along the current network path.
- Restore and verify: Once the cause is identified, restore other temporary settings, then visit three commonly used destinations in succession and watch for repeated errors for at least 2 minutes.
A complete diagnosis of a port conflict
Suppose webpages become completely inaccessible after v2rayN starts, and the first log entry is a local listening error rather than a remote dialing error. Fix port 10808 first; do not switch nodes or change transport parameters. A typical log may look similar to this:
failed to start inbound
listen tcp 127.0.0.1:10808: bind: address already in useFully exit duplicate client processes and start again. If the port is still occupied, select another unused local port under “Settings” → “Parameter Settings,” and make the browser or system proxy use the same port. After the change, the log should show successful listening first, followed by connections from the local machine. Only after the request reaches the core should you inspect routing and outbound dialing.
Practical fixes for common log symptoms
Some faults do not correspond to a single error message, but appear as combinations such as “a connection is logged but the webpage never returns” or “it works at startup, then times out after a few minutes.” The steps below address the first checks for common symptoms; afterward, return to the log around the failure time.
The log keeps scrolling. How do I find the failure from a moment ago?
Clear the log first and stop background downloads. Open only one test webpage, note the click time, then search the next 30 seconds of entries for the destination domain, timeout, rejected, failed, or error.
It says startup succeeded, but the browser produces no new log entries?
Check v2rayN’s system proxy status and whether the browser has its own proxy configured. If the proxy is entered manually, the address should be 127.0.0.1 and the port must match the client’s current setting.
Only one node shows connection timeout?
Keep the network unchanged and switch to another known-working node. If the other nodes work, verify the affected node’s server address, port, and transport parameters, then update the subscription and select the node again.
Many context canceled messages appear after switching nodes?
Switching nodes terminates old connections, so these entries usually need no separate action. Wait for the new core to stabilize, test again, and look for an earlier dialing or authentication error in the new time window.
v2rayNG says it is connected, but the app still times out?
Open Logs from the side menu and check whether requests from the target app appear. If there are no entries, check the system connection permission and the app’s own proxy settings. If entries exist, continue through the routing and outbound stages.
How to tell a DNS issue from a node issue
If the log shows a domain resolution failure while other requests using known IP addresses work, DNS is the more likely cause. If the node server itself uses a domain, resolution failure will block outbound dialing directly; if only the destination domain fails to resolve, also check DNS split routing and domain rules. Do not assume every timeout is DNS-related, since an unreachable port can time out as well.
lookuporno such hostappears: check the DNS settings and node address spelling first.- The IP resolves, then
dial tcptimes out: focus on the port and network path. - TCP connects, then an authentication error appears: verify the UUID, protocol type, and server-side parameters.
- Only specific domains use the wrong outbound: check routing rule order and whether GeoSite data is up to date.
Outdated routing data can classify domains differently from expected, but it normally does not cause invalid user. Match each error to its processing stage to avoid unrelated changes: authentication errors point to user parameters, listening errors to the local port, resolution errors to DNS, and incorrect rule matches to routing.
Keep a troubleshooting record you can review
Intermittent disconnections are the hardest to diagnose because restarting may temporarily restore service. Instead of saving only the final error, keep a structured record so the next reproduction can be compared directly. Include the client, core, network environment, node type, failure time, and first anomaly.
| Item | Example | Purpose |
|---|---|---|
| Client and version | v2rayN 7.x | Identify menu locations and default behavior |
| Core type | Xray or V2Ray | Explain differences in log wording |
| Local inbound | 127.0.0.1:10808 | Verify that the app connects to the correct port |
| Protocol and transport | VLESS and TCP | Limit the scope of authentication and transport checks |
| Reproduction time | 14:32:10 to 14:32:40 | Locate the request among many log entries |
| First anomaly | dial tcp: i/o timeout | Separate the root cause from subsequent cascading errors |
When contacting the person maintaining the configuration, provide the environment details above and redacted error excerpts. Remove the subscription URL, UUID, password, token, complete server address, and personal domains. The timestamp, module name, error type, and port are usually enough for most diagnoses.
- Copy the original text first, then redact sensitive information to avoid cutting off important context in a screenshot.
- Keep at least 10 lines before and after the error, and note what action was being performed.
- State whether the problem is reproducible or intermittent, along with the comparison results after switching networks or nodes.
- After applying a fix, repeat the same action and confirm that the original error no longer appears instead of relying only on a “Connected” status.