v2rayN Local Port in Use: Find and Fix a Conflict on Port 10808

Identify the error: a failed local listener doesn’t mean the server is down

Open the v2rayN main window and check the log area at the bottom. Look for lines containing listen, bind, and a local address. If the failure is at 127.0.0.1:10808, the core could not open that local endpoint. The browser has not yet sent a request to the core, so switching VMess or VLESS servers or repeatedly updating your subscription won’t free the local port.

This guide uses the mixed listener settings in v2rayN 7.x on Windows 10 and Windows 11, with the Chinese interface as an example. Menu groups may differ between minor versions, so follow the field names shown in your version. Older configurations may have separate SOCKS and HTTP ports; 10808 and 10809 aren’t a fixed pair across all versions.

Find the process and executable using port 10808

First, run this command in PowerShell. It only checks TCP listeners and won’t stop any programs. No results means no TCP listener was found on this port at the time of the query. If you get a result, note the OwningProcess value and check whether the local address is a loopback or wildcard address.

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

Suppose the query returns PID 6420. Run this command to check the process name, path, and command line. The number 6420 is just an example—replace it with the PID you found on your machine. If you can’t see the path with your current permissions, rerun the query in an elevated PowerShell window; don’t run the client as an administrator just for this reason.

Get-Process -Id 6420 | Select-Object Id, ProcessName, Path
Get-CimInstance Win32_Process -Filter "ProcessId = 6420" |
  Select-Object ProcessId, ExecutablePath, CommandLine

You can also run this query in Command Prompt. findstr only filters the output, so check that the local address column shows port 10808 and the state is LISTENING. Don’t mistake a remote port or an established connection for a listening conflict.

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

• Another v2rayN folder appears in the results: You may have started both an older extracted copy and a newer one. Check the two windows and their tray icons, then keep the one you want to use.
• An Xray or V2Ray core process appears in the results: Check its command line and configuration path to identify which client it belongs to. The core launched by the current v2rayN instance normally uses a port, so seeing a core process doesn’t necessarily mean anything is wrong.
• Another application appears in the results: Keep it running if it provides a service you need, and change v2rayN’s local endpoint instead. Don’t end a process based on its port number alone.
• The address is 0.0.0.0 or :: This is a wildcard listener and may also cover the loopback address for that address family. Don’t look only for entries showing 127.0.0.1.

Close the old instance or change the local mixed listener port

First, determine whether this is a duplicate launch or whether you really need both instances running. If the process is an obsolete instance, choose “Exit” from its tray menu and wait a few seconds before checking again. Closing the main window may only minimize it to the tray and leave the listener running.

1. Note your current settings

   In “Settings” → “Parameter Settings,” note the current listening port, listening address, and LAN connection option. Keep 10808 as a reference in case you need to revert. Don’t change the server port in the node editor.

2. Check the new port

   Use the PowerShell command above to check port 10818, replacing -LocalPort 10808 with -LocalPort 10818. Once there are no listener results, check the excluded port ranges as described below. 10818 is only an example; it may not be free on every machine.

3. Change the listening port

   Go to “Settings” → “Parameter Settings” → “Core: Basic Settings,” then find “Local mixed listening port” and change 10808 to 10818. If your version has separate SOCKS and HTTP fields, note and set each one separately, then use the appropriate port for each protocol in the steps below.

4. Save and reload

   Click “OK” and watch the logs as the core reloads. If prompted to restart, exit v2rayN completely and reopen it. Check that no new bind errors appear, then confirm that port 10818 is listening.

5. Verify the endpoint

   Confirm that the PID listening on the new port belongs to the client folder you’re using. For local use, keep the listener bound to loopback. Don’t enable “Allow connections from the LAN” just to fix a conflict; listening on more interfaces won’t resolve it.

Update the system proxy, browser, and command-line settings

A local mixed port can accept both HTTP and SOCKS requests through the same endpoint, but it won’t update every application’s separate proxy settings. After changing the port to 10818, a browser extension or terminal still pointed at 10808 can cause a second problem: the core is running, but pages still won’t load.

