What to Do When v2rayN Reports a Port Conflict: Find the Process and Change the Local Listening Port

When v2rayN starts a core, it needs to open a SOCKS, HTTP, or mixed proxy listener on a local address. If the planned port is already occupied by another process, the Xray or V2Ray core cannot bind to it. The nodes themselves may be working normally, but the system proxy cannot forward traffic because the local entry point never started.

First, confirm that the conflict is a local listening-port issue

A page failing to load does not necessarily mean a port is occupied. Node timeouts, expired subscriptions, a disabled system proxy, and DNS failures can look similar. The key evidence for a port conflict is in the v2rayN log: it usually shows the local address, port number, and a failed bind or listen operation together.

In the common v2rayN 7.11.3 setup, the local SOCKS entry uses 10808 and the HTTP entry uses 10809. Actual ports may differ after migrating an old configuration, changing settings, or using a different core. Use the values shown in the current logs and under “Settings” → “Parameter settings” rather than relying on defaults.

Use netstat to find the process using the port

After confirming the conflicting port, open Command Prompt without administrator privileges. Do not omit the colon in the command below; it helps prevent remote connection entries from being mistaken for local listeners.

netstat -ano | findstr :10808

A typical result looks like this. The final column, 18420, is the process PID, and LISTENING means that process is listening on local port 10808. Only a record containing LISTENING directly proves that the port already has a listener. ESTABLISHED means a connection is active, while TIME_WAIT is a brief state after a connection closes; neither state alone proves a port conflict.

TCP    127.0.0.1:10808    0.0.0.0:0    LISTENING    18420

Once you have the PID, look up the process name:

tasklist /FI "PID eq 18420"

1. If the result is another v2rayN.exe, check whether a second instance is running in the notification area, then exit the duplicate normally.
2. If it belongs to a browser, development proxy, or another local networking tool, first confirm whether the program still needs to use 10808.
3. If tasklist cannot find the process, it may have just exited. Run netstat again to check whether the PID has changed.
4. If the output includes both the IPv4 address 127.0.0.1 and the IPv6 address ::1, record both listeners so you do not miss the binding scope.

View listening processes with PowerShell

PowerShell can filter local ports directly and pass OwningProcess to Get-Process. If no process is listening on the port, the command reports that no object was found, which usually means the conflict has been cleared.

Get-NetTCPConnection -LocalPort 10808 -State Listen
Get-Process -Id (Get-NetTCPConnection -LocalPort 10808 -State Listen).OwningProcess

Do not force-terminate an unfamiliar process immediately. System services, development environments, and LAN debugging tools may legitimately listen on local ports. A safer approach is to identify what the program does, then decide whether to close it or move v2rayN to a new port.

Change the local listening port in v2rayN

If the other program needs to keep running, changing v2rayN’s port is usually the quickest solution. Open v2rayN and go to “Settings” → “Parameter settings,” then look for “Local listening port” or the corresponding core settings. Menu names may vary slightly across 7.x releases, but the port fields always show their current values.

1. Write down the original values—for example, SOCKS 10808 and HTTP 10809—so you can restore them if needed.
2. Change the main listening port to 10818. If the interface has a separate HTTP port, change it to 10819.
3. Keep the listening address set to 127.0.0.1 unless you specifically need to provide a proxy entry point to devices on your local network.
4. Save the settings, stop the current core, and then start the core again or restart v2rayN.
5. Return to the logs and confirm a successful listener entry for 127.0.0.1:10818, with no new bind errors.

Run the port query again after making the change. The expected result is that the LISTENING PID for 10818 belongs to the current core, while the old port 10808 is no longer occupied by it.

netstat -ano | findstr :10818
netstat -ano | findstr :10808

Update the system and browser proxy settings

The most common follow-up problem after changing a port is that the core starts normally but pages still fail to load. Usually the node is not at fault: the system or browser is still sending requests to the old port, 10808/10809. Since nothing is listening there anymore, requests fail immediately.

• Use v2rayN to configure the system proxy: Clear the system proxy once, then select “Automatically configure system proxy” or the system proxy mode you use so the client writes the new HTTP port.
• When the browser uses the system proxy: Close and reopen the browser, then confirm that the system proxy server has changed from 127.0.0.1:10809 to 127.0.0.1:10819.
• When the browser uses a manual SOCKS proxy: Keep the server set to 127.0.0.1, change the port from 10808 to 10818, and handle DNS according to your existing policy.
• When the terminal uses environment variables: Update the port in HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY so command-line tools do not continue connecting to the old entry point.
• When a development tool has its own proxy settings: Check the tool’s network settings. Some programs do not read the Windows system proxy and must be updated separately.

set HTTP_PROXY=http://127.0.0.1:10819
set HTTPS_PROXY=http://127.0.0.1:10819
set ALL_PROXY=socks5://127.0.0.1:10818

The set command above affects only the current Command Prompt window and is not retained after the window closes, making it suitable for temporary testing. During verification, first run netstat to confirm that the port is LISTENING, then make a network request that requires a proxy. If the connection log shows a new inbound entry, the request has reached v2rayN.

What to check if the error remains after changing the port

If 10818 also fails to listen, do not try a large number of random ports. First determine whether the new port is occupied by a process, falls within a Windows excluded range, or is being used by a duplicate v2rayN core. Each case requires a different fix.

Check the system’s excluded port range

Windows networking components may reserve a range of TCP ports. Even when netstat shows no listening process, a port in an excluded range can return a permission-related bind error. Run the following command in Command Prompt with administrator privileges:

netsh interface ipv4 show excludedportrange protocol=tcp

If the planned port 10818 falls within the displayed range, choose a new port outside it, such as 11808 and 11809. This is safer than changing the system’s reservation policy. You must still update the system proxy and browser settings afterward.

Check for duplicate cores and leftover processes

• Stop the core from the v2rayN main window, wait three seconds, then check ports 10808, 10809, 10818, and 10819.
• If a port is still LISTENING after stopping the core, record its PID and use tasklist to check for a leftover core process.
• Whenever possible, exit through the original client. Only end the process through Task Manager if it is unresponsive and you have verified the PID.
• After restarting v2rayN, keep only one main window open and watch the logs for duplicate instances of the same inbound.

Common questions and verification steps

A reusable troubleshooting sequence is: read the core log, find the port’s PID, identify what the process does, and then decide whether to close it or change the listening port. Afterward, update the system proxy, browser, and command-line environment variables together to avoid the secondary failure where the conflict is gone but applications still connect to the old port.