September 4, 2026 · Troubleshooting · About 10 minutes

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

Learn how to identify the process using a local port, distinguish duplicate launches from other conflicts, and update proxy settings after changing the port.

At a glance

For Windows users whose v2rayN core fails to start, logs show bind or address already in use, or browser proxying suddenly stops working. Confirm the failed listener and protocol, find the port's PID, and determine whether it belongs to a duplicate v2rayN instance, a leftover core, or another program. Change the port only when the conflicting process cannot be safely stopped, then update system proxy, browser, terminal, and other manual proxy settings.

First confirm that the local listener failed—not the remote node

v2rayN is a graphical client for managing subscriptions, nodes, routing, and system proxy status. The proxy core actually reads the configuration and handles connections. At startup, the core must bind a listening address on Windows, such as 127.0.0.1:10808. Browsers and terminals send requests to this endpoint, and the core then selects a direct or proxied outbound connection according to the routing rules.

If another process already occupies the port, the core usually stops while creating the local inbound. Switching VMess or VLESS nodes or updating the subscription will not free the port, because the conflict occurs before any remote connection is attempted. Check v2rayN's core log first and find the line containing listen, bind, the local address, and the port number.

Client starts Core reads configuration Local port is bound Application connects Outbound routing

Error: listen tcp 127.0.0.1:10808: bind: Only one usage of each socket address is normally permitted.

Cause and fix: TCP port 10808 is already being listened to by another process. Use the PID to identify it; if it is a duplicate client or leftover core, exit the corresponding process normally and start again.

Error: failed to listen on address: 127.0.0.1:10809

Cause and fix: The core cannot create the specified local inbound. Check TCP and UDP usage on 10809, and make sure the configuration does not define two inbounds with the same address, port, and transport protocol.

Error: listen tcp 0.0.0.0:10808: bind: address already in use

Cause and fix: The program is trying to listen on 10808 across all local network interfaces, overlapping an existing listener. If it is only for local use, check whether it should bind to 127.0.0.1; do not widen the listening scope just to bypass the conflict.

Find the PID using the port in Windows

Copy the port number from the log first; do not assume it is always 10808. Different configurations, migrated settings, and user changes may use other ports. The examples below use TCP 10808; if the log points to 10809 or another number, replace the port in the commands with the actual value.

10808
Common local proxy ports
10809
Adjacent ports often found in older configurations
127.0.0.1
Loopback address only
2 types
Check TCP and UDP separately

Method 1: Use PowerShell

Open PowerShell and run the following commands. State Listen limits the results to TCP ports that are currently listening, while OwningProcess returns the PID of the process using the port.

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

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

The 14632 in the second command is only an example PID. Replace it with the actual OwningProcess returned by the first command. If a regular window does not show the process path, reopen PowerShell with administrator privileges, but do not force-terminate a system service just because its name looks similar.

Method 2: Use Command Prompt

netstat is useful for quick checks on older Windows systems. The -a parameter shows listening entries, -n keeps addresses numeric, and -o displays the PID.

netstat -ano | findstr ":10808"
tasklist /FI "PID eq 14632"

Distinguish duplicate launches, leftover cores, and other process conflicts

Once you have the PID, the right action depends on the process identity. The port itself is rarely damaged. More often, the same client was launched twice, the core from a previous session is still running, or another local proxy tool or development service happens to use the same port.

Check the taskbar notification area and Task Manager first. v2rayN may remain in the notification area after its main window is closed, so double-clicking the program again does not necessarily mean only one instance exists. Prefer exiting the duplicate through the notification-area menu, then confirm that its associated core process has ended. Force-termination is appropriate only when the interface is unresponsive and the PID identity has been verified.

Query result Common cause Recommended action
Another v2rayN process The client was launched twice, or an older instance is still running in the notification area Keep one instance, exit the others normally from the client menu, then restart the core
Standalone core process The associated core did not exit when the client closed unexpectedly Check the process path and start time, confirm ownership, then terminate the leftover process
Another proxy or networking tool Two programs are configured to use the same local listening port Decide which program keeps the original port, then assign an unused port to the other
Development service or local debugging program The service happens to listen on 10808, 10809, or a custom port Do not terminate a working process blindly; assess dependencies and change one side's configuration
Two inbounds in the same configuration Manual settings assign the same endpoint to SOCKS, HTTP, or mixed inbounds Check generated and custom configurations to avoid duplicate address, port, and protocol combinations
  1. Record the listening address, port, and TCP or UDP type shown in the log.
  2. Use PowerShell or netstat to find the PID, then verify the process name, path, and start time.
  3. For a duplicate instance, exit it normally whenever possible. For a business-critical program, assess the impact before taking action; do not force-terminate it immediately.
  4. Restart the v2rayN core, query the port again, and confirm that the PID now belongs to the current core process.

Change the listening port when the conflicting process cannot be released

If the process using the port is a service that must remain running, or two proxy environments need to run in parallel, change v2rayN's local listening port. First check whether a candidate port is free in PowerShell. For example, if you plan to use 10818, check TCP and UDP separately.

Get-NetTCPConnection -LocalPort 10818 -ErrorAction SilentlyContinue
Get-NetUDPEndpoint -LocalPort 10818 -ErrorAction SilentlyContinue

