v2rayN Local Port Already in Use: Find the 10808 Conflict and Change the Listening Port

First, Confirm the Local Listener Is Failing

v2rayN is a desktop client; the proxy core it launches creates the local listener. Your browser connects to the local proxy endpoint first, then the core forwards traffic according to its routing rules. If the endpoint cannot bind to its port, the request never reaches the remote connection stage. Reimporting subscriptions or switching between VMess and VLESS configurations usually will not resolve the conflict.

Open the log panel on the v2rayN main window and note the protocol, listening address, and port in the error line. Both errors below indicate a bind failure, though the wording varies by operating system and core. The log may also include a timestamp, inbound name, or other context.

Windows: Find the Process Listening on a Port

Run the following command in PowerShell or Command Prompt. The netstat results may include both local and remote addresses, so check the full line: the local address must show the target port, the state must be LISTENING, and the last column is the listener's PID. Don't mistake a connection with 10808 in its remote address for the process using the local port.

netstat -ano -p tcp | findstr ":10808"
netstat -ano -p tcp | findstr ":10809"

If there's too much output, use PowerShell to filter by local port and listening state. The second command passes the matching PID to Get-Process and displays the process name.

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

Get-NetTCPConnection -State Listen -LocalPort 10808,10809 -ErrorAction SilentlyContinue |
  Select-Object -ExpandProperty OwningProcess -Unique |
  ForEach-Object { Get-Process -Id $_ }

1. Exit v2rayN first. Use Exit in the tray menu; closing the main window doesn't necessarily quit the app. Then check the port again.
2. If the listener disappears: It likely belonged to the current instance. Start just one v2rayN instance again and see if the issue returns. You don't need to terminate the core process directly.
3. If the listener is still there: In Task Manager, open the Details tab and find the process by PID. Check its executable path and command line. If needed, enable those columns from the column selector.
4. Identify the owning app before taking action. You can exit a duplicate v2rayN instance normally. Don't force-quit another service you need to keep; changing the current client's port is the better option.

A core process name alone doesn't prove that it's a leftover process: another active instance may have launched the same core. Check the file path, parent process, and running client first. If you don't have permission to query the process path, reopen the terminal with administrator privileges and try again. Don't treat running the client as administrator as a standard fix for port conflicts.

macOS and Linux: Find the Listener with lsof

Run the command below in a terminal. -nP keeps addresses and ports numeric to avoid name resolution; -sTCP:LISTEN shows TCP listeners only. The COMMAND, PID, and NAME columns help identify the process name, process ID, and listening address.

lsof -nP -iTCP:10808 -sTCP:LISTEN
lsof -nP -iTCP:10809 -sTCP:LISTEN

• If you can't see the expected process as a regular user, rerun the query with sudo lsof if you have permission.
• If Linux reports that lsof isn't installed, use sudo ss -ltnp 'sport = :10808' to inspect listeners and process information.
• First, exit normally from the owning app. If it's a background service, stop it using that service's management tools. Don't force-kill an unfamiliar PID.
• Check the same port again after taking action. If the listener immediately returns, check startup items, background services, or another client instance instead of repeatedly killing the process.

Change v2rayN's Local Listening Port

If the process using the port needs to stay, change the port in v2rayN. Note the current port and system proxy settings first so you can revert if needed. Depending on the interface, the field may be called Local mixed listening port, or SOCKS and HTTP ports may be listed separately. Change the fields that are actually present; don't follow an old guide looking for an HTTP field that isn't there.

1. Check the New Port

   Use the commands above to check 11808. If your configuration has separate listeners for the two protocols, check 11809 too. An empty result means the port isn't in use right now; it doesn't guarantee another program won't use it later.

2. Open Settings

   Go to Settings → Parameters Settings → Core Basic Settings on the main window and find the local listening port field. If the section names differ slightly, look for the settings page with the local port and listening address.

3. Enter the New Port

   For a mixed listener, use 11808. For separate SOCKS and HTTP listeners, use 11808 and 11809, respectively. Change only the local inbound ports, not the remote port in the server editor.

4. Save and Restart

   Save the settings and wait for the client to apply them. If the logs don't show a restart, exit normally from the tray and start a single instance again. Check the new logs for any bind errors.

5. Check the Listener Again

   Check the PID listening on 11808 and confirm it belongs to the core launched this time. It's fine if another service is still using the old port, 10808; the important thing is that v2rayN successfully bound to its new port.

Don't edit the client-generated runtime configuration to make a port change permanent. Such files may be regenerated when you switch nodes, save settings, or restart the core. If you use a custom configuration, also check listen, port, and protocol in its inbound settings; otherwise, the client may still load the old inbound even after you change the UI settings.

Update System Proxy and App Proxy Settings

Even after the port change succeeds, your browser may still try the old 127.0.0.1:10809 endpoint. The core is running, but the app can't reach the right proxy. Update each proxy setting instead of continuing to switch nodes.

The system proxy doesn't override every app's separate settings, and it won't update environment variables in terminals that are already running. On Windows, check the address actually set under Settings → Network & Internet → Proxy. If you're using PAC mode, make sure the PAC file returns the updated proxy port too. For troubleshooting, start by testing a known manual proxy endpoint to reduce variables.

Test the Local Endpoint and Remote Requests in Order

Test local TCP connectivity separately from whether the proxy can complete a request. In Windows PowerShell, first check the new listening port. A TcpTestSucceeded value of True only means something accepted the TCP connection; it doesn't confirm that the node, DNS, TLS, or routing is working. You still need to verify which process is listening.

Test-NetConnection -ComputerName 127.0.0.1 -Port 11808

Next, use curl with an explicitly specified proxy to rule out issues with the system proxy. The example uses SOCKS5, which works with SOCKS or mixed listeners; socks5h sends the target hostname to the proxy for resolution. On Windows PowerShell, run curl.exe; on macOS and Linux, run curl with the same arguments.

curl.exe --proxy socks5h://127.0.0.1:11808 --connect-timeout 10 --max-time 30 -I https://v2rayopenwrt.com/

• Connection to the local port is refused: Check the listener again. Verify that you entered the right port, the core is still running, and the listener is using 127.0.0.1.
• Proxy protocol error: Check whether you sent an HTTP request to a SOCKS-only endpoint, or the other way around. The port number alone doesn't tell you which protocol it accepts.
• Local connection succeeds, then the handshake fails or times out: Check the node, DNS, TLS, and routing logs. This is no longer a port conflict.
• curl works, but the browser doesn't: Check the browser-specific proxy, system proxy, and PAC settings, especially for stale references to 10808 or 10809.

The 10-second connection timeout and 30-second overall timeout in the example are command options, not performance test results. An HTTP status from one website doesn't prove that every destination is reachable. The goal here is to verify that the request uses the right local endpoint and pinpoint the stage where it fails.

Common Questions and Preventing Recurrence