How to Read V2Ray Logs: Common Errors and Troubleshooting

Identify which layer produced the log

v2rayN, v2rayNG, and v2flyNG are clients; V2Ray and Xray are the cores that handle connections. A subscription download can fail in the client’s updater before the core receives any request. By contrast, entries containing module paths such as proxy/vless/outbound or transport/internet usually indicate that the core is processing the connection. These problems require different starting points for troubleshooting.

In v2rayN, start with the log area in the main window, then check the logging options under Settings → Parameter Settings. In v2rayNG, open Logs from the main-screen menu and check the log level in Settings; menu locations and translations can vary by version. Note the client version and the core name and version shown in the startup log rather than simply writing “V2Ray.” v2rayNG uses the Xray core, while v2flyNG uses the v2fly core, so don’t infer the error format from the app name alone.

How to read log levels and error chains

Common V2Ray/Xray loglevel values are debug, info, warning, error, and none. For troubleshooting, try info first and switch to debug if you need more detail. Setting the level to error filters out warnings and informational messages; with none, no output doesn’t prove the connection is working.

{
  "log": {
    "loglevel": "info"
  }
}

This is only the logging section of a core configuration, not a complete file you can replace your configuration with. When a client generates the configuration, change the relevant option in the UI whenever possible; edits to a generated file may be overwritten when you switch nodes. The access and error fields, as well as how the client starts the core, determine where access and error logs go. Raising the log level doesn’t guarantee that logs will be written to disk.

1. Check the time first. Note when you start a test or refresh a page, then look for entries from roughly 10 seconds before and after. This helps avoid mixing in requests from background apps.
2. Match related entries. If entries include a connection ID in square brackets, use it to link the lines. If not, compare the destination address, port, and timestamp.
3. Read from the outer layer inward. failed to process outbound traffic is usually a high-level summary; a later message such as connection refused or lookup ... is more likely to point to the direct cause.
4. Find the first error. A failed startup can cause every subsequent test to time out. Fix startup errors before diagnosing failed requests.

This flow helps identify which layer to check; not every protocol follows exactly the same sequence. For example, a server address that is already an IP doesn’t need to be resolved first, and routing rules may trigger separate DNS lookups. Use the current configuration and logs to guide your diagnosis.

Connection timeouts, refused connections, and DNS failures

A “timeout” means an operation took longer than allowed, but doesn’t tell you whether the problem was local DNS, the remote port, or a handshake response. First identify the destination in the error: it could be the proxy server, a direct-connection website, or a subscription server. Don’t change all your DNS and routing rules just because you see a timeout.

Check DNS resolution and the port separately on Windows

These commands use reserved example domains to demonstrate the checks. Before running them, replace the domain and port with the current node’s actual server address and port. Don’t enter the website you want to visit or the TLS serverName unless it happens to be the server address.

Resolve-DnsName server.example.com
Test-NetConnection server.example.com -Port 443

• Resolve-DnsName checks the system’s DNS resolution path; its result may differ from the core’s built-in DNS. If the system can resolve the name but the core can’t, check the core’s DNS servers and routing.
• TcpTestSucceeded : True only confirms that this TCP connection succeeded. It doesn’t verify the UUID, TLS, WebSocket path, or remote forwarding.
• A failed TCP test doesn’t tell you whether a UDP-based transport is working. First confirm the transport in use, then choose an appropriate diagnostic method.

TLS handshake failures and clock skew

A handshake failure means the connection stopped during security negotiation or protocol initialization, but certificates aren’t always to blame. Once TCP is reachable, check the security type, server name, certificate, transport settings, and authentication fields in that order. VLESS UUID validation and TLS certificate verification happen at different layers; fixing the certificate name doesn’t mean the UUID is correct.

Sync the clock before checking node settings

1. On Windows, go to Settings → Time & language → Date & time, enable automatic time setting, and sync. Run w32tm /query /status to check the time service status; an error may simply mean the service isn’t running yet.
2. On Android, open Settings, search for “Date & time,” and enable automatic time setting. Check the actual date and time; changing only the displayed time zone won’t correct the system clock.
3. With VMess, a clock difference between the client and server can cause authentication to fail. Sync both clocks; don’t just change the time zone displayed on your phone. VLESS doesn’t use the same VMess time-based authentication, but TLS still requires the correct time to verify certificates.
4. Compare the server address, port, UUID, security type, serverName, WebSocket path and Host, or gRPC serviceName, one by one. Use only the values supplied by the server; don’t troubleshoot by changing fields at random.

Port conflicts: get the core running first

If the log contains bind, address already in use, or Windows’ Only one usage of each socket address, start by checking the local listening address. If the local inbound fails to start, the browser has nowhere to connect even if the system proxy is enabled. This is separate from whether the remote server’s port is open.

For example, if the log says binding to 127.0.0.1:10808 failed, use PowerShell to find the listening process. If the reported port is different, change the port in the command as well.

Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 1234

In the second command, 1234 is an example process ID. Replace it with the OwningProcess value from the first command’s results. If no entry appears, check whether the log refers to a UDP listener, whether the process has already exited, or whether the error is from an earlier startup.

1. If the listener is a duplicate client instance, exit the extra instances normally from the system tray, then start one instance and test again.
2. If another program that you need is listening on the port, change the local listening port in the client’s parameter settings. Update any apps using a manual proxy to use the new port too.
3. Restart the core after making changes. Confirm that the startup log looks normal, then test a web page. Don’t terminate system processes you don’t recognize.
4. An error such as permission denied or access permissions may also involve reserved system ports or security policies. Don’t assume it’s always a duplicate process, and don’t rely on running as administrator indefinitely to hide the cause.

How to create a reproducible troubleshooting record

If you switch nodes, change DNS, enable TUN, and adjust routing all at once, even a successful connection won’t tell you which change worked. A better approach is to stick with one destination, one node, and one connection method, and match each test to the corresponding log timestamps. The steps below apply to similar issues on both desktop and Android.

1. Record the baseline: Note the client and core versions, current network, proxy connection method, and destination. Pause unnecessary background downloads.
2. Check startup: Restart the connection and first address startup errors such as configuration parsing failures, listener failures, and missing resources.
3. Send a single request: Note the time, refresh one page once, and keep the logs from about 10 seconds before and after the request.
4. Find the deepest error: Identify whether the issue is local listening, DNS resolution, remote dialing, TLS, or protocol authentication, then run the relevant checks.
5. Change one thing: For example, correct only the system time or the incorrect port. Retest the same destination and compare whether the specific error disappears or moves to the next stage.
6. Restore the log settings: When finished troubleshooting, exit debug mode and note what fixed the issue. Before sharing logs, remove UUIDs, subscription tokens, full subscription URLs, and personal browsing records. Keep module names and the structure of the error chain.

For more on outbound tags and routing rules, see Configuration Field Reference. If the log shows a request using a direct outbound, check the routing match; don’t mistake a failed direct connection for a failure to connect to the proxy server.

Common questions: what logs can’t tell you on their own