v2rayN Core Startup Errors: Fix JSON Syntax and Port Conflicts

When Claude Code cannot sign in, start a session, or complete a request, the cause may be simpler than a broken node: the terminal may not be using v2rayN at all. A browser can follow the Windows system proxy while PowerShell, Command Prompt, or another terminal-launched process ignores it. This guide shows how to check v2rayN’s local listener, pass its address to Claude Code through environment variables, and separate proxy, routing, and service-side problems.

1. Why terminal traffic can bypass v2rayN

v2rayN manages a local connection point and starts a proxy core such as Xray. Selecting a server and enabling the Windows system proxy does not guarantee that every program will use that connection. Browsers often read the operating system’s proxy settings, but command-line tools and the programs they start can use their own proxy options or environment variables instead.

Claude Code inherits much of its environment from the terminal that starts it. If that terminal has no usable proxy setting, Claude Code may attempt a direct connection even while a browser works. Conversely, a terminal can connect to v2rayN successfully while the core’s routing rules select a direct outbound, or while the remote node cannot reach the service. These are separate points in the connection path:

• Application to local listener: Does the terminal-launched process know the proxy address, and is a listener accepting connections there?
• Local routing: After v2rayN receives the request, does the active routing configuration send it to a proxy outbound rather than a direct outbound?
• Remote connection: Can the selected node resolve and reach the requested service, and does the service accept the request?

Changing the node before checking the first point can waste time. First confirm the listener and shell settings; then investigate routing and the remote connection. A successful browser test is useful, but it does not by itself verify that Claude Code uses the same path.

2. Check the v2rayN local listener

Open v2rayN and confirm that a server is selected and the core is running. In many layouts, listener options are under Settings → Parameter settings. Menu labels and available fields can vary by v2rayN version, so treat the active configuration and startup output as the source of truth. Look for the local HTTP, SOCKS, or mixed inbound address and port; do not assume that an example port is your actual port.

For the commands below, 127.0.0.1:10808 is only an example of a local HTTP-capable listener. Replace it with the address and port shown in your configuration. A SOCKS-only listener needs a SOCKS proxy URL for tests that support it. Do not enter the remote server’s address here: the terminal connects to the local listener, and v2rayN handles the remote connection.

Before configuring Claude Code, test the HTTP listener directly from PowerShell. Use curl.exe, not just curl: in some Windows PowerShell versions, the latter may be an alias for a different command. Substitute a real HTTPS destination you are authorized to access and your own listener address.

curl.exe -v --proxy http://127.0.0.1:10808 https://example.com/

A response from the destination means that this command reached an HTTP proxy at the specified local address and completed a request. It does not prove that Claude Code has inherited the same setting or that every service it contacts will succeed. If the connection is refused, check whether the core is running, the port is correct, and another process is not occupying or blocking the listener. If the request reaches the listener but times out, continue to routing and node checks.

3. Set proxy variables in the terminal that launches Claude Code

For a first test, set the variables for the current PowerShell window. This keeps the change limited to that shell and the child programs it starts. It also makes it easy to remove the setting when the test is finished. The values below use the example HTTP-capable listener; replace the port if yours differs.

$env:HTTP_PROXY = "http://127.0.0.1:10808"
$env:HTTPS_PROXY = "http://127.0.0.1:10808"
claude

Set both variables because programs commonly distinguish between ordinary HTTP requests and HTTPS requests. The proxy URL remains an HTTP URL even when the destination is HTTPS: the client asks the HTTP proxy to establish a CONNECT tunnel. Do not change the scheme to https:// unless your local listener itself is configured to accept TLS from the local client.

Run the Claude Code command from the same PowerShell window after setting the variables. A new terminal window will not inherit variables that were set only in the old one. Likewise, setting variables in PowerShell does not configure a separate Git Bash, Command Prompt, IDE terminal, or remote shell. Configure the environment in the shell that actually starts Claude Code, and restart the terminal or IDE after changing persistent environment settings.

To test the same environment with a basic HTTPS request, run:

curl.exe -v https://example.com/

This request uses the variables set in the current PowerShell session if the command-line program recognizes them. Compare it with the explicit --proxy test from the previous section. If the explicit test works but this one does not, the listener may be fine while environment-variable handling, spelling, or shell scope is wrong. If both work but Claude Code still fails, check that the command was launched from this same shell and inspect the application’s own output.

