This guide is for cases where v2rayN opens but Xray exits shortly after launch. Save a complete startup log, then determine whether the problem occurs during config parsing, parameter construction, or port binding. Use the config test and local port checks to narrow it down. You’ll also learn why editing a generated config.json often doesn’t stick, and how to apply fixes to the node or custom config instead.
1. Confirm that the Xray core is the process exiting
v2rayN is the client interface; Xray is the core that runs the proxy configuration. Being able to use the main window doesn’t mean the core is running properly. Likewise, a browser failing to load a page doesn’t by itself mean the core failed to start. Follow this guide if selecting a node triggers a startup error, the core process exits soon after launch, or the log repeatedly stops while loading the config.
Open the log panel at the bottom of the main window, then select the current server again. Keep the complete output from before and after this action. Look for an error chain containing Failed to start, failed to load config files, or failed to listen. Multiple causes may be joined with >; the rightmost message is usually closest to the root cause. Don’t capture only the final “process exited” message.
-
Record the details
Note the v2rayN version, the Xray version shown in the log, the current node protocol, and when the error occurred. Before sharing logs, redact sensitive details such as subscription URLs, UUIDs, passwords, and server addresses.
-
Check the core
Go to “Settings” → “Parameter settings” and check the core configured for the current protocol. Use the Xray version shown in the startup log as the source of truth. Settings group names may vary between versions; don’t apply commands for a different core to this issue.
-
Save a copy of the config
Use the config path in the log to find the file that was actually loaded, then make a copy for troubleshooting. It may be named
config.jsonor have a different prefix. Follow the startup arguments rather than guessing from the filename. -
Reproduce the error once
Stop switching nodes repeatedly and reproduce the startup error once. Match that run’s log with the backed-up config so you don’t diagnose the current node using an error from the previous one.
2. Use the config test to separate parsing errors from runtime errors
Test the backup config with the same Xray executable that v2rayN actually runs. Config support can differ between core versions, so testing with an older executable may lead to misleading results. The following PowerShell commands are for Windows: open a terminal in the core’s directory, name the config copy config.json, then run the commands.
.\xray.exe version
.\xray.exe run -test -config ".\config.json"-test reads, builds, and tests the config without starting the full proxy service. It can catch JSON parsing errors, some missing required parameters, and invalid protocol settings, but it can’t replace an actual launch or check whether a remote account is valid. In particular, passing the test doesn’t guarantee the port will be available at runtime; check for port conflicts during startup.
| Log location or result | Check first | Next step |
|---|---|---|
| Failed to read config file | Startup arguments, file path, read permissions | Verify that you’re testing the file actually loaded according to the log |
| invalid character during parsing | Quotes, commas, brackets, and string escaping | Fix the syntax, then run the config test again |
| Failed while building outbound | protocol, settings, user parameters | Use the error chain to identify the specific outbound |
| Test passes, but startup fails while binding | Listen address, port conflict, or system restrictions | Check the local port and bind address |
| Core starts; errors occur only when connecting | Remote connectivity, TLS, DNS | Troubleshoot the connection instead of repeatedly changing JSON punctuation |
3. JSON syntax errors: fix punctuation before checking fields
When editing a custom config by hand, the most common problems are trailing or missing commas, curly quotation marks, and unescaped backslashes. Some loading methods allow comments, but use strict JSON when reproducing the issue to avoid parser differences. Don’t paste explanatory text, code fences, or line numbers from a web page into the file.
Error: invalid character '}' looking for beginning of object key string
Cause and fix: A common cause is a trailing comma after the last property in an object. Check the line before the closing brace, remove the extra comma, and test the config again.
Error: invalid character '"' after object key:value pair
Cause and fix: A comma may be missing between two properties. Check the end of the previous item near the reported location; don’t just change the highlighted quotation mark.
Error: unexpected EOF
Cause and fix: The file may be truncated, or an object, array, or string may be left unclosed. Compare the end of the file with a backup, then check that all brackets and braces are paired.
These are common parsing errors; the prefix around them varies by version and loader. A JSON parser usually points to where it can no longer continue, but the actual mistake may be on the previous line. The complete JSON snippet below has no trailing comma and can help you check quotation marks and separators. It’s a log config snippet, not a complete proxy config.
{
"log": {
"loglevel": "warning"
}
}- Use straight English double quotes for property names and string values, such as
"loglevel", not curly quotation marks. - Write Boolean values as
trueorfalse. Don’t convert every value to a string just to fix a syntax error. - Escape Windows paths inside JSON strings. For example:
"C:\\Temp\\xray-error.log". The directory must exist and be writable. - Check the config in a local editor. Avoid sending a complete file containing node credentials to an online formatter.
4. Port conflicts: find out what’s listening on 10808
If the error chain reaches listen tcp, check local listeners before importing the subscription again. The examples below use SOCKS port 10808, HTTP port 10809, and bind address 127.0.0.1. These aren’t the defaults for every version. Some configs use a mixed inbound that listens on just one port, so check your generated config.
Error: bind: address already in use
Cause and fix: Common on Linux, this means another process is already listening on the target address and port. Find the process, then close the duplicate client or change the inbound port.
Error: Only one usage of each socket address (protocol/network address/port) is normally permitted.
Cause and fix: This is a common Windows port binding conflict. Check for another core process still running, and make sure two inbounds aren’t trying to use the same address and port.
Use PowerShell to find the listener. The first command checks TCP listening status; the second shows the process identity. Use the PID returned by your own query—don’t copy someone else’s number.
Get-NetTCPConnection -State Listen -LocalPort 10808 -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-NetTCPConnection -State Listen -LocalPort 10808 -ErrorAction SilentlyContinue |
ForEach-Object { Get-Process -Id $_.OwningProcess }If two client instances are running, exit the extra one normally. Don’t terminate an unknown system process. To change the port, go to “Settings” → “Parameter settings” and find the local listen port option—for example, change 10808 to an unused port such as 10818. Save the change and reload the core. Update any apps where you manually specified the proxy port. If the client manages the system proxy, set it up again.
Bottom line: if the test passes but listening fails, check local resources first
Troubleshoot ports only when the actual error involves listening. If no TCP listener is found but you still get a permission error, check that the bind address belongs to this machine, as well as port reservations and security policies. Don’t assume every binding error means the node is invalid.
5. Field names and protocol parameters: valid syntax doesn’t guarantee a valid config
A successful JSON parse only means the text structure is basically valid. Xray then uses protocol to build the inbound and outbound and checks the fields required by that protocol. For example, vles instead of vless is still a valid string, but it doesn’t identify a configured protocol. Some unknown fields may also be ignored, so “no error” doesn’t mean a field took effect.
Error: unknown config id: vles
Cause and fix: The protocol identifier is misspelled. Check the outbound’s protocol against the actual node protocol. Don’t try to work around this error by changing unrelated parameters.
Error: invalid UUID
Cause and fix: The user ID may be invalid; the surrounding error chain usually identifies the related protocol. Copy the ID again from the original node, check for spaces or non-ASCII punctuation, and make sure you haven’t entered a password in the UUID field.
| Check | What to verify | Common wrong fix |
|---|---|---|
| VMess / VLESS | Protocol, server port, and user ID match the original node | Change only protocol while keeping all settings from a different protocol |
| VLESS user parameters | Check encryption; none is common, and set flow to the value provided by the node | Copy the VMess user encryption field directly |
| Transport settings | The transport type in streamSettings must match its corresponding settings | Change the transport type but keep unrelated paths or service names |
| TLS / REALITY | Make sure security, serverName, and the corresponding security-layer parameters match | Mix fields from two security layers, or disable verification instead of fixing the config |
| Routing target | outboundTag should match the intended outbound tag | Assume any string automatically creates a proxy outbound |
An incorrect node address, port, UUID, or TLS domain may not prevent the core from starting; the problem may surface only on the first connection. Don’t switch protocols just to get a “startup successful” message—that turns the original config error into a connection error. For field structure and routing, check the config reference item by item.
6. Isolate the problem with a minimal config, then restore settings one by one
When a config is long or includes multiple inbounds and routing groups, use a minimal config copy to verify the parsing and build process. The example below has only a local SOCKS inbound and a direct outbound. It contains no remote node and can’t test a proxy connection. Save it as minimal.json; don’t overwrite the subscription or node config.
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10818,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": false
}
}
],
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
}
]
}.\xray.exe run -test -config ".\minimal.json"If this file passes the test but the original config doesn’t, restore the original config one section at a time: add the real proxy outbound first, then transport and security settings, and finally DNS and routing. Test after each addition; the first change that causes a failure is where to focus. Before running this minimal config, make sure port 10818 is available. All traffic will go direct, so don’t use it to judge whether the original node works.
- Change one variable at a time: Don’t switch nodes, change ports, and change cores all at once, or you won’t know what fixed the problem.
- Keep track of changes: Record the field names and why you changed them. Don’t include complete credentials in troubleshooting notes.
- Restore protections afterward: If you temporarily change the log level, restore it promptly. Access logs may contain destination domains and other sensitive information.
- Verify the actual connection last: Once the core is running reliably, check the system proxy, browser access, and expected egress route.
7. Common questions about config errors
Why does config.json break again after I switch nodes?
First check whether it’s a runtime config generated automatically by v2rayN. If so, edit the relevant node in the server list or fix the custom config source, then reload. Changes made only to a generated file may not persist.
Why does startup still fail when the config test passes?
Check the startup log for listen errors and query the actual inbound port. The test doesn’t verify remote connectivity or guarantee that a port will be available at runtime. Passing the test isn’t a complete connectivity check.
What if the log only says the process exited, with no specific error?
Keep the startup command and config path shown by the client, then test the config in a terminal using the same Xray executable. If there’s still no output, check the error file path in log and its read permissions to see whether errors are being written to a separate log.
Will reinstalling the client fix it?
Back up your nodes and subscription settings first, then identify which startup stage is failing. Reinstalling usually won’t fix a port used by another process, incorrect subscription parameters, or duplicate inbounds. Consider installing a compatible version only after confirming that the program files are damaged or the version is incompatible.
You’re done when you can explain and reproduce the fix—not just when the error window disappears. Confirm why the original config failed, which change made it pass, and whether it still works after restarting the client. For actual connectivity, follow the user guide to select a node and test the proxy. Config construction, successful listening, and remote connectivity are three separate results.