How to Fix V2Ray Core Startup Failures: Find config.json Errors in Logs

First confirm the failure occurs during startup

A core startup failure is different from a node connection failure. During startup, V2Ray or Xray usually exits while reading config.json, creating an inbound listener, or initializing outbound settings. In a connection failure, the core remains running but the request times out, the handshake fails, or the server refuses the connection. The troubleshooting entry points differ, so a page that will not open is not enough to identify the cause.

After opening the log, scroll up to the first error or failed entry for this launch. Later messages such as “process exited” or “restart failed” are often only consequences; the actual cause is usually one to five lines earlier. For example, a configuration parser may report a character position before showing the core exit code, while a port conflict may show the listening address before reporting startup failure.

Using v2rayN 7.x as an example, open “Settings” → “Parameter settings” → “Core type” and confirm whether the current node uses Xray Core or v2fly Core, then return to the main window and open the log panel. After switching core types, restart once so the log contains only fresh entries from the active core, rather than mistaking an old configuration error for the current problem.

1. Stop the core

   Stop the core in the client, wait for the log to report that the process has ended, and confirm that the old process no longer holds the local listening port.

2. Clear the log

   Clear the log window or note the current time, then start the core only once to avoid filling the log with repeated errors from continuous retries.

3. Find the first error

   From the top of the fresh log, find the first entry containing failed, error, invalid, or unknown.

4. Capture the context

   Keep the three lines before and after the error, especially the configuration path, line and column numbers, listening port, and outbound tag.

5. Change one thing at a time

   Fix one issue at a time, save, and restart. If several fields are changed together, the next log cannot clearly show which change took effect.

JSON syntax errors: fix the structure using the line and column

config.json must follow standard JSON syntax. Use straight double quotes for keys and strings, square brackets for arrays, curly braces for objects, and commas between adjacent fields; do not leave a trailing comma after the final field. Curly quotes from an IME, missing quotation marks, and comments accidentally copied into the file can all make the core stop before it processes the protocol parameters.

The snippet below is missing a comma at the end of the port line, so the parser cannot continue when it reaches protocol on the next line. The line number in the log may point to where the problem was detected; the missing character may actually be on the preceding line.

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808
      "protocol": "socks"
    }
  ]
}

When fixing the file, do not focus only on the reported character. Starting at the indicated position, check the nearest set of curly braces, confirm that every object contains correctly separated key-value pairs, and verify from the beginning to the end that all brackets are balanced. If the editor supports JSON formatting, run it first; failure to format usually means the structure is still incomplete.

• Replace curly quotes with straight double quotes, especially around the server address, UUID, tags, and protocol names.
• Make sure numbers are not written as strings with units; for example, the port should be 10808, not 10808port.
• Make sure Boolean values use lowercase true or false, without quotation marks.
• Save the complete file before restarting the core; do not edit an unsaved copy shown only in a preview window.

Port conflicts: find the conflicting process or duplicate inbound

Once the JSON parses successfully, the core creates inbound listeners in sequence. Startup can stop at this stage if an old v2rayN process is still running, another local networking tool uses the same port, or two inbounds in config.json share the same address and port. The log usually contains keywords such as listen, bind, or address already in use.

A common test configuration uses 127.0.0.1:10808 for SOCKS and 127.0.0.1:10809 for HTTP. These values are not fixed across all client versions, so use the log and current parameter settings as the source of truth. If the log identifies port 10808 as the conflict, inspect only 10808; there is no need to change the remote server port.

On Windows, run the following commands in a terminal to find the process ID using 10808. If the last column shows 6420, use the second command to look up the process name. Do not terminate an arbitrary system process just because a port is occupied; first confirm that it is a leftover core instance.

netstat -ano | findstr :10808
tasklist /FI "PID eq 6420"

Conclusion: release the port before changing the number

Changing the port to 10810 while an old process remains only bypasses the conflict temporarily and leaves the system proxy pointing to the old port. End the leftover instance and confirm that the port is free first; change the inbound port and system proxy together only when another required program permanently occupies it.

Misspelled fields: distinguish nesting, core, and configuration format

A field can be spelled correctly yet placed at the wrong level, which also causes configuration loading to fail. For TLS server naming, for example, serverName belongs inside the relevant transport security settings, not arbitrarily at the outbound root. Other common mistakes include writing setting instead of settings, streamSetting instead of streamSettings, or using a single object where an array is required.

Another common source is mixing configuration fragments from different cores or versions. v2rayN can generate a configuration based on the node and core type, but Xray Core and v2fly Core do not support exactly the same protocols, flow-control values, or transport fields. A configuration that works in one core may fail to load unchanged after switching core types.

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": []
      },
      "streamSettings": {
        "security": "tls",
        "tlsSettings": {
          "serverName": "example.com"
        }
      }
    }
  ]
}