To remove the temporary variables from the current PowerShell window, run:

Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue

For Command Prompt, the equivalent session-only form is set HTTP_PROXY=http://127.0.0.1:10808 and set HTTPS_PROXY=http://127.0.0.1:10808, followed by launching Claude Code from that same window. Avoid using a machine-wide or user-wide change as the first diagnostic step: persistent variables can affect unrelated tools, and already-open applications will not necessarily see updated values. If you later choose persistent settings, record the previous values and remove or restore them deliberately.

4. Apply the setup in a controlled order

Change one layer at a time. This sequence helps distinguish a listener problem from an environment or routing problem, and prevents a successful browser session from being mistaken for a terminal test.

1. Start the core

   In v2rayN, select a working server and start the core. Confirm that startup completes without a local bind or configuration error.

2. Note the port

   Open the listener settings under Settings → Parameter settings, or inspect the active configuration. Record the local address, port, and whether the inbound accepts HTTP.

3. Test explicitly

   Run curl.exe -v --proxy http://127.0.0.1:10808 https://example.com/ with your actual listener. Resolve a refusal or timeout before changing Claude Code settings.

4. Set the shell

   Set HTTP_PROXY and HTTPS_PROXY in the terminal you will use, replacing the example port with your own.

5. Launch and observe

   Start Claude Code from that same terminal, reproduce one failed operation, and note its time and error text for comparison with v2rayN logs.

6. Undo test values

   When finished, remove temporary variables if you do not want other commands in that shell to use the proxy.

On a Unix-like shell, the session-scoped form is typically export HTTP_PROXY=http://127.0.0.1:10808 and export HTTPS_PROXY=http://127.0.0.1:10808, followed by launching the program from that shell. The listener must be reachable from that environment. If v2rayN is running on another machine or inside a different network namespace, 127.0.0.1 refers to the machine or namespace running the command, not automatically to the Windows host.

5. Check routing and connection logs

If the local proxy test reaches v2rayN but the destination request fails, determine what happened after the request entered the core. For a short diagnostic, select a routing mode that sends the test request through the proxy outbound, if that option is available in your v2rayN setup. Then repeat the same request. A change in result is evidence that routing selection matters; it is not a reason to leave all traffic in a broad mode permanently if your normal rules are more selective.

• No matching request in the logs: The command may not be reaching the listener, the selected inbound may not produce access records, or the log level may not show the information you need. Recheck the port and repeat one request while observing the log.
• A request appears with a direct outbound: Inspect the active routing mode and rule order. A rule matching earlier in the configuration can send traffic direct before a later rule is considered.
• A request uses the proxy outbound but fails: Check the node’s availability, DNS resolution, transport and security settings, and the exact error from the core. Changing shell variables will not repair a failed remote connection.
• The request succeeds but Claude Code fails: Confirm that Claude Code was launched after the variables were set, from the expected terminal, and review the application’s own diagnostic output. Different requests or authentication steps may have different outcomes.

Do not copy a list of service domains into custom routing rules without confirming the destinations used by your installed Claude Code version and account flow. Services can use more than one host, and routing data and application behavior can change. If you need a targeted rule, use the actual destination shown in a trustworthy diagnostic, make the rule narrow, and verify that it matches the intended outbound. Avoid editing generated runtime configuration directly; v2rayN may regenerate it when settings or servers change.

6. Common failure patterns and next checks

Use the symptom and the narrowest test that can confirm it. A terminal error alone rarely identifies which layer failed, so compare one reproducible request with the local proxy test and the corresponding v2rayN log entries.

When comparing logs, note the time of a single request and look for its destination and outbound selection. Several terminal and application requests can occur close together, so the last log line may belong to a different connection. Before sharing diagnostic output, remove subscription links, tokens, UUIDs, credentials, and private server addresses; retain the error type, relevant port, and non-sensitive configuration field names.

Once the connection works, keep the settings as narrow as your workflow requires. Session-only variables are a useful default for testing because they are easy to remove. If you use persistent variables, document which terminal and applications rely on them, and verify that local services or destinations that should bypass the proxy are handled intentionally rather than by an accidental broad bypass.