v2rayN Local Port in Use: How to Find and Fix Port Conflicts

At a glance

This guide is for desktop users dealing with a failed core startup, a proxy that stops working after a restart, or websites that remain inaccessible after changing a local port. First distinguish a failed listener from an incorrect proxy address, then identify the process using Windows or macOS commands, change the port, and test the connection again. There’s no need to delete subscriptions or reinstall the client first.

First, check whether the error is from the local listener

The local listening port is where apps such as browsers send requests to the proxy core. It is not the remote port used by a server in your subscription. For example, 127.0.0.1:10808 is an entry point on your computer’s loopback address; 443 after a server address is usually the destination port on the server. Changing the remote port won’t fix a local bind failure and could break a node that was configured correctly.

Open the log panel in the v2rayN main window, restart the service, and check for errors around the startup time. Note the listening address, port, and failure reason. These are common error messages; the full log may include a core module name, and the port number may differ depending on your settings.

Error: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.

Cause and fix: Another listener is already using the address and port on Windows. Find the PID for that port, then either exit the conflicting app normally or change the local port.

Error: bind: address already in use

Cause and fix: The address and port are already in use on macOS or another system. Use lsof to identify the listener, and check whether another copy of the client is still running.

Error: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

Cause and fix: Windows refused the bind. The port may be in an excluded range or blocked by a security policy; this doesn’t necessarily mean another process is using it. Check active listeners and system-reserved ranges, then choose an available port you’re allowed to use.

If the log only shows a node connection timeout, authentication failure, or DNS lookup failure, and the local listener is running, investigate the node, DNS, or routing instead. Don’t change ports just because you see “connection failed”; first identify which part of the connection is failing.

Proxy settingsLocal listenerRouting rulesNode connectionDestination website

Windows: Find the process using the listening port

The examples below use 10808. Replace it with the port that failed in your log; not every version uses the same default. Run this query in PowerShell. If the process path isn’t shown, reopen PowerShell as an administrator. You don’t need to run the client as an administrator on an ongoing basis.

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

Find the OwningProcess value, then look up that PID. The 6240 below is just an example; replace it with the value returned by the previous command. Checking the executable path is more reliable than relying on the process name, especially when v2rayN is installed in more than one folder.

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

You can also run these two commands in Command Prompt. The first command’s results may include remote ports or other matching numbers, so check the “Local Address” column and look for a line with the status LISTENING. The number at the end of that line is the PID using the listener.

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

Another copy of v2rayN or its core: Exit it normally from the program’s tray menu, then check the port again. Closing the window may only minimize the app to the tray.
Other software you still need: Keep the software running and assign v2rayN a different available port, so the two programs don’t compete for the same entry point after startup.
An unfamiliar system service: Identify the service before taking action; don’t force-quit it. A PID appearing consistently in the log doesn’t mean it’s safe to terminate.

macOS: Identify the listener and exit it normally

Open Terminal and use lsof to check TCP listeners. For HTTP and SOCKS proxy entry points, start with TCP. Only add a UDP query if the log specifically reports a UDP bind failure. TCP and UDP use separate port spaces, so don’t treat their results as interchangeable.

lsof -nP -iTCP:10808 -sTCP:LISTEN

In the output, COMMAND is the program name, PID is the process ID, and NAME is the listening address. If you don’t have permission to see another user’s listener, run sudo lsof -nP -iTCP:10808 -sTCP:LISTEN for more detail. To find the command used to launch a process, replace the example number below with the actual PID.

ps -p 6240 -o pid,ppid,command

Exit the other client normally from the menu bar or app menu. Closing its window alone may leave the background service running.
Run lsof again to confirm the old listener is gone. If a new PID appears right away, check the app’s login items or automatic restart settings.
Start the v2rayN instance you want to keep, then check the same port to confirm it’s now being used by that instance’s core.

If the same port appears on both IPv4 and IPv6, compare the PIDs first. Both listeners may belong to one process, not two copies of the client. Use the address family, bind address, and log details to determine whether there’s a conflict; don’t just count the lines.

Change the local listening port in settings

If you can’t free the original port, move the local entry point to a port such as 11808. First use the commands above to make sure nothing is listening on it. The example isn’t guaranteed to be available on every system. Note the original value so you can restore it if needed.

Record the current settings

