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

Check the logs first: a port conflict does not mean the node is faulty

A local listening port is the entry point apps use to connect to the proxy core; it is not the node’s server port. When a browser connects to 127.0.0.1:10808, the request first reaches the local core, which routes it directly or through a proxy based on the routing rules. If the core cannot bind to its local listener, changing subscriptions or switching to a VMess or VLESS node usually won’t help.

Open the log panel in the v2rayN main window and note the address, port, and error message on the failed line. 127.0.0.1:10808, 0.0.0.0:10808, and [::1]:10808 are not interchangeable: they refer to different listening addresses or address families. In particular, a process bound to all IPv4 addresses may conflict with one that is meant to bind only to the local loopback address.

Windows: Find the PID and executable path for a port

Run the following query in PowerShell. This example uses 10808 from the log; replace it with the port shown in your error. Filtering by local port and listening state is more accurate than searching every line for the same number.

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

OwningProcess is the process ID (PID). If the result is 6420, run the two commands below. This is only an example—replace it with the PID returned on your computer.

Get-Process -Id 6420 | Select-Object Id, ProcessName, Path

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

The executable path and command line help distinguish the core launched by the current v2rayN instance, an older copy in another extracted folder, and other apps. Some process details may require administrator privileges. If a regular query returns incomplete information, open the terminal as an administrator and try again. Don’t terminate a process just because its name matches.

If PowerShell returns no results

netstat -ano -p tcp | findstr :10808
tasklist /FI "PID eq 6420"

• In the netstat output, check the Local Address column to confirm the port is 10808 and the state is LISTENING.
• findstr only filters text. It may match a remote address or another port containing the same digits, so don’t assume every matching line means the local port is in use.
• TIME_WAIT does not mean a proxy process is still listening. Don’t use it as a reason to terminate processes in bulk.
• If the error specifically involves UDP, also check with Get-NetUDPEndpoint -LocalPort 10808. UDP queries don’t have a TCP listening-state field.

macOS: Check listeners and identify duplicate instances

Open Terminal and use the built-in lsof command to check TCP listening ports. The -nP options show addresses and ports in numeric form, making them easier to compare with the logs.

lsof -nP -iTCP:10808 -sTCP:LISTEN

In the results, COMMAND is the process name, PID is the process ID, and NAME shows the listening address. If a regular query returns nothing but you suspect a process running under another account, check again with sudo lsof -nP -iTCP:10808 -sTCP:LISTEN. A blank result doesn’t guarantee the port is free; also make sure the error came from the most recent startup attempt.

1. Once you have the PID, run ps -p 6420 -o pid,ppid,command, replacing the example PID with the actual one, to see the startup command and parent process.
2. If it belongs to another v2rayN instance, quit that instance from its menu bar or app menu, then start the instance you want to keep.
3. If another app you’re using owns the port, leave it running and choose a different local listening port for v2rayN.
4. Only consider terminating a process in Activity Monitor after confirming which app it belongs to and finding that a normal quit doesn’t work. Stopping a core may interrupt existing connections.

Change the listening port: example changing 10808 to 20808

If you need to keep the process using the port, changing the local listener is the more direct fix. The steps below follow the common v2rayN 7.x interface; menu group names can differ between versions and desktop or classic layouts. Use the Local Listening Port field in your version. First check whether 20808 is already in use, then update the setting. The example port is not guaranteed to be available on every computer.

1. Note your current settings

   Go to Settings → Parameter Settings and find the local listening options. Note the current port, whether a mixed listener is enabled, the listening address, and the LAN access option. Don’t change the remote server port in the node editor.

2. Check the new port

   On Windows, change the query to -LocalPort 20808. On macOS, use lsof -nP -iTCP:20808 -sTCP:LISTEN. If another process is using it, try a different number and check again.

3. Save the listening endpoint

   Go to Settings → Parameter Settings and change the relevant Local Listening Port to 20808. Save and restart the core if prompted. If the setting doesn’t reload after saving, quit v2rayN normally and reopen it.

4. Reconfigure the proxy

   In the System Proxy menu on the main window or tray menu, select Clear System Proxy first, then select Automatically Configure System Proxy. Apps with manually configured proxies also need to be updated separately; this step alone won’t change them.

5. Check the latest logs

   Check 20808 again to confirm the expected core is listening, then check the latest startup logs for bind errors. Changing the number alone won’t restore browser access if the core still fails to start.

Update proxy addresses so apps don’t keep using the old port

If you still see “connection refused” after changing the port, an app may still be connecting to the old endpoint. System proxy settings, browser extensions, and terminal environment variables are separate configuration sources. Fixing access in one app doesn’t mean every app has been updated.

The PowerShell example below applies only if the current listener supports HTTP proxying. It changes environment variables for the current terminal process only; it won’t update other open terminals or save the settings system-wide.

$env:HTTP_PROXY = "http://127.0.0.1:20808"
$env:HTTPS_PROXY = "http://127.0.0.1:20808"

Using http:// for HTTPS_PROXY is not a contradiction: it specifies how to connect to a local HTTP proxy, which typically accesses HTTPS destinations through a CONNECT tunnel. For a SOCKS endpoint, use a protocol supported by the specific tool. Don’t assume the tool will recognize it just because you changed the protocol name.

No process is using the port? Check excluded ranges and verify the results

On Windows, if you get a permissions-related bind error but the TCP listener query returns nothing, check the system’s excluded port ranges. Virtualization, containers, or network sharing components may use these reserved ranges; rely on the output from your own system to determine whether one is involved.

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

If the failed port falls within an excluded range, choose a port outside it with no listener. Don’t remove system reservations just to set up a proxy listener, and don’t treat running everything as an administrator as a general fix. If the port isn’t in an excluded range, check your security software’s logs and the core logs instead of disabling all protection first.

Verify at three levels

• Listener: Confirm the expected core process is listening on the new port. On Windows, use Test-NetConnection 127.0.0.1 -Port 20808 to check whether a TCP connection can be established. Success doesn’t mean the proxy protocol or remote connection is working.
• Proxy: If the listener supports HTTP, run the explicit proxy request below to rule out ambiguity in the system proxy settings. Use the second command for a SOCKS listener. Choose the command that matches your listener type.
• App: Once the explicit proxy request succeeds, try opening the same site in your browser. If the command works but the browser doesn’t, check the browser’s separate proxy settings, extensions, and any cached old port.

curl --proxy http://127.0.0.1:20808 --connect-timeout 5 --max-time 15 -I https://example.com/

curl --proxy socks5h://127.0.0.1:20808 --connect-timeout 5 --max-time 15 -I https://example.com/

In Windows PowerShell, use curl.exe instead of curl to avoid parameter parsing issues caused by an alias in some environments. The 5-second value is the connection timeout; 15 seconds is the overall request timeout. These are not measured performance results. Receiving an HTTP response means the request got a response, but it doesn’t prove the proxy node can reach the destination if routing rules sent that domain directly. Check the core logs to confirm the actual outbound route.

FAQ: Recurring conflicts after reboot and what changing the port affects