V2Ray Core Won’t Start? Diagnose Config Errors in v2rayN Logs

1. Tell a Core Startup Failure from a Connection Failure

v2rayN is the client interface; V2Ray and Xray are the cores that parse configs, open listeners, and handle proxy traffic. Seeing servers in the interface only means the client has loaded its own data. If the core exits, the local proxy endpoint may disappear too. Changing system proxy settings or repeatedly testing latency won’t fix an error that occurs during startup.

Check the most recent startup entry in the log area at the bottom of the main window. If the log panel is collapsed, expand it first; panel names can vary by version. Note the startup time, core name and version, first error, and exit message. Keep the full lines containing failed, error, file paths, or port numbers—not just the final “startup failed” message.

This sequence helps identify the failure stage; it doesn’t mean every core follows exactly the same internal order. Errors reading the config, loading rule files, or binding a listener should be resolved before investigating remote connectivity. If the core keeps running and the port is listening, but requests fail with i/o timeout or a handshake error, check the server address, network, transport, or security settings instead.

• Exits immediately: Start at the startup entry and find the first specific error. Common clues include a port, field name, or missing file.
• Core runs, but websites won’t load: First confirm the app is using the local proxy, then check outbound errors in the request log.
• Only TUN fails to start: Turn off TUN and test the regular proxy first. This separates virtual adapter permission issues from config parsing errors.

2. Port Conflicts: Find the Process Before Changing the Listener

Port conflicts often occur when an old core is still running, the client is open more than once, or another local service uses the same listening port. We’ll use 127.0.0.1:10808 as an example; these numbers may not match your installation. Check the actual local listening port under Settings → Parameter Settings, then substitute it in the commands.

Run the following query in Windows PowerShell. OwningProcess is the process ID; the second command shows its name and, if accessible, its path. If the first command returns nothing, it only means no matching TCP listener was found at that moment—it doesn’t rule out a UDP conflict or a reserved port.

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

Get-NetTCPConnection -LocalPort 10808 -State Listen -ErrorAction SilentlyContinue |
  ForEach-Object { Get-Process -Id $_.OwningProcess } |
  Select-Object Id, ProcessName, Path

Get-NetUDPEndpoint -LocalPort 10808 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess

3. JSON Errors: Separate Invalid Syntax from Unsupported Fields

If a custom config causes an immediate startup failure, first check whether the JSON parses, then confirm the core supports its fields. Syntax errors include trailing commas, missing quotes, and unmatched brackets. Compatibility errors can occur even in perfectly valid JSON. Handle these issues in order; don’t assume every config error means the subscription is invalid.

Strict JSON doesn’t allow a trailing comma after the last item in an object. The example below is a valid syntax snippet, not a complete core config. To check a custom file, use a local editor so you don’t have to upload a file containing server credentials to an online formatter.

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

1. Back up the original custom config and keep the path and line and column details from the error. Some errors provide only a character position, so check the surrounding text too.
2. For a regular server entry, v2rayN builds the config from its settings. Go back to the server editor and fix the relevant fields; don’t just edit the temporary runtime file.
3. For a complete custom config, fix the original file and reload it. Restart once, then review only that startup’s log.
4. If startup still fails after the syntax is valid, check the protocol, transport, security settings, and rule files. A config that parses isn’t necessarily runnable.

4. Unknown Protocols and Fields: Check Which Core Actually Starts

The v2rayN, V2Ray, and Xray versions are separate things. Updating the client interface doesn’t update every core file it uses, and having a newer core on disk doesn’t mean it was selected for this startup. Check the core name and version in the startup log, then confirm it supports the features the server requires. Use the reported version; don’t infer it from the installer’s name.

In particular, distinguish the VLESS protocol from REALITY security settings: they are separate options. A core that supports VLESS doesn’t necessarily support every transport and security feature in a given config. Keep the server’s requirements intact and choose a compatible core. Removing security fields at random may turn a startup error into a handshake failure.

5. Missing Rule Files: Check the Path, File Type, and Permissions

A missing or unreadable external resource referenced by routing rules can also prevent startup. V2Ray and Xray configs commonly use geoip.dat and geosite.dat for IP and domain categorization. Other cores may use different rule formats, so don’t mix them by simply renaming file extensions. Use the actual path and resource type shown in the error.

• Check the installation first: Moving only the launcher may leave the core and resource files behind. Restore the required folder structure, then try again.
• Check relative paths next: Relative paths in a custom config depend on the runtime environment and may not be relative to the config file. Try a known-existing absolute path to narrow down the issue.
• Check security software logs: See whether a file was quarantined. Verify its source and the action history; don’t disable all protection outright.
• Finally, verify the routing rule: If the file is readable but the category doesn’t exist, restore a backed-up rule or use a category that’s actually in the resource. Don’t switch everything to direct routing at random.

6. Change One Thing at a Time; Verify the Listener and Requests

Save the current config and logs before troubleshooting, then change one thing at a time. A useful order is port binding, JSON syntax, protocol fields, and rule files. But if the log clearly identifies a missing file, fix that directly rather than mechanically going through every step. Keep a record of each change and its result; otherwise, updating the subscription, switching cores, and changing routing at once makes it hard to identify the cause.

1. Start with the basics: Turn off TUN and temporarily disable custom rules you don’t need. Select one fully configured server and keep the regular local proxy listener enabled.
2. Restart once: Read the log from this startup’s timestamp and confirm the core doesn’t exit immediately. Note the actual core name and version.
3. Check the local listener: Use the command above to check the actual port and confirm it belongs to the core from this run, not another client instance.
4. Send a request explicitly through the proxy: If the port provides SOCKS, use the command below to test it. Then check the request log to see whether the failure is at DNS resolution, connection, or handshake.
5. Restore features one at a time: Re-enable routing rules first, then TUN. Check the log after each change to pinpoint where the failure returns.

curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --head https://example.com/

This Windows example sets a 10-second connection timeout and a 20-second total timeout. Replace the SOCKS port with the one you actually use. socks5h sends the destination hostname to the proxy for resolution; if your local listener only supports HTTP proxying, use the appropriate proxy type instead. An HTTP response confirms that this request received a response, not that every site is reachable. A request timeout alone doesn’t mean the core failed to start.

7. Common Questions About Log Troubleshooting