v2rayN Port Already in Use: Find the Conflicting Process and Change the Local Port

1. Check the logs to confirm the conflict is on a local port

Open the log panel in the v2rayN main window and restart the core. Keep the full error, including listen, bind, and the address and port. This guide uses 127.0.0.1:10808 as an example. If the log shows a different port, substitute it in the commands below. Don’t assume the default port is the one in use.

This error occurs at the local entry point that receives proxy requests, before a connection to a remote node begins. Changing the subscription, switching between VMess and VLESS, or changing the remote server port won’t free local port 10808. The local port and the node’s server port don’t need to match.

2. Find the process using port 10808 with PowerShell

Open Windows PowerShell and check for TCP listeners. The command below matches only the local port, so it won’t mistake a regular connection to remote port 10808 for a listening conflict. No matches means the output will be empty; it only indicates that no matching TCP listener was found at the time of the query.

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

Focus on LocalAddress and OwningProcess. 0.0.0.0 means the process is listening on all IPv4 addresses and may conflict with a listener on the same port at the loopback address. :: is the IPv6 wildcard address; account for dual-stack behavior as well. Don’t ignore a record just because the address isn’t 127.0.0.1.

# Assume the previous command returned OwningProcess 6240; replace it with the actual result
Get-Process -Id 6240 |
  Select-Object Id, ProcessName, Path

Get-CimInstance Win32_Process -Filter "ProcessId = 6240" |
  Select-Object ProcessId, ParentProcessId, ExecutablePath, CommandLine

6240 is an example PID, not a fixed process ID. If the path or command line is blank, rerun the query with administrator privileges. If the process is a core, check its parent process too: a running v2rayN normally uses the proxy port, so don’t assume it’s a problem based on the process name alone.

• Core running under the same v2rayN instance: Check whether the log entry is old and whether current requests work before taking action. Don’t terminate a working connection by mistake.
• Duplicate instance launched from another folder: Find its tray icon and exit the app normally. Closing the main window may only minimize it to the system tray.
• Another application: Leave its listener alone and change v2rayN’s local port instead to avoid disrupting an existing service.
• Unknown path or purpose: Check the file location and associated service in Task Manager first. Don’t terminate a process based on its PID alone.

3. No listener found? Check UDP and excluded port ranges

TCP and UDP are separate transport protocols. The same port number can be used by both, and a UDP record alone doesn’t prove there’s a TCP listener conflict. If the log specifically reports a UDP inbound bind failure, query UDP endpoints and use the returned PID to identify the process.

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

If the error says access is denied and neither TCP nor UDP shows a matching record, check Windows excluded port ranges. Virtualization, containers, and Windows networking components can affect these ranges. The command below only checks the configuration; it doesn’t change anything. Run it in an administrator terminal if needed.

netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp

• Check whether 10808 falls between the start and end ports in any listed range. Don’t look only for an exact match on a single line.
• If the port is in an excluded range, choose a new port outside it and check again for an existing listener.
• If the log points to UDP, replace protocol=tcp with protocol=udp in the query.
• Don’t delete excluded port ranges or disable security protections just to fix a local proxy issue. If access is still denied, check security software events and your organization’s device policies.

The process may also exit immediately after launch, leaving no listener by the time you run the query. Restart the core and check the latest logs and port records right away. One empty result doesn’t prove the port is permanently free, and it says nothing about whether the node is available.

4. Change the local listening port in the settings

This example changes 10808 to 10818. The new port is only an example; run the listener and excluded-range checks above before using it. Depending on the v2rayN version, the setting may be called “local mixed listening port” or SOCKS and HTTP ports may be listed separately. Follow the actual field labels and meanings in your app.

1. Note your current settings

   Write down the current local port, listening address, and system proxy status. If browser extensions, terminal environment variables, or developer tools refer to the old port, note those too.

2. Check the new port

   Replace 10808 with 10818 in the query. Confirm there’s no conflicting listener and that the new port isn’t in a relevant excluded range.

3. Change the inbound port

   Go to “Settings” → “Parameter Settings” → “Basic Settings” and find the local listening port field. For a mixed inbound, enter 10818. If SOCKS and HTTP are configured separately, set each field to a different port. Don’t bind two separate inbounds to the same TCP address and port.

4. Save and restart

   Click “OK” to save and reload the core configuration. If the core doesn’t restart automatically, exit v2rayN normally and reopen it. Check the startup log for any new bind errors.

5. Update proxy settings

   In “System Proxy” at the bottom of the main window, select “Clear system proxy” first, then “Auto-configure system proxy.” Update the old port in any manually configured proxy tools as well.

Some older configurations use 10808 for SOCKS and 10809 for HTTP. A mixed inbound can accept both types of proxy request on one port. Don’t assume the HTTP port is always one greater than the SOCKS port. With a custom configuration, the settings in the interface may not control its inbounds; check the configuration file actually loaded and the logs.

5. Verify proxy operation in three steps

First confirm that the current core is listening on the new port. Then use an explicit proxy setting from the command line, and finally check whether any apps still use the old port. This separates a core startup failure from a node connection problem or an app setting that wasn’t updated.

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

# Use only if 10818 is configured as an HTTP or mixed inbound
curl.exe --proxy http://127.0.0.1:10818 --connect-timeout 10 --max-time 20 -I https://www.microsoft.com/

The command explicitly calls curl.exe to avoid PowerShell environments that interpret curl as a different command. It tests a public HTTPS page; if that page is unreachable, use an HTTPS address you know is accessible. Don’t expose subscription links or node credentials in screenshots or logs.

If the port provides SOCKS only, use the command below. socks5h sends the destination hostname to the proxy to resolve. Choose the HTTP or SOCKS test according to the inbound type; not every configuration needs to support both.

curl.exe --proxy socks5h://127.0.0.1:10818 --connect-timeout 10 --max-time 20 -I https://www.microsoft.com/

6. Common questions about port conflicts and changing ports

When you’re done, keep a short record of the conflicting port, the path of the process using it, the new inbound type and port, and your test results. Check these details after updating the client or restoring its configuration; it’s often easier than repeatedly switching nodes.