1. Confirm that the core selected under v2rayN “Settings” → “Parameter settings” → “Core type” matches the node protocol.
2. Check the actual configuration path shown in the log so you do not edit a backup file or a config.json in an old directory.
3. Reduce the complex configuration to one inbound and one outbound. After confirming that it starts, restore DNS, routing, and additional inbounds.
4. If the error comes from a subscription node, edit the node parameters in the client and regenerate the configuration instead of changing only the temporary runtime file.

Conclusion: moving an unknown field around is not a solution

First identify the active core type and configuration format, then verify which object owns the field. Repeatedly moving a field between levels may clear one error while creating a semantic error, leaving the core unable to connect even after it starts.

Missing protocol parameters: check each stage from inbound to outbound

Once JSON syntax and field nesting are correct, the core can validate protocol parameters. Common VMess issues include an invalid user ID; common VLESS issues include mismatched address, port, user ID, encryption value, or flow-control settings. With TLS, also verify the security type and server name. Missing parameters may not appear as “missing”; logs may instead report an unparseable user, invalid UUID, or unsupported flow value.

After importing a subscription, open the corresponding node editor in the client. Confirm that the server address has no surrounding spaces, the port is between 1 and 65535, the user ID is complete, and the protocol and transport types match. Do not treat the subscription URL as the node's server address, and do not enter the local port 10808 where the remote server port belongs.

The stage where the process stops determines what to inspect. If the log already shows that the local port is listening and only then reports a missing routing tag, there is no need to revisit the SOCKS inbound. If it exits while parsing the outbound user, DNS and routing have not started; prioritize the node's protocol parameters.

Minimal configuration: narrow down the error

When the log contains several configuration errors, the most effective approach is not to change every field at once, but to build a configuration that can start. Keep one local inbound and one outbound with confirmed complete parameters, and temporarily remove custom DNS, routing rules, additional inbounds, and complex transport options. Once the core stays running, restore each module one at a time.

After restoring each module, stop, start, and run a local connection test. For example, restore DNS first and check for name-resolution errors; then restore routing and confirm that every inboundTag and outboundTag referenced by the rules exists; restore additional listeners last. This turns a search through dozens of fields into a check of the single module just added.

1. Keep the inbound

   Keep one local inbound listening on 127.0.0.1 and use a currently available high-numbered port.

2. Keep the outbound

   Keep only one VMess or VLESS outbound with complete parameters, and remove backup nodes not involved in the test.

3. Pause routing

   Temporarily remove custom routing rules so references to deleted tags do not interfere with the startup check.

4. Retest startup

   Confirm that the log shows no configuration errors, the process runs for more than 3 seconds, and the local listening port remains present.

5. Restore one item at a time

   Restore DNS, routing, additional inbounds, and transport options in that order, adding only one module per test.

Verify startup success: logs, port, and connection must all pass

A configuration that no longer reports errors is only the first step. True startup success requires all three conditions: the core process does not exit immediately, the local inbound port is listening, and a test request from the client reaches the corresponding outbound. Seeing “configuration loaded” before the process exits does not count as recovery.

Watch the log for 3 to 10 seconds after startup. If runtime messages continue and there is no new failed to start, panic, or exit code, check the port next. On Windows, run netstat -ano | findstr :10808 again; it should show a listening entry associated with the current core process. Replace the number in the command if the client uses a different port.

Then run the client's built-in latency or connection test. If you see a TLS handshake error, a server timeout, or a refused connection, the startup issue is resolved and the failure has moved to the remote connection stage. Check the server address, network reachability, TLS serverName, transport method, and node validity instead of continuing to edit JSON brackets.

• Start it successfully twice in a row to rule out an intermittent leftover process.
• After stopping the client, the local listener disappears; after starting it again, the listener returns.
• The log no longer reports configuration line or column errors, unknown fields, or port binding failures.
• The system proxy points to the current local port rather than the old port.
• The fix remains after updating the subscription and regenerating the configuration.

Conclusion: verify startup and node availability separately

A continuously running process and a normally listening local port show that config.json has passed the startup stage. Any subsequent handshake or timeout should be investigated as a connection-path issue. Separate verification stages prevent you from repeatedly changing configuration structure that is already correct.

If the cause is still unclear, collect the first error from this launch, the three lines before and after it, the active core type, client version, and the configuration module involved. Before sharing logs, remove the server address, user ID, subscription URL, and other credentials, but keep the error type, field name, line and column position, and port number—the details needed to diagnose the configuration.