v2rayN Local Port Conflicts

First, confirm the error is about a local listener

v2rayN is a graphical client; the core it launches handles proxy connections and listens on local ports. When your browser uses the system proxy, it typically connects to a local address such as 127.0.0.1:10808. If that listener is not available, the browser cannot send requests through it, even if your subscription is valid and your node configuration is complete.

Open the log panel in the v2rayN main window and find the latest startup failure. Note the protocol, address, and port in the error; don't rely only on the final “startup failed” line. 10808 is a common example, but not every version or configuration uses it. Use the port shown in your log when troubleshooting.

By contrast, connection refused usually means a connection attempt was rejected; check the destination address. A refusal from an old local port is not the same as a refusal from a remote node. A timeout only at the node address also doesn't prove that the local port is the problem.

Find the process: identify it by port

Run these commands in Windows PowerShell. First, check whether TCP port 10808 has a listener. No output means this query found no TCP listener on that port; it doesn't guarantee the port can be bound.

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

Check LocalAddress and OwningProcess. A listener on 0.0.0.0 covers all local IPv4 interfaces and may conflict with a listener on the same port bound to 127.0.0.1. Whether IPv6 :: conflicts with IPv4 depends on socket options, so keep the full address information.

Next, look up the process name, executable path, and command line. The command below gets the process ID from the query results, so you don't need to enter a PID manually:

$listeners = Get-NetTCPConnection -State Listen -LocalPort 10808 -ErrorAction SilentlyContinue
$ownerIds = $listeners | Select-Object -ExpandProperty OwningProcess -Unique
foreach ($ownerId in $ownerIds) {
  Get-CimInstance Win32_Process -Filter "ProcessId = $ownerId" |
    Select-Object ProcessId, Name, ExecutablePath, CommandLine
}

If the process path is blank, reopen PowerShell as an administrator and query its details. Don't terminate a system service based on its name alone, and don't assume every core process is stale. A running core is expected to occupy the listening port configured in the client.

Free the port: exit duplicate instances first

If you find another instance of the same client, exit it using the tray menu in the taskbar notification area. Closing the main window may only hide it, leaving its listener active. After exiting, run the port query again to see whether the listener is gone, then start the client you want to keep.

1. Note the process ID (PID), file path, and command line, then confirm which program folder it belongs to.
2. Use that program's normal exit option, wait a few seconds, then query 10808 again.
3. If the client has exited but a core process from its folder is still running, verify the PID in Task Manager's Details tab before ending the process.
4. Start just one v2rayN instance and check whether the same bind error appears in the log.

Change the listening port: 11808 as an example

If another program needs the current port, change v2rayN's local listener to 11808. This is only an example; the port may not be free on your computer. Check 11808 with the query command above, and check the system's excluded port ranges below if needed.

1. Note the current settings

   Record the current port, listening address, and system proxy status. This example changes 127.0.0.1:10808 to 127.0.0.1:11808 without changing the node's remote port.

2. Open the settings

   Go to Settings → Parameter Settings and find the local listening port under the basic settings. Depending on your version, the field may be called “Local mixed listening port” or “Local listening port.” Use the label shown in your version.

3. Enter the new port

   Change the relevant local endpoint to 11808. If your version has separate SOCKS and HTTP endpoints, check each field individually and don't assign the same port to both independent listeners. A mixed listener can accept both protocols on one port.

4. Save and restart

   Save the settings so the core reloads them. If it doesn't restart automatically, exit and reopen v2rayN, then check for a listener on 11808 and confirm its path belongs to the client you just started.

5. Refresh the system proxy

   In the System Proxy menu in the main window or tray, select Clear system proxy, then Set system proxy automatically. Check that the system proxy address now points to the new port.

The local listening port and the node's remote port are separate settings. Ports such as 443 in the node editor belong to the remote server. Changing one can break the node connection; it won't fix a local conflict on 10808. With a custom configuration, also check which inbound settings are active: the general parameter page may not override custom inbounds.

Update the proxy: fix apps still using the old port

After changing the port, the next common issue is an app still connecting to the old endpoint. In Windows 11, check Settings → Network & internet → Proxy → Manual proxy setup. In Windows 10, go to Settings → Network & Internet → Proxy. A typical local HTTP proxy should use 127.0.0.1 and 11808.

• Browsers that use the system proxy: Refresh the system proxy and reopen the page. If the browser has a separate proxy extension, check its settings too.
• Apps with manual proxy settings: Change 127.0.0.1:10808 in the app to the new endpoint, and confirm whether it expects HTTP or SOCKS.
• Command-line tools: Check whether HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY still points to the old port. Open terminals won't automatically pick up environment variable changes made afterward.
• For TUN mode: The system proxy and TUN are different traffic interception methods. When troubleshooting the local endpoint, stick to one test path and avoid changing multiple routing and interception settings at once.

Use the command below to check proxy environment variables in the current PowerShell session. If you find an old value, change it in the terminal profile or system environment variable settings where it was set; refreshing the browser alone won't help.

Get-ChildItem Env: |
  Where-Object Name -Match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$'

Verify the result: test the listener and outbound connection separately

First, confirm the new port is listening, then test a request through it. The example below assumes 11808 is a mixed listener that supports HTTP or an HTTP listener. If it's a dedicated SOCKS endpoint, use the SOCKS command below instead.

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

Test-NetConnection -ComputerName 127.0.0.1 -Port 11808

curl.exe --noproxy "" --proxy http://127.0.0.1:11808 --connect-timeout 10 --max-time 20 -I https://example.com/

TcpTestSucceeded : True means only that the TCP connection succeeded. It doesn't confirm that v2rayN is the listener or that the remote node is available. Check the process path and look for a matching entry in the core log while the request runs. An HTTP response header confirms that a response was received; interpret the status code in the context of the destination site.

curl.exe --noproxy "" --proxy socks5h://127.0.0.1:11808 --connect-timeout 10 --max-time 20 -I https://example.com/

In the SOCKS example, socks5h sends the destination hostname to the proxy for resolution. Choose one command based on the endpoint type; don't change the node protocol just to make the test pass. If a request through the explicitly specified proxy succeeds but the browser fails, check the system proxy and the browser's own settings instead of changing the listening port again.

No process is using the port? Check system-reserved ports

If you get an access-permission bind error and the TCP query consistently returns no results, check Windows excluded port ranges from an administrator terminal. Virtualization and networking components may create these ranges. A port in one of these ranges may not be bindable even when no user process is listening on it.

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

The output shows ranges by their starting and ending ports. For example, if a row runs from 11800 to 11899, then 11808 is also in that range. This illustrates how to read the output; it doesn't mean your device necessarily has this reservation. Choose a port outside the ranges with no listener, save the settings, and test again. Don't delete system reservations from an unknown source.

• If the log says udp, check for UDP conflicts with Get-NetUDPEndpoint -LocalPort 10808 -ErrorAction SilentlyContinue; don't check TCP alone.
• If the bind address isn't an address on this computer, check the listening address configuration instead of terminating more processes.
• If several different, unreserved free ports are still rejected, check security software events and device policies set by your organization. Save the full logs for an administrator to review.

Port conflict FAQ