Troubleshooting Kernel Startup Failures: Find Configuration Errors from the First Log Line

When the client shows “Startup failed,” the node itself may still be valid. Graphical clients such as v2rayN and v2rayNG first convert the node, routing, and local listener settings into a kernel configuration, then launch the Xray or v2fly kernel. If configuration generation, a listening port, a certificate file, or any field structure is invalid, the kernel process exits before establishing a proxy connection.

The effective approach is not to keep switching nodes, but to find the first error from this startup attempt. The end of a log often contains wrapper messages such as “failed to start,” “app/proxyman,” or an exit code; the real cause usually appears earlier. Fix the earliest clear error, restart once, and read the new log to avoid being distracted by cascading failures.

Capture the complete log from this startup attempt

The log must correspond to the startup action you just performed. Old entries may contain errors that have already been fixed, and searching only for prominent red lines can lead you to troubleshoot the wrong issue. First stop the kernel, note the current time, and start it once more. Then read downward from the timestamp closest to startup; pause at the first entry containing error, failed, invalid, or cannot.

v2rayN desktop

1. Open the log panel at the bottom of the main window. If it is collapsed, expand the bottom information panel and switch to “Log”.
2. Go to “Settings” → “Parameter settings” → “Basic settings” and make sure logging has not been completely disabled. Use warning for routine troubleshooting; temporarily switch to info when you need to observe the configuration-loading process.
3. Click Stop service, wait about 2 seconds, then start the current configuration again. Copy the entries from the kernel version line through the process exit line.
4. If the main window shows both client and kernel logs, prioritize entries containing Xray, V2Ray, Core, or a configuration file path.

v2rayNG for Android

1. Disconnect the current connection, then open “Log” from the menu in the upper-right corner of the main screen.
2. Return to the main screen, select the target configuration, start it, and immediately go back to the log page.
3. Start with the latest kernel startup entry. If the content scrolls too quickly, stop the connection first, then copy the entries generated by the most recent startup.
4. When v2rayNG uses the Xray kernel, configuration validation, VLESS fields, and TLS errors are written directly by the kernel. The brief message at the top of the client only confirms the status and cannot replace the detailed log.

Port conflict: the kernel cannot create a local listener

After starting, the proxy kernel first creates a SOCKS, HTTP, or transparent-proxy listener on the local machine. A common v2rayN combination is 127.0.0.1:10808 and 127.0.0.1:10809. If an old kernel did not exit, another client is running, or another program is using the same port, the new process fails before it handles the remote node.

This issue is unrelated to server latency or VMess and VLESS parameters. If the error contains listen, bind, address, and a port number together, troubleshoot the local listener first. Do not keep switching nodes to test it: all nodes share the same local entry point, and switching nodes will not release the occupied port.

What to check after changing the port

• The system proxy is usually updated automatically by v2rayN, but manual proxy settings in browsers and download tools are not.
• If you change the SOCKS port from 10808 to 11808, also change the proxy address configured inside the application to 127.0.0.1:11808.
• The port must be between 1 and 65535, and the SOCKS, HTTP, API, and LAN listeners must not use duplicate ports.
• If the same error persists after changing the port, check the actual port shown in the log. The configuration may have been generated from a different configuration file, so the change has not reached the current kernel.

JSON syntax error: protocol validation has not started

V2Ray and Xray kernels typically read JSON configuration files. Graphical clients generate these files automatically, but importing a complete configuration, editing custom routing, merging fragments, or pasting advanced parameters can introduce missing commas, trailing commas, incorrect quotes, or unmatched brackets. A syntax-parsing failure means the kernel has not yet interpreted the details of VMess, VLESS, or routing rules.

Line and column numbers in the log provide the most direct location. For example, line 42 column 17 means the parser could not continue at line 42, column 17, though the actual mistake may be at the end of the previous line. Check both the reported position and the preceding line, especially commas between array elements and object fields.

{
  "inbounds": [
    {
      "port": 10808,
      "protocol": "socks"
    }
  ],
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {}
    }
  ]
}

Recommended recovery order

1. Back up the current custom configuration or routing rules; do not overwrite the only copy.
2. If the error appears in a configuration generated from a subscription node, delete that node, refresh the subscription, then select the node and start again.
3. If the error is in manually edited JSON, restore a minimal configuration that can start, then add routing, DNS, and transport settings one section at a time.
4. Start once after adding each section. This limits the problem to the latest change instead of requiring a review of the entire file.

Field spelling and version incompatibility: valid syntax, invalid structure

A JSON file can parse successfully without matching the current kernel's data structure. Misspelled or incorrectly capitalized fields, misplaced nesting, or fields generated by a newer client that an older kernel does not recognize can trigger unknown field, failed to build config, or invalid value during configuration loading. Braces and commas are usually fine; focus instead on field names, protocol combinations, and the kernel version.

For example, VLESS flow, the transport-layer network, and the TLS-related serverName each have a fixed location. The kernel will not guess when a field uses a similar name or an outbound field is placed inside transport settings. A subscription parser may also ignore newer parameters because it is outdated, resulting in an incomplete configuration.

Distinguish node, subscription, and global errors

Certificates and TLS: check paths, names, and system time separately

Certificate-related startup errors mainly occur while loading local certificate files or initializing TLS settings. When the client is the outbound connection side, most nodes do not require users to select certificate files manually. If the configuration contains certificateFile, keyFile, or a local absolute path, confirm that the file exists and that the current process can read it.

Another class of errors occurs after the connection is established, such as a certificate name mismatch or an invalid certificate validity period. These entries may not make the kernel exit immediately, but they can still make the target node connection fail. First distinguish “unable to read a file during startup” from “remote certificate verification failed during connection”; the fixes are different.

Three checks for certificate issues

• Check the time first: If the system date is off by several months, even a valid certificate may be considered not yet valid or already expired.
• Then check the name: The connection address can be an entry-point domain, but the TLS server name must match the server configuration and the certificate's covered names.
• Finally check the file: Check the file path only when the configuration explicitly uses a local certificate. A standard subscription node should not have certificate or private-key paths added without a reason.

Verify after fixing: make sure the old error has not become a new one

After fixing one issue, stop and restart the kernel completely. Merely switching nodes in the interface may leave the old process or generated configuration in use. The minimum signs of a successful startup are a listener-established or core-running message in the log, a process that does not exit immediately, an actively listening local port, and subsequent requests reaching the proxy outbound.

If the first error disappears but another one appears, the fix was not necessarily ineffective. Configuration loading is sequential: the parser checks the next stage only after passing the previous one. For example, fixing a JSON comma may reveal a field typo; freeing 10808 may expose a certificate-name error. Continue by classifying the new first error.

1. Stop the kernel, wait about 2 seconds, and clearly separate the new and old log periods.
2. Restart the same node without changing the port, protocol, routing, and DNS at the same time.
3. Confirm that the original keywords no longer appear in the log, such as bind, invalid character, unknown field, or x509.
4. Open a regular webpage, then check whether a new connection entry appears in the log.
5. After confirming that one node works, restore additional settings such as custom routing, TUN, or LAN listening.

A reusable troubleshooting record

Client: v2rayN
Kernel: Xray
Time: 2026-07-31 14:26
Scope: All nodes
First error: failed to listen TCP on 127.0.0.1:10808
Change made: SOCKS port changed to 11808
Retest result: Kernel remained running; local listener established

Recording the client, kernel, time, failure scope, first error, and one change helps avoid repeated work. When a similar issue occurs, compare the keywords and failure scope first instead of reinstalling or resetting the entire configuration. The key to log-based troubleshooting is identifying the stage where the error occurred and testing only one variable per round.