This guide is for anyone seeing “address already in use,” a core process that exits immediately, or a system proxy that is enabled while no local port is listening. Confirm the port and protocol, identify the process, decide whether to stop it or change the port, then update the system proxy, browser, and other dependent settings.
First confirm which local port is conflicting
When the V2Ray or Xray core starts, it creates a listening port on the local machine. Browsers and other apps send requests to this entry point, and the client handles them according to the node configuration and routing rules. v2rayN 7.x commonly uses a local mixed proxy port, and many existing configurations use 127.0.0.1:10808; older configurations may separate SOCKS and HTTP across ports 10808 and 10809. This port is not the remote server port. It serves only as the local entry point between applications and the client.
A given network protocol, listening address, and port combination can normally be used by only one process. For example, if a process is already listening on TCP 127.0.0.1:10808, a newly started Xray core requesting the same combination will fail to bind. “Startup failed” alone is not enough: open the v2rayN log window or inspect the core log for the original line containing listen, bind, or 10808.
- Confirm the port: If the log says 10808, check 10808. Do not guess based on the default value.
- Confirm the address:
127.0.0.1accepts connections only from the local machine, while0.0.0.0listens on all IPv4 network interfaces. - Confirm the protocol: TCP and UDP occupancy records are separate. Pay particular attention to UDP when troubleshooting TUN or DNS-related issues.
- Confirm the instance: Exit the client from the system tray before checking again, so an old core process is not still running in the background.
Find the process using port 10808 on Windows
On Windows, start by opening Terminal or Command Prompt. Standard permissions usually let you view connections and PIDs; if process details or terminating a system-level process is denied, reopen the terminal with administrator privileges. The first step is identification—do not force-kill a process as soon as you see its PID.
netstat -ano | findstr :10808
LISTENING in the output means a process is actively listening. The last column is the PID. For example, the record below shows that PID 6420 is using local TCP port 10808. If you see only TIME_WAIT, it is usually a short-lived state after a connection closes, not an active listening service.
TCP 127.0.0.1:10808 0.0.0.0:0 LISTENING 6420
Once you have the PID, use the task list to identify the executable. If a command returns multiple records, match the PID exactly rather than relying only on the process name, because the same program may have several instances running.
tasklist /FI "PID eq 6420"
| Query result | Common meaning | Recommended action |
|---|---|---|
| Another v2rayN or Xray process | An old instance did not exit, or the client was started twice | Exit the old instance from the system tray, then check the listening records again |
| Another local proxy program | Two programs are using the same entry port | Keep the port used by the preferred program and move the other program to a free port |
| Development service | A development tool happens to be using 10808 | Decide whether to change the development service or the client port based on the project’s dependencies |
| PID no longer exists | The process exited while it was being queried | Run netstat again to confirm that the listening port has been released |
PowerShell can also link listening records directly to process information. The command below checks only TCP 10808 and passes the PID owning that port to the process query. No output means there is currently no matching TCP listening record.
$listener = Get-NetTCPConnection -LocalPort 10808 -State Listen -ErrorAction SilentlyContinue
$listener | Select-Object LocalAddress, LocalPort, OwningProcess
$listener | ForEach-Object { Get-Process -Id $_.OwningProcess }
Change the local listening port in v2rayN
If the process using the port must remain active, changing v2rayN’s local port is usually more reliable than repeatedly terminating processes. In the common Chinese interface of v2rayN 7.x, first note the current system proxy state, then go to Settings → Parameter Settings → Basic Settings and find the local mixed proxy port or local listening port. Field names may vary slightly between 7.x releases, but change the inbound listening entry—not the node’s server port.
- Temporarily disable the system proxy from the tray menu so applications do not continue using the old address.
- Open Settings → Parameter Settings → Basic Settings and change the local port from 10808 to the example value 10818.
- Save the parameters and restart the core. If the interface asks you to restart the client, fully exit the tray instance and start it again.
- Open the log and confirm a record showing
127.0.0.1:10818listening, with no further bind or address already in use errors. - Enable the system proxy again, then check that its address is still 127.0.0.1 and its port has been updated.
Choose an unused port between 1024 and 65535, but do not judge availability by a high number alone. Before changing the setting, run netstat -ano | findstr :10818; only enter 10818 in the client if there is no LISTENING record. If the configuration includes SOCKS, HTTP, API, or DNS inbounds, each field must use a different port—do not assign the same value to every entry.
After changing the port, “core started successfully” only confirms that the listening conflict is gone. It does not mean the browser is using the new port. v2rayN usually updates the system proxy automatically, but manual proxy settings, browser-specific proxies, terminal environment variables, and development tools do not necessarily follow. Check each dependency individually.
- Windows system proxy: Confirm the address is still
127.0.0.1and the port has changed from 10808 to 10818. - Command-line environment variables: If
HTTP_PROXY,HTTPS_PROXY, orALL_PROXYis set, replace the old port there as well. - Browser-specific settings: When using a manual proxy, make sure the HTTP and SOCKS fields match the inbound types actually exposed by the client.
- LAN sharing: If other devices are allowed to connect, also check the listening address, LAN access switch, and system firewall rules.
Key port settings in v2rayNG and v2flyNG
Local port conflicts can also occur on Android. Common causes include another network tool using the same port, a service that did not stop cleanly, or a custom configuration that declares its own inbound. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Setting names vary by version, but the troubleshooting principle is the same: stop the current connection, change the local proxy entry point, and restart the service.
Using the common Chinese interface of v2rayNG 1.10.x as an example, go to Settings → Local Proxy Settings and check the local SOCKS port, HTTP port, or related listening fields. If the current value is 10808, change it to 10818 after confirming that the port is free. Return to the main screen, stop the connection, and start it again so the core reloads the inbound configuration. In v2flyNG, make the same change under the local proxy or listening port settings; do not edit the remote server port in a subscription node.
Error:listen tcp 127.0.0.1:10808: bind: address already in use
Cause and fix: Another process is already listening on TCP 10808—stop the conflicting program, or change the client’s local listening port to 10818 and restart the core.
Error:bind: Only one usage of each socket address is normally permitted
Cause and fix: Windows rejected a second process trying to bind the same address and port—use netstat to find the PID, then decide whether to exit the old instance or change the port.
Error:failed to start app/proxyman/inbound
Cause and fix: The inbound module failed to initialize. A port conflict is one common cause—check the listen or bind log entries that follow and troubleshoot the actual port shown.
If you use a custom JSON configuration, the global port in the interface may not override inbounds in the configuration file. Check the listen and port fields in every inbound object. Declaring 10808 more than once in the same configuration can also create an internal conflict within a single core.
{
"inbounds": [
{
"listen": "127.0.0.1",
"port": 10818,
"protocol": "socks"
}
]
}
The port is free, so why does startup still fail?
If startup still fails after resolving the conflict, reread the latest log instead of continuing to work with the old PID. A startup sequence may create listeners for the mixed proxy, API, DNS, and TUN in turn; successful binding on 10808 does not mean the other ports succeeded. Search the log for the next failed, listen, or bind entry, then repeat the check for the actual port.
netstat cannot find 10808, but the client still says it is in use?
First confirm whether the log refers to TCP or UDP, and check whether the listening address is IPv6. Use netstat -ano -p tcp for TCP and netstat -ano -p udp for UDP; then fully exit the client and reread the latest log.
After changing to 10818, why can’t the browser open web pages?
Check whether the Windows system proxy and the browser’s manual proxy still point to 10808. The address must match the client’s listening address, and the port must be changed to 10818. Then close and reopen the browser connection.
Does the port conflict return after every reboot?
Check Startup apps in Task Manager for two clients configured to start automatically, and confirm that there is no duplicate tray instance. Keep one automatic startup entry and assign different ports to programs that must coexist.
The process ended—why does the PID appear again immediately?
The program may be relaunched automatically by a background service or scheduled task. Disable automatic startup in the relevant program first, then exit normally. Do not repeatedly fight an automatic recovery mechanism with force-kill commands.
The system proxy shows the new port, but terminal commands still fail to connect?
The terminal may use separate proxy environment variables. Query the variables for the current shell and confirm that 127.0.0.1:10808 is not still present. Reopen the terminal window after making changes.
Also distinguish between a port being in use and a port being reserved. Some Windows networking components or virtualization features reserve a range of TCP ports. Even when netstat shows no listening process, the system may still reject the bind. Use the command below to view excluded ranges. If 10808 falls within one, choose an unused and unreserved port such as 10818 or 20808; this is usually more direct than changing the system’s reservation policy.
netsh interface ipv4 show excludedportrange protocol=tcp
Complete verification sequence after changing the port
Before finishing troubleshooting, perform one complete end-to-end check. The goal is not merely to make the error disappear, but to confirm that the core listener, system proxy, application connection, and node outbound path use the same settings. The sequence below helps prevent a client from appearing to run while traffic still goes to the old port.
- Fully exit the old client instance and wait for the tray icon and related core processes to disappear.
- Run
netstat -ano | findstr :10818and confirm that no other process is listening on the new port before making the change. - Start v2rayN, v2rayNG, or v2flyNG and confirm in the log that the new port is listening successfully.
- Query the port again and verify that the listening PID belongs to the core process started by the current client.
- Check the system proxy, browser manual proxy, terminal environment variables, and proxy settings in development tools.
- Choose a working node and test the connection. If the port is listening normally but the connection fails, check node availability, DNS, routing rules, and system time instead.
If the conflict was caused only by starting the client twice, keep the default 10808 and remove the old instance. If two local services must coexist long term, assign them different fixed ports and document which program owns each one. Once the port plan is stable, subscription updates, VMess or VLESS node selection, and direct-versus-proxy routing do not need to be rebuilt because of a local port change; only applications that depend on the local entry point need updating.