1. Refresh the system proxy: In the “System Proxy” menu at the bottom of the v2rayN main window, select “Clear System Proxy,” then “Set system proxy.” This refreshes the local endpoint, but it doesn’t mean every program will use the system proxy settings.
2. Check Windows settings: Go to Windows “Settings” → “Network & Internet” → “Proxy.” If you use a manual proxy, check the address and port. If you use a setup script, make sure an old script address isn’t still configured. Don’t mix settings from two different configurations.
3. Check browser extensions: If an extension manages your proxy, change its HTTP or SOCKS endpoint to 127.0.0.1:10818, or temporarily switch to the system proxy for testing. An extension still set to the old port will override the system settings.
4. Check terminal variables: Make sure HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY don’t still point to port 10808. Also check any proxy configuration files used by individual apps.

The commands below change only the current PowerShell session; they don’t set permanent environment variables. With the mixed listener enabled, use the HTTP endpoint for these two variables. HTTPS_PROXY is the variable used for HTTPS requests; the proxy URL itself doesn’t have to start with https://.

$env:HTTP_PROXY = "http://127.0.0.1:10818"
$env:HTTPS_PROXY = "http://127.0.0.1:10818"
Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue

If an application uses SOCKS, you can switch it to socks5h://127.0.0.1:10818 if supported. Don’t assume every command-line program supports the same variables. If you previously set permanent variables in Windows, update those saved values and open a new terminal.

No listener found? Check excluded ports and listener settings

If the logs show a permissions-related bind error but the listener query returns nothing, check Windows excluded port ranges. Virtualization and network services may make some ports unavailable for ordinary binds; an empty listener table doesn’t guarantee a port is available.

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

• The port is in an excluded range: Choose a port outside that range with no listener, then change it in “Parameter Settings.” Don’t delete system-reserved ranges just to keep port 10808.
• The conflict happens only at startup: Check “Startup apps” in Task Manager and Task Scheduler for two v2rayN instances configured to start automatically. The old process may have already exited by the time you query it, so check again immediately after the error appears.
• The log shows a different port: Troubleshoot the port shown in the log. A custom configuration may have multiple inbounds, so changing the mixed port won’t resolve a conflict on another inbound.
• The log specifically mentions UDP: Check UDP endpoints separately with Get-NetUDPEndpoint -LocalPort 10808. TCP and UDP are separate protocol spaces; a TCP query can’t tell you the UDP status.

Don’t change the remote server port to work around a local bind failure. The server port is for outbound connections; the local mixed port is an inbound listener. They don’t need to match. Don’t reset the entire network or reinstall the client as a first step either: those changes broaden the scope without necessarily affecting the process using the port.

Verify in two steps: check the listener, then test a request

After changing the port, first confirm that 10818 is listening, then test a request with the proxy explicitly specified. This separates “the core didn’t start,” “the app still uses the old port,” and “the remote connection failed.” Don’t rely on the tray icon alone to decide whether the issue is fixed.

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

curl.exe --noproxy "" --proxy http://127.0.0.1:10818 --connect-timeout 5 --max-time 15 -I https://example.com/

This example uses curl.exe to avoid older versions of Windows PowerShell treating curl as a different command. --noproxy "" prevents an existing bypass list from skipping this proxy test. The 5-second value is the connection timeout; 15 seconds is the timeout for the whole request. These are test settings, not measured latency. The example site is only for checking the request path—also test the actual destination you need to reach.

• Connection refused immediately: Recheck the listening port and core logs. You haven’t reached the stage of troubleshooting the remote server yet.
• The connection times out or resets: Check the routing result, server connection, and destination site in the core logs. Not every failure is a port conflict.
• You get HTTP response headers: The request received a response through the specified local endpoint. Even a 403 response is different from a failed connection to the local port.
• The command works but the browser doesn’t: Check browser extensions, separate proxy settings, and the state of any existing browser windows. To confirm that traffic went through the proxy, also check the routing result in the logs; a response alone doesn’t prove it.

Common questions: What else should you check after changing the port?

Before you finish, note three things: the final listening port, the path of the process using it, and which applications have their own proxy settings. After an upgrade or folder move, check these first to quickly determine whether the issue is with the local endpoint or a later step in the connection.