Use this guide when v2rayN fails to start on Windows, the core exits, or the system proxy cannot connect. Check the logs for the conflicting address, then use the port’s process ID to identify the program. Exit duplicate instances if possible; if the port remains unavailable, change the local listening settings and update the system proxy and any apps configured to use a proxy manually. Focus on the local entry point first—there’s no need to change your subscription or node protocol.
1. Confirm the error is at the local listening stage
Open the log panel in the v2rayN main window, restart the service, and note the address, port, and time in the latest error. A common local address is 127.0.0.1:10808, but use the address shown in your logs. Older configurations may use 10808 for SOCKS and 10809 for HTTP. A configuration with a mixed inbound may accept both protocols on the same port, so don’t infer the protocol from the port number alone.
Error: bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
Cause and fix: Windows reports that the address is already in use. This often happens when the client is running twice or another program is listening on the same address and port. Find the process listening on that port and, once you’ve confirmed what it is, exit the duplicate instance or assign the client a free port.
Error: bind: An attempt was made to access a socket in a way forbidden by its access permissions.
Cause and fix: Windows refused the bind. The port may fall within an excluded range, or a security policy may be blocking it; this doesn’t necessarily mean another program is using it. Check for a listener first, then review the system’s excluded port ranges. Repeatedly running with elevated privileges isn’t the only answer.
Error: connectex: No connection could be made because the target machine actively refused it.
Cause and fix: This means the connection was refused; it doesn’t directly indicate a port conflict. If the target is a local proxy address, check whether the core has exited or the app still points to an old port. If the target is a remote server, troubleshoot the remote connection separately.
A local listening failure occurs before a request reaches the proxy core. Switching VMess or VLESS nodes, or importing the subscription again, usually won’t free a local port. First narrow the issue down to the local entry point. Avoid changing routing rules, DNS, and outbound settings at the same time, or it will be hard to tell what fixed the problem.
2. Find the process using port 10808
Press Win + R, type cmd, and press Enter. Run the command below. If the logs show a different port, replace 10808 with that number. Keep a space after the port in the command to avoid matching numbers such as 108080.
netstat -ano -p tcp | findstr /C:":10808 "Focus on the Local Address and State columns; don’t stop at the first matching line. The example below explains the fields and doesn’t show your actual process ID. A record indicates a TCP listener only when the local address matches the target port and the state is LISTENING.
TCP 127.0.0.1:10808 0.0.0.0:0 LISTENING 6420- Local address:
127.0.0.1:10808is a loopback endpoint;0.0.0.0:10808listens on all IPv4 interfaces and may conflict with a bind to the loopback address. - State:
ESTABLISHEDandTIME_WAITdon’t prove that a port is listening. Also rule out connection records where 10808 appears only as the remote address. - PID: The number at the far right is the process ID. It can change when a program restarts, so use the result from your current query.
If the PID you find is 6420, run the query below. Replace the number if you have a different PID. Then open Task Manager → Details, find the process by PID, right-click it, and select Open file location to identify the program or client folder it belongs to.
tasklist /FI "PID eq 6420"You can also use PowerShell to filter for local TCP listeners and avoid confusing remote addresses with local ones. No output means this query found no matching listener. If you get a permissions error, resolve that first—it doesn’t mean the port is free.
Get-NetTCPConnection -State Listen -LocalPort 10808 |
Select-Object LocalAddress, LocalPort, OwningProcess3. Exit duplicate instances before changing ports
Don’t end a process as soon as you see its name. An Xray or V2Fly core may be managed by a running v2rayN instance, and closing it can interrupt active connections. If you have an old folder, a new folder, and a startup entry, first check which copy is open in the main window.
-
Identify the conflicting process
Note the listening address, port, PID, and program path. If two main windows are open, check each instance in the system tray so you don’t close the one still handling your connection.
-
Exit the old instance normally
Select Exit from the old instance’s system tray menu. Closing the window may only hide it in the tray and won’t necessarily release the listening port.
-
Check for a listener again
Run the port query again. If the old PID is gone, start the v2rayN instance you’re keeping and check whether it works. There’s no need to change ports just to troubleshoot.
-
Handle leftover processes
End a process from Task Manager → Details only after confirming its client has exited and the process is genuinely leftover. Don’t end every core process or stop an unknown system service.
If another program needs to keep running, leave it alone and change v2rayN’s local entry point instead. If the conflict returns after every reboot, check Task Manager → Startup apps for duplicate client entries that may compete for the same port when you sign in.
4. Change the listening port and update the system proxy
This guide uses 10818 as an example replacement for 10808. There’s no guarantee 10818 is free on your PC, so check it with the same command before using it. If your old configuration has a separate HTTP inbound, you can also check 10819. Don’t assign the same port to two separate listeners.
-
Pause proxy access
First, select Clear system proxy from the System proxy menu in the v2rayN tray. When troubleshooting a regular local proxy, turn off TUN for now so the two connection methods don’t affect the results at the same time.
-
Open the listening settings
Go to Settings → Parameter settings, then find Local listening port under Basic settings, or the corresponding SOCKS or HTTP listening field. Field names and groups vary by version, so match the available settings to the port shown in your logs.
-
Save the new port
Change the target listening port from 10808 to 10818, save, and restart the service. If there’s no separate restart option, exit the client normally and reopen it. Changing the number in the interface without reloading the core may leave the old listener in use.
-
Reconfigure the system proxy
Confirm the new port is listening, then select Set system proxy from the System proxy menu. Open Windows Settings → Network & Internet → Proxy and check that the manual proxy port matches the client’s HTTP or mixed inbound.
-
Update apps configured manually
Check manual proxy settings in browser extensions, download tools, and other apps one by one. Apps using SOCKS5 need the SOCKS or mixed inbound; apps using HTTP need the HTTP or mixed inbound. Match the protocol as well as the port number.
5. Check excluded port ranges if no process is found
If the logs keep showing a permissions-related bind error but no listener appears, open an elevated terminal and check Windows excluded port ranges. Virtualization or networking components can prevent regular programs from binding to certain ports; looking up a PID may not explain the issue.
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp- Compare the start and end ports in the results to see whether your target falls within a range. For example, if a range runs from 10800 to 10899, both 10808 and 10818 are included, so switching to 10818 may not help.
- Choose a candidate port outside the range, then check whether it already has a listener. Don’t delete system exclusions or stop an unknown networking service just to free a port.
- If the log shows an IPv6 address, check IPv6 as well. TCP and UDP listeners are separate; if the log specifically reports a UDP bind failure, also run
netstat -ano -p udpto check for matching entries. - If the port isn’t in an excluded range, check the logs for duplicate inbounds or whether another program grabs the port after startup. Follow your system administrator’s guidance for security policy issues; disabling security protections outright isn’t recommended.
Don’t use 0.0.0.0 as a universal fix for the listening address. It may expose the proxy more widely and won’t reliably avoid conflicts with wildcard binds. If you only use the proxy on this computer, keep it bound to loopback to limit access.
6. Verify the connection path
After applying the fix, verify the first two steps before checking whether the node works. Query port 10818 again; you should see a listening PID belonging to the relevant core. If the bind error no longer appears, the local listener is up—but that alone doesn’t confirm the remote connection is working.
- Check the old endpoint: If another program used the old port, it may still be listening, and that’s normal. What matters is that the new port belongs to the right process—not that the old port has disappeared.
- Check the system proxy: After setting it automatically, the system proxy port should match the current HTTP or mixed listener. If you only have a SOCKS inbound, don’t use it as the system’s HTTP proxy endpoint.
- Test an actual connection: Choose a known-working node and use a browser that follows the system proxy to open the page that was failing. Check the logs for the same time period to distinguish a refused local connection from a remote timeout or DNS error.
- Check after restarting: Exit and reopen v2rayN normally, then test again; restart the computer too if needed. If the problem returns only after sign-in, check for duplicate startup entries instead of repeatedly changing ports.
If the local listener is working but the logs now show a remote handshake error or connection timeout, the issue is further down the connection path. Check the node address, remote port, system time, and network environment. Don’t mistake two separate problems for a single “port 10808 in use” issue.
7. Port conflict FAQ
Why can’t my browser connect after I change the port to 10818?
First confirm that the correct process is listening on 10818, then select System proxy → Set system proxy again. If a browser extension is manually configured to use 127.0.0.1:10808, changing the system proxy won’t update the extension. Change its settings separately and make sure the HTTP or SOCKS5 type is correct.
The process using the port is Xray. Can I end it?
Use the PID and file location to confirm which client it belongs to, then exit normally from that instance’s tray menu. End the process only if the client has exited but the process remains. A running core holding a local port is normal.
Do I need to add 10818 to my router’s port forwarding rules?
Apps on your computer connecting to a loopback proxy don’t need router port forwarding. Forwarding a public router port to a local proxy won’t fix a listening conflict and could expose the proxy to more users. Keep the listener on 127.0.0.1 and troubleshoot the local port and process.
Why is the problem still there after reinstalling the client?
Ports are controlled by running processes or system rules; replacing client files won’t automatically free a port. Check the listening PID, duplicate startup entries, and excluded ranges first. Once you know the cause, changing the listening settings is more effective than reinstalling repeatedly—and makes it easier to keep working settings and pinpoint the issue.