This guide is for users whose v2rayN fails to start, whose 10808 port is already in use, whose browser proxy is unresponsive, or whose core keeps exiting. Start by confirming the listening address, then use Windows, macOS, or Linux tools to identify the process. Finally, stop the old process or change the port, and update system, browser, and app proxy settings.
Confirm that a port conflict is actually occurring
Cores such as V2Ray and Xray create inbound listeners on the local machine, while browsers and other apps send requests to those ports. A common setup uses 127.0.0.1:10808 for SOCKS and 127.0.0.1:10809 for HTTP. The exact ports depend on the client configuration and are not fixed across all versions.
A port conflict occurs when two processes try to listen on the same address, use the same transport protocol, and bind to the same port. For example, if an old v2rayN core is still running and a newly launched core tries to bind to 127.0.0.1:10808, the system rejects the second listener. Subscriptions, VMess, VLESS, and routing rules are usually not the first things to check.
Error: listen tcp 127.0.0.1:10808: bind: address already in use
Cause and fix: Another process is using TCP 10808. Find its PID, verify which program it belongs to, then exit the old process normally or move the new client to an unused port.
Error: Only one usage of each socket address is normally permitted
Cause and fix: Windows rejected a duplicate bind to the same socket address. Check whether v2rayN was launched twice, an old core is still running, or another local proxy is active.
Symptom: The core is running, but the browser keeps reporting that the proxy server is not responding
Cause and fix: This may not be a port conflict. The browser could still be pointing to the old port. Compare the client’s current listener settings and make sure the HTTP or SOCKS type is correct.
Find the process using 10808 on Windows
Both Windows 11 and Windows 10 include netstat for identifying listeners. Fully exit v2rayN before starting the check, then open a terminal and run the command. This helps prevent the new process from being mistaken for the conflicting one.
Query listening records
Open PowerShell or Command Prompt and run
netstat -ano | findstr :10808. Focus on lines whose state isLISTENING, and note the PID in the far-right column.Verify the process name
Run
tasklist /FI "PID eq process number", replacing the process number with the actual PID. You can also search by PID on the Details tab in Task Manager.Decide whether it can be stopped
If the result belongs to an old v2rayN process or core, exit it normally from the tray menu. If it belongs to another program that is still in use, do not terminate it immediately; move one of the clients to a different port instead.
Confirm the port again
Run the query again. Once no
LISTENINGentry remains, start v2rayN and check the log for a successful listener message.
netstat -ano | findstr :10808
tasklist /FI "PID eq 6420"
PowerShell:
Get-NetTCPConnection -LocalPort 10808 -State Listen
Get-Process -Id 6420If the results show several connection states, do not treat ESTABLISHED or TIME_WAIT as listeners. The state to verify is LISTENING, or Listen in PowerShell output. Connection-state entries indicate active connections; their rightmost PID can still help identify the process using them.
Bottom line: identify the PID first, then handle the process
Stopping a process is not always required. If the PID belongs to an old core, exit it normally. If it belongs to a development server, remote-access tool, or proxy that is still working, changing the local v2rayN port is usually safer.
Check listeners on macOS and Linux
Both macOS and Linux can use lsof to inspect ports, while Linux distributions typically also include ss. On Debian, Ubuntu, Fedora, and similar systems, regular users may not see complete details for processes started by other accounts. After confirming the required permissions, use sudo when necessary.
macOS:
lsof -nP -iTCP:10808 -sTCP:LISTEN
Linux:
ss -ltnp | grep ':10808'
sudo lsof -nP -iTCP:10808 -sTCP:LISTENError: listen tcp 0.0.0.0:10808: bind: address already in use
Cause and fix: Another program is listening on 10808 across all IPv4 interfaces. Use ss -ltnp or lsof to find the PID, then decide whether to stop the related user service or change the client port.
Symptom: lsof returns no output, but the client still says 10808 is in use
Cause and fix: Check whether the actual error involves UDP, IPv6, or a different port. Then query [::]:10808, UDP listeners, and the complete address shown in the log.
- macOS: Search by PID in Activity Monitor to verify the process path and launch user. When closing a graphical client, also check its background status in the menu bar.
- Linux desktop: If the client was started as a systemd user service, closing its window may not stop it. Run
systemctl --user statusto inspect services for the current user. - Multi-user Linux environments: A listener on
0.0.0.0covers every IPv4 network interface, so do not check only127.0.0.1. - Containers: A container mapped to host port 10808 can also cause a conflict. The process shown by the command may be the container runtime rather than the proxy core name.
Stop the old process or change the listening port
The right fix depends on whether the process using the port is still needed. After verifying its identity, you can stop an orphaned old core, a duplicate client instance, or a process left by an abnormal exit. If the port belongs to an ongoing service, keep that service running and give v2rayN a different local port.
Do not change just one setting. SOCKS, HTTP, LAN listening, and API ports may be configured separately; any two settings that accidentally use the same address and port can prevent the core from starting. After choosing a new port, also verify that system and app proxy settings were updated.
Record the current settings
In the v2rayN main window, open “Settings” → “Parameter settings” and record the local SOCKS, HTTP, and LAN access values. Group names may vary slightly between versions; use the port fields as the source of truth.
Choose an unused port
Use a system command to check candidate ports first, such as 10810 or 10811. After confirming that nothing is listening, enter the port in the client rather than choosing it simply because the number looks unfamiliar.
Save and restart the core
Save the settings, then restart the core or close and reopen v2rayN. Query the new port afterward and confirm that the expected PID is listening.
Reset the proxy entry points
If v2rayN does not manage the system proxy automatically, replace
127.0.0.1:10808with the new port. Update browser extensions and standalone apps individually as well.Keep the address scope in mind
For local-only use, keep the listener on
127.0.0.1. Enable LAN listening only when devices on the local network explicitly need to connect.
| Scenario | Recommended action | Check afterward |
|---|---|---|
| Old v2rayN core left running | Exit the old process normally, then start the current client | Is 10808 being listened to by the new PID? |
| Another local service uses the port continuously | Keep the existing service and move the proxy to an unused port such as 10810 | System proxy and browser ports |
| Two v2rayN instances running at the same time | Keep only the required instance, or assign different ports to the two instances | Tray icon and startup items |
| LAN listening covers the local address | Verify that listening on all interfaces is actually required | Binding scope of 0.0.0.0 and 127.0.0.1 |
Bottom line: let long-running services keep their ports; exit orphaned processes
When the conflicting process is still doing useful work, change the local proxy port. When the conflict comes from a duplicate launch or an old core, removing its startup source is more effective than repeatedly changing ports.
Update system proxy and browser settings
If access still fails after resolving the port conflict, traffic is most often still going to the old port. Seeing 10810 in the client does not mean that the browser, command-line tools, and system proxy automatically switched to 10810. Check every manually configured proxy entry separately.
| Where to check | What to verify | Common mistake |
|---|---|---|
| Windows system proxy | Address is 127.0.0.1 and the port matches the current HTTP inbound | Entering the SOCKS port in a field that accepts only HTTP |
| Browser-specific proxy | Proxy type, host, and port all match | The extension still stores the old 10808 |
| Command-line environment variables | HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY |
The terminal session has not reloaded the variables |
| Other devices on the LAN | Enter the LAN address of the computer running the client and the new port | Entering 127.0.0.1, which points to the device itself |
Symptom: The core runs normally after switching to 10810, but webpages immediately refuse the connection
Cause and fix: The app is still connecting to the old 10808, or it is treating a SOCKS proxy as HTTP. Select the correct proxy type and update every manual entry to the current listener.
Symptom: The browser works, but terminal commands still cannot connect
Cause and fix: The browser and terminal are using different proxy sources. Check proxy environment variables in the current terminal session, then reopen the terminal and test again.
On Android, v2rayNG and v2flyNG generally manage the local proxy and VPN handoff within the app. If connection problems appear after importing the same subscription, do not directly reuse desktop PID commands. First check whether another VPN connection is enabled, then verify the client’s local port and runtime status.
Verification steps after fixing the issue
Start verification with the local listener rather than assuming the node has failed. If the local port is not established, protocol handshakes, transport connections, and routing cannot occur. First prove that the app can connect to the local proxy, then check node parameters and the remote network.
Confirm a single listener
Run
netstat,lsof, orssagain. The target port should be listened to by the expected core PID, with no unexplained second service.Check the client log
Watch the log for 30 seconds after startup and confirm there are no new
address already in useerrors, repeated restarts, or inbound creation failures.Test the local proxy
Have the browser or command-line tool connect explicitly to the current port. An immediate connection refusal indicates a local listener problem; a timeout after the connection is established points to the node or network.
Verify routing results
Confirm that routing rules are not sending the test target to direct or blocked outbound traffic by mistake. Fixing a port does not automatically change geosite, geoip, domain, or other rules.
Recheck automatic startup
Check again after rebooting or signing in again. If the old port is occupied once more, a login startup item or user service is still launching the old instance in the background.
If the port is listening normally but every node still times out, investigate the network and configuration layers: verify system time, node address, protocol parameters, transport settings, and subscription validity. A port conflict occurs during local inbound setup and cannot explain every connection failure after traffic has already entered the core.