No output from either command means only that no matching endpoint was found at the time of the query; it is not a permanent reservation. Then open v2rayN's “Settings” → “Parameter settings” and find the local listening, SOCKS, HTTP, or mixed proxy port field. Field names may vary slightly between interface versions, so follow the current interface and generated configuration. Do not change the remote node port to change the local listening port.

  1. Write down the original port, such as 10808, so you can roll back and find applications that still reference the old value.
  2. Choose an unused port, such as 10818. The port must be between 1 and 65535.
  3. Save the change under “Settings” → “Parameter settings”, then restart the proxy core so the new inbound configuration takes effect.
  4. Run Get-NetTCPConnection -LocalPort 10818 -State Listen to confirm that the current core is listening on the new port.
  5. Query 10808 again to determine whether the old listener has disappeared. This prevents you from assuming the change worked when an old instance is still serving traffic.

Still seeing an error after the change: listen tcp 127.0.0.1:10818: bind

Cause and fix: The new port is also occupied, or another v2rayN instance read the same setting. Query the PID for 10818 again; do not keep trying ports while skipping process identification.

No error after the change, but the browser connection is refused

Cause and fix: The core now listens on the new port, but the browser or extension still points to the old one. Change the manual proxy from 127.0.0.1:10808 to the actual new endpoint.

Handle the listening address carefully as well. For local applications only, keep the loopback address 127.0.0.1 in most cases. Changing it to 0.0.0.0 does not solve a port conflict; it changes the exposure scope and may still conflict with a program listening on all interfaces.

Update every proxy entry after changing the port

The core's listening port and the application's proxy address must match. Changing v2rayN's parameters updates only the local service endpoint; it does not automatically rewrite browser extensions, terminal environment variables, developer tools, or manual settings in virtual machines. When v2rayN manages the system proxy, refreshing the system proxy setting usually writes the new port. Apps configured manually must be updated one by one.

Also distinguish SOCKS from HTTP. Even when both endpoints are local, they may use different ports. Pointing an HTTP client to a SOCKS-only port can cause a connection failure, protocol error, or direct bypass instead of a port conflict.

New core port Refresh system proxy Check browser Update terminal variables Reconnect applications
Connection point What to check Example change
Windows system proxy Whether v2rayN rewrote the proxy server address and port Update from 127.0.0.1:10808 to 127.0.0.1:10818
Browser-specific proxy Whether the browser or extension overrides the system proxy Update the HTTP or SOCKS port according to the actual inbound type
Terminal environment variables HTTP_PROXY、HTTPS_PROXY、ALL_PROXY Close the old terminal window; reopen the session after changing the variables
Development and download tools The proxy host, port, and protocol saved inside the application Remove old references to 10808 and reconnect
Devices on the local network Whether LAN access is actually required and which listening address it needs Define the access boundary first; do not widen the listening scope instead of troubleshooting the port 
set HTTP_PROXY=http://127.0.0.1:10818
set HTTPS_PROXY=http://127.0.0.1:10818

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

The first two lines apply to the current Command Prompt session, and the last two apply to the current PowerShell session. They are HTTP proxy examples only. If the actual endpoint is SOCKS, use the SOCKS syntax supported by the application and confirm that it recognizes the relevant environment variables. Session-level variables usually do not persist after the window is closed.

Common questions and easy-to-miss boundaries

Why does v2rayN still say 10808 is in use after I end the process?

Run the port query again and verify the PID. A background service may have relaunched the program, or a second v2rayN instance may still exist. Exit duplicate instances from the notification area first, then confirm that both TCP and UDP endpoints have been released.

If I change 10808 to 10818, do I need to import the subscription again?

Usually not. The subscription stores remote nodes and related settings, while the local listening port belongs to the client connection settings. Restart the core after changing it, then update the system proxy and manually configured proxy applications.

What if there is no bind error in the log, but web pages still won't open?

First confirm that the new port is in LISTENING state, then check whether the application is actually using it. If the local endpoint works, move on to node availability, routing, DNS, and remote TLS settings.

Can disabling the system proxy release the port?

Not by itself. The system proxy switch tells some applications where to send requests; the core's running state determines whether it continues listening. Exit the core or client, then verify with a port query.

Why is the port free at first but occupied again as soon as startup begins?

Two instances may be starting at the same time, or a background program may bind the port first after the query. Record the conflicting PID, process path, and start time; this is more effective than repeatedly changing ports at random.

Windows Firewall blocking and port occupation are different problems. An occupation error means the core failed while binding locally; firewall rules usually affect whether connections are allowed through. When you see a clear bind or address already in use message, handle the listening conflict first instead of making firewall changes your first troubleshooting step.

With TUN, application traffic is captured differently from system proxy traffic, but the core may still create a local control port, DNS endpoint, or other inbound. Do not ignore a specific listening address in the log just because TUN is enabled. Locate each reported port individually instead of reinstalling the client without diagnosis.

Post-fix verification checklist

Success means more than making the error window disappear: the core must listen successfully, applications must point to the correct endpoint, and no old instance may continue using the original port. The sequence below separates local issues from remote node issues.

In short, handle port conflicts in the order “log endpoint → PID → process identity → configuration entry.” Exit duplicate instances and leftover cores first. If another service must remain, avoid it by choosing a different local port. Every port change must be synchronized with the applications that actually use the proxy; otherwise, the core may start successfully while browsers and terminals continue connecting to the obsolete endpoint.

Download the client