Go to Settings → Parameter Settings and find the local listening port fields. Record the port, listening address, and entry type. Depending on the version, the field may be called “Local Listening Port” or “Local Mixed Listening Port”; use the label shown in your version.
Check the new port

Replace 10808 in the query with 11808. Finding no listener is only the first check. On Windows, if you get an access-permission error, also check the system’s excluded port ranges.
Save and restart

Change the relevant entry to 11808, save the settings, and restart the service. If there’s no restart option in your version, exit the client normally and reopen it. Check the new startup log to confirm the bind succeeded.
Reconfigure the proxy

In the tray menu under “System Proxy,” select “Clear System Proxy,” then “Set System Proxy.” Check your operating system’s proxy settings afterward to confirm the HTTP and HTTPS address and port have been updated.
Update other apps

Update any browser manual proxy settings, command-line environment variables, and other apps that still point to the old port. SOCKS5 and HTTP must each use an entry point that supports that protocol; matching port numbers alone don’t make them interchangeable.

Verify the system proxy in two steps

A port accepting connections and a browser using that port are two different things. First check which process is listening on 11808, then make an explicit proxy request, and finally check the browser. This helps avoid repeatedly changing local port settings when the actual problem is an unreachable node.

Verification stage	How to check	What the result means
Local entry point	Check the new port’s LISTEN state and PID	If nothing is listening, troubleshoot core startup first. If there is a listener, check the protocol and request next.
Explicit proxy request	Use curl and specify the local proxy explicitly	A response from the destination means the proxy chain worked for that request. If the connection is refused, check the entry address and port first.
System proxy	Check the proxy address, port, and mode in system settings	If an explicit proxy request works but the browser doesn’t, first check whether the app uses the system proxy and whether any bypass rules apply.

In Windows PowerShell, use curl.exe to avoid differences caused by command aliases. If 11808 is an HTTP or mixed entry point, run the command below; on macOS, replace the command at the start with curl. The public webpage is just a request target, not a designated speed-test site.

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

If the entry point accepts SOCKS5 only, use this command instead. socks5h passes the destination hostname to the proxy for resolution, so the test follows a different path from one that resolves the name locally. Receiving HTTP response headers means the request reached a responder, but one successful request doesn’t prove that every website or routing rule is working.

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

Can’t connect to the local address right away: Check the listening process, port, and whether the entry point uses HTTP or SOCKS.
Local connection succeeds but then times out: Check the node connection, DNS, and routing results in the core log. Don’t keep changing the local port without a reason.
The command works but the browser doesn’t: Check the browser’s own proxy settings, extensions, and bypass list. Make sure they don’t still point to 10808 or 10809.

Common questions: No process found, conflicts after reboot, and running multiple clients

Why is the port still unavailable when no process shows up?

Make sure you’re checking the port shown in the log, and verify whether the error concerns TCP or UDP. If Windows reports an access-permission error, run the command below to check excluded IPv4 TCP port ranges; for an IPv6 listener, replace ipv4 with ipv6. If the port falls within an excluded range, choose one that isn’t excluded and has no listener. Don’t remove system reservations without a good reason.

The conflict comes back after reboot. Is the subscription the problem?

Local bind conflicts are usually unrelated to subscription contents. When the conflict occurs, immediately check the PID and executable path, and see whether clients in two different folders are both set to launch at startup. Keep only one startup entry and reboot to verify. If the listener belongs to software you need, assign the two programs different ports.

Can I run two copies of v2rayN, each connected to a different node?

Use separate configuration directories and make sure none of the local listening ports enabled in either copy conflict. Changing just one entry may leave another HTTP, SOCKS, or custom inbound using the same port. Let only one instance manage the system proxy at a time; use manual proxy settings in apps for the other, or the instance started later may overwrite the first one’s proxy settings.

How do I get websites working again after closing v2rayN?

If the client is still open, select System Proxy → Clear System Proxy before exiting. If it’s already closed, open your operating system’s proxy settings and turn off any manual proxy pointing to a stopped local entry. Remove only the settings related to this issue; don’t overwrite proxy settings required by your workplace network. Test the connection without a proxy, then start the client again.

netsh interface ipv4 show excludedportrange protocol=tcp

You should end up with three clear results: the current core is listening on the new port, an explicit proxy request gets a response, and neither the browser nor system settings refer to the old port. Record the old and new ports and the path of the process that was using the port. If another startup conflict or leftover instance occurs, you’ll have the evidence you need to troubleshoot it quickly.