v2rayNG Core Won’t Start? Fix Config Errors Using the Logs

Open the logs first: distinguish startup failures from connection failures

Open the side menu from the top-left corner of the v2rayNG home screen and select “Logs.” Stop the service, clear the old logs, return to the home screen, select the failing node, and start it once. Then reopen “Logs” and save the complete record from that startup attempt. Menu locations can vary between versions; use the “Logs” item shown in your app. Don’t capture only the final “startup failed” line—the cause is often above it.

1. Back up the original config

   Note the node name and config type. Save a copy of any JSON you maintain manually. For subscription nodes, note the group they belong to so a later update doesn’t overwrite your temporary changes.

2. Record your environment

   Note the client version under “About” in the side menu. If the startup log shows the Xray version, save that too. The client version and core version are separate numbers.

3. Reproduce the issue once

   Stop the service and clear the logs, then start it once. If Android asks for VPN permission, grant it first so a canceled permission prompt isn’t mistaken for a config error.

4. Follow the error chain

   Read past failed to load config or failed to start. If the error has multiple layers, keep going until you find the specific field, port, or JSON parsing hint.

If the log has reached the stage where it accepts requests and only then shows connection refused, i/o timeout, or a certificate handshake error, the problem is usually with the connection—not core startup. Repeatedly changing JSON punctuation won’t fix an unreachable remote port or a certificate mismatch.

If one of the first three stages fails, focus on the config and ports covered here. If either of the last two fails, check routing, DNS, node reachability, and TLS. Log wording varies by Xray version; the examples below are common snippets, not exact full-line matches.

1. JSON syntax errors: check brackets and data types first

If a custom config won’t start right after you paste it, check the JSON first. Object keys and string values must use straight double quotes. Don’t leave a trailing comma after the last item in an object or array. To avoid parser differences while troubleshooting, use standard JSON with no comments.

This partial object illustrates JSON syntax; it is not a complete proxy config you can import. port is a number, listen is a string, and the last item has no trailing comma. When you find a type error, fix fields one by one instead of converting every number to a string.

{
  "listen": "127.0.0.1",
  "port": 10808,
  "protocol": "socks"
}

2. Misspelled fields: valid JSON doesn’t guarantee a valid config

Once the syntax is valid, check field names, nesting, and allowed values. The top level usually contains two arrays, inbounds and outbounds, not singular names. Transport settings go under streamSettings, and network must be set to a value supported by the core. Field-name capitalization matters.

• Wrong nesting: Putting streamSettings inside settings does not configure the transport layer for the current outbound.
• Invalid value: Use ws for the WebSocket network value, not an improvised abbreviation like websoket.
• Mixing up fields: Don’t copy parameter names from a share link and use them as JSON keys. For example, link parameters and TLS fields in the core config don’t necessarily have matching names.
• Version differences: New config fields may require a newer core. After updating the client, check which core version is actually running; the download date alone isn’t enough.

Also note that some unknown fields may be ignored instead of triggering a “misspelled field” error. So the absence of syntax errors doesn’t prove that a setting took effect. For a regular node, return to the home screen, open the node editor, and check the address, port, protocol, and transport settings one by one. Don’t convert the entire node to custom JSON just to fix one field.

3. Inbound listener conflicts: check the address and port

If the log shows bind: address already in use, the local listening endpoint is already occupied. This is a port conflict on your device, not a connection refused by the node server. Stop other proxy services first, then check whether your custom config declares the same listening address, port, and transport protocol more than once.

These numbers illustrate the troubleshooting process; they aren’t default values for every version. For a regular config, look for the local SOCKS port under “Settings” in the side menu. After changing it, stop and restart the service; the exact label may vary by version. For custom JSON, check listen and port in the actual inbounds entry. Don’t assume the general settings override a custom config.

0.0.0.0 means the listener binds to all interfaces, which may conflict with a specific IPv4 address using the same port. Whether two inbounds conflict also depends on TCP versus UDP and the address family—not just the port number. Don’t enable LAN access just to work around the issue; it makes your local proxy accessible to more devices.

4. Missing outbound parameters: check the required fields for the protocol

The outbound determines which server to connect to, which protocol to use, and how to authenticate. Common VMess and VLESS JSON outbounds define the server under settings.vnext and the user under users. Trojan typically uses settings.servers. Mixing fields from different protocols can make outbound creation fail, even when the JSON is valid.

The connection address, TLS server name, and WebSocket Host serve different purposes; don’t swap them just because they all look like domain names. With VLESS and REALITY, also check the public key, server name, and other parameters against the server configuration. Field names and support depend on the core version in use. Ask the configuration provider about missing values instead of copying them from another node.

Restart after each change and keep a record you can roll back

Change one type of issue at a time, then stop and restart the service and check the new logs. Fix syntax first, then fields and parameters, and finally confirm the listener starts successfully. If you change the port, DNS, protocol, and routing all at once, it’s hard to tell which fix worked—even if the connection comes back.

• Regular subscription node: Update the subscription group from its menu first, then check the imported result. If only one node fails, save its logs instead of deleting the entire group.
• Custom config: Keep copies from before and after the change, and note which fields you changed and when. Don’t overwrite your only working config file.
• Known-good node: Compare it on the same device. If it starts successfully, focus on the failing node instead of resetting all settings right away.
• Still won’t start: Share the client and core versions, the complete redacted error chain, the config source type, and your most recent change. A screenshot that only says “Unable to connect” isn’t enough to pinpoint a config error.

If the core has started but Android VPN hasn’t been established, check system permissions and other apps currently using a VPN. Android typically allows only one active VPN per user profile. Troubleshoot this as a system VPN issue; there’s no need to keep changing UUIDs or disable certificate verification.