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

Tell a Local Port Conflict from a Node Connection Failure

v2rayN is the configuration and management interface; its core handles incoming proxy connections on your PC. Your browser sends requests to a local listening address, and the core routes them according to its rules. If the local port cannot be bound, the connection fails before reaching a remote node. Updating your subscription or switching VMess or VLESS nodes usually won't fix it.

Check the log area in the main window and find the full error around the time startup failed. The two messages below are common Windows socket errors. Logs may also include the listening address, port, and core details. Don't assume a port conflict based only on a generic “connection failed” message.

If the log shows only remote connection timeouts, authentication failures, or DNS errors, while the local listener is already up, investigate node settings, DNS, or the network path instead. This guide covers local port binding; not every loss of connectivity is caused by a port conflict.

Find the Port and PID with netstat

First, open Settings → Options and note the current local listening port. In newer versions, this is usually listed as “Local mixed port” under “Core: Basic settings.” The wording and grouping may vary slightly by version, so check the actual field. The values below are examples, not universal defaults.

Press Win + R, type cmd, and press Enter. Run the first command in Command Prompt; use the second to check the port you plan to switch to.

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

• Check the Local Address column and make sure the number after the colon is the port you're looking for. findstr may also match a remote address or a longer number, so not every result indicates a conflict.
• Look for entries with the state LISTENING. The last column is the PID (process ID), not the port number.
• Check for wildcard listeners such as 0.0.0.0:10808 and [::]:10808; don't search only for 127.0.0.1. Whether these conflict depends on the bound address and socket options.
• Don't treat TIME_WAIT as an active application listener, or use it as a reason to terminate an unrelated process.

For a precise filter, run this command in PowerShell. It lists only local TCP listeners; OwningProcess is the PID to investigate. No output means no matching TCP listener was found at the time of the query, not that the port is guaranteed to bind successfully.

Get-NetTCPConnection -State Listen |
  Where-Object { $_.LocalPort -in 10808,10818 } |
  Select-Object LocalAddress,LocalPort,State,OwningProcess

Identify the Process with Resource Monitor

Once you have a PID, identify the process before deciding whether to close it. The listener could be the core currently in use, a process from another v2rayN folder, a leftover process, or another local service. A matching process name alone doesn't tell you which instance it belongs to.

1. Open Resource Monitor

   Press Win + R, type resmon, and press Enter. Open the Network tab, expand Listening Ports, find 10808 in the Port column, and check the image name, PID, and protocol.

2. Check the File Path

   Open the Details tab in Task Manager, find the process by PID, right-click it, and select Open file location. If needed, enable the Command line column to confirm whether the launch path and arguments belong to the current v2rayN instance.

3. Close Duplicate Instances

   If the process belongs to another v2rayN instance, use that instance's tray menu and select Exit. Closing the main window may only minimize it to the system tray; the process may still be running.

4. Check the Listener Again

   Run the port query again and confirm the old listener is gone before starting the instance you want to keep. If the listener quickly reappears, check Task Manager's Startup apps and Task Scheduler for duplicate startup entries.

You can also look up an image name by PID from the command line, for example: tasklist /FI "PID eq 4321". Here, 4321 is only a syntax example; replace it with the actual PID you found. Don't copy the number into a command that terminates a process, and don't kill system services just to free a port. If the service needs to keep running, changing the v2rayN port is usually the better option.

Change the v2rayN Local Listening Port

Check the new port before switching to it, so you don't trade one conflict for another. Valid port numbers range from 1 to 65535. This example uses 10818; it is a convenient candidate, not a guaranteed-free port. Change the local inbound listener, not the server port in a node's settings.

1. Note the Current Settings

   Record the current listening address, port, and system proxy mode. If other apps use manual proxy settings, note their proxy type and port too, so you can update or restore them later.

2. Open the Options Page

   Go to Settings → Options → Core: Basic settings and find “Local mixed port.” If your version uses a label such as “Local listening port,” confirm the field by checking the current port and its description. Don't change a node address or subscription URL.

3. Save the New Port

   In this example, change 10808 to 10818 and save. If your version has separate HTTP and SOCKS listener fields, check each one. Don't assume the other port will automatically increment by 1, or set two separate listeners to the same port without checking.

4. Restart and Verify

   Reload the configuration. If saving doesn't restart the core, exit v2rayN normally and reopen it. Check the startup log, then query port 10818 to confirm the listener is active and its PID belongs to the core you just started.

Update System Proxy, Browser, and Command-Line Settings

After the core switches to port 10818, apps still pointing to 10808 will keep connecting to the old address. So if the core starts but websites won't load, the new port may be fine—the apps using it may simply need updating. Check each item below before changing nodes again.

• System proxy: From the v2rayN tray menu, choose System proxy → Clear system proxy, then select Automatically configure system proxy. Next, open Windows 11 Settings → Network & internet → Proxy and check that the generated configuration uses the current port. If you use PAC, check its active configuration too; don't look only at the manual proxy setting.
• Browser: Browsers that use the system proxy usually pick up the updated setting automatically. For browsers or extensions with their own proxy settings, enter the new port manually. In Firefox, check Settings → General → Network Settings → Settings and verify whether it uses the system proxy or a manual proxy.
• Proxy type: HTTP and SOCKS are different protocols. A mixed listener can accept different connection types within its supported range; for separate listeners, enter the matching port. A successful connection to a port alone doesn't mean you've selected the right protocol.
• Command line: Check HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY in the current terminal and your user environment variables. If they contain the old port, update them and reopen the terminal; existing processes usually retain the environment variables they started with.

First test the local TCP connection, then test a proxy request. The first command checks only whether a TCP connection to the port can be established; it doesn't verify the proxy protocol or node. The second explicitly uses an HTTP proxy and works with a mixed or HTTP listener confirmed to support HTTP.

Test-NetConnection -ComputerName 127.0.0.1 -Port 10818
curl.exe --proxy http://127.0.0.1:10818 --connect-timeout 10 --max-time 20 --head https://example.com/

Run both commands in PowerShell. If the first fails, return to checking the listener and process. If it succeeds but the second fails, check the proxy type, core logs, and node connection. If the explicit proxy request gets a response but the browser still fails, focus on the browser's own settings, system proxy, and existing connection cache. Don't assume this proves that every website is reachable.

Check Windows Excluded Port Ranges if No Process Is Found

If you get error 10013 and a regular listener query returns nothing, check Windows excluded port ranges from an elevated terminal. Virtualization or container networking components can affect port allocation, but confirm whether they're relevant using command output; their mere presence doesn't prove they're the cause.

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

• Compare the start and end port numbers to see whether 10808 or your candidate port falls within an excluded range. Also consider the address family used by the actual listener.
• If the candidate port falls within an excluded range, choose an unexcluded port with no active listener, then save and verify it. Don't copy commands that remove Windows port exclusions.
• If the port is neither in use nor within a relevant excluded range, check security software logs, organizational policies, and custom configurations for duplicate inbound listeners.
• If the conflict occurs only during startup, save the full log and query the process immediately. Once the process exits, you may no longer be able to find what was using the port.

Don't start by turning off the firewall. Firewall rules, listener binding, and remote connections are separate parts of the process; a standard inbound block rule doesn't mean an application is using the port. Administrator privileges won't let two conflicting listeners coexist. Investigate permissions or policies only when the logs point to them.

Port Conflict FAQs

Download the v2rayN Client

Choose the client for your operating system and architecture. For first-time setup, follow the guide to import a subscription and configure the system proxy.

Go to Downloads View the Guide