v2rayNG Core Startup Failed: Find Configuration Errors in the Logs

First, tell whether the core failed to start or started but couldn’t connect

v2rayNG is an Android client, and this guide focuses on logs from the Xray core it uses. Seeing a VPN icon after tapping Connect only indicates that Android has established the corresponding service state; it does not confirm that the node is working. Likewise, a webpage failing to load doesn’t necessarily mean the core failed to start. If the local listener is up and a timeout appears only when you first visit a site, investigate the connection to the remote server.

A single log entry may link several causes with >. “Startup failed” at the beginning describes the outcome; details about a character, port, or certificate later in the chain are more likely to point to the root cause. Keep the entire error chain, then work backward from the end to identify the specific item. Don’t rely on just the most prominent red line.

Capture a clean log, starting when you tap Connect

Keep your current node and custom configuration before collecting logs. Menu names and locations can vary slightly between v2rayNG versions. A common route is Logs in the menu at the top left of the main screen; set the log level under Settings. If you can’t find an option with the same name, follow the interface in your installed version rather than copying the Preferences steps from desktop v2rayN.

1. Record your setup

   In Android Settings → Apps → v2rayNG, note the client version from App info. Also record your Android version, node protocol, and whether you use a custom configuration. Include the core version if it appears in the logs.

2. Stop the connection

   Return to the v2rayNG main screen and tap the connection button to stop the service. Temporarily stop other VPN apps to avoid interference from Android switching VPN services.

3. Set the log level

   Go to Settings → Log level and select info. If that doesn’t provide enough detail, temporarily switch to debug. If you use a complete custom JSON configuration, also check log.loglevel in it.

4. Reproduce the issue once

   Open Logs and clear the old entries, then return to the main screen and connect once. If the service stays running, visit a webpage, then return to the logs and review entries from that time.

5. Keep the surrounding context

   Copy the complete log entries from before and after the first failure. Before sharing, redact subscription URLs, UUIDs, passwords, and server details, but keep field names, error order, and the relationships between references to the same address.

debug provides detailed output, info records routine activity, warning flags a potential issue, and error indicates that an operation failed. These levels don’t rate how good a node is. An error from one request doesn’t mean the whole core has stopped, and no visible errors may simply mean the log level is too high. When you’re done troubleshooting, restore the original level to avoid unnecessary logging.

JSON syntax errors: fix the format before checking the node

If a custom configuration fails right after import, start by checking for parsing errors. JSON property names and strings must use straight double quotes. Curly quotes, missing commas, and trailing commas can all cause errors. The examples use strict JSON for portability and troubleshooting; they don’t rely on any loader-specific support for comments.

In the snippet below, there’s an extra comma after "warning". The error may point to the closing brace on the next line rather than the comma itself, so check the line above the reported location.

{
  "log": {
    "loglevel": "warning",
  }
}

Here’s the corrected snippet. It shows only how to write log; it isn’t a complete, standalone configuration. Replace the corresponding object in the original file, and don’t overwrite its existing inbounds, outbounds, or routing rules.

{
  "log": {
    "loglevel": "warning"
  }
}

Port conflicts: check the local listener, not the server port

A bind error occurs while starting a local listener. That’s a different issue from failing to connect to a remote server. The numbers below are examples for troubleshooting, not defaults for every v2rayNG installation. Check the local ports shown in Settings and the actual error in your logs.

If the log specifically says that binding 127.0.0.1:10808 failed, try changing the local SOCKS port to an unused port such as 10818, then restart. Update any other apps that rely on that SOCKS port as well. Changing only the remote port on the node edit screen won’t free the local listener and may break a node setting that was already correct.

Field names and core support: valid JSON isn’t enough

A successful JSON parse only confirms that the format is valid; it doesn’t mean Xray accepts every value. For example, network in streamSettings must use a transport identifier supported by the core. WebSocket uses ws, not websocket. A protocol name shown in the client interface may also differ from the string used in the configuration.

• Check capitalization: Write streamSettings, serverName, and wsSettings exactly as specified. Don’t guess based on similar-looking spellings.
• Check field types: Write Boolean values as true or false, without quotes. Ports are usually numbers.
• Check the field’s location: Put the TLS serverName in the relevant tlsSettings; don’t move it to the top level of the outbound object.
• Check the parameter combination: VLESS and VMess are proxy protocols, WebSocket is a transport, and TLS is a security layer. Check each setting separately when importing; they aren’t interchangeable.

The example below shows the structure for WebSocket and TLS and is intended only to help verify field placement. The domain and path are examples; in practice, they must match the server settings. This object isn’t a complete outbound configuration.

{
  "streamSettings": {
    "network": "ws",
    "security": "tls",
    "tlsSettings": {
      "serverName": "example.com"
    },
    "wsSettings": {
      "path": "/tunnel",
      "headers": {
        "Host": "example.com"
      }
    }
  }
}

Keep in mind that unknown fields don’t always cause startup errors. Some loading processes ignore them, so the settings you intended to enable may have no effect. Conversely, a newer parameter may fail during configuration building if the core doesn’t support it. Before updating, note your client and core versions and keep the original configuration. After updating, test the original node first; don’t change the protocol and the entire routing setup at the same time.

Transport and certificate errors: usually after startup

If the core has already started a local listener and these errors appear only when you visit a webpage, stop looking for a JSON comma. First verify the node address and remote port, then check TLS, security, and transport settings. These are common error snippets; the full prefixes and surrounding text vary by core version.

TLS serverName is used for server-name-related handshakes and certificate verification; the WebSocket Host is used for HTTP requests. They may match, or differ depending on how the server is set up. Don’t disable certificate verification just to make the error disappear; that can hide a hostname or certificate configuration issue.

Retest after the fix: keep a record and avoid random changes

After making one change, stop the service, clear the old logs, and connect again. First confirm that the core keeps running, then make one webpage request and check for new errors from that request. If a subscription update regenerates the node, manual changes may be overwritten. Record why you made the change instead of just noting that it works now.

Keep a short troubleshooting record: client version, core details, the first complete error, the one change you made, and the retest result. If the same error comes back, you’ll be able to tell whether the original issue returned or the failure has moved to a new stage.