Use this guide if v2rayN reports a listener startup failure or your system proxy points to 10808 but won't connect. Note the address and port in the error, then identify the listening process with a system command. If you can't stop the process using the port, change v2rayN's local port and update every app that uses the old one.
First, confirm the conflict is with a local listening port
v2rayN's local SOCKS or HTTP listener accepts proxy requests from apps such as browsers and terminals. This is separate from the remote server port in your node settings. If the log reports a bind failure on 127.0.0.1:10808, check port 10808 on your computer—not the subscription link or node address.
Start by noting the full error from the v2rayN log, especially the protocol, listening address, and port. Your configuration might use 10808, 10809, or a manually changed value, so don't assume the port based on common defaults. If the error shows 0.0.0.0:10808, also check for processes bound to other local addresses on the same port.
A port conflict occurs at step two: the core hasn't successfully accepted a local connection. Switching VMess or VLESS nodes usually won't fix it. If the port is listening but only one node is unreachable, check the node status, routing rules, and DNS instead.
Error: bind: address already in use
Cause and fix: Another process is using the specified local address and port. Find the listening process, close the duplicate instance, or choose an unused port for v2rayN.
Error: Only one usage of each socket address is normally permitted
Cause and fix: Windows won't allow the same socket address to be bound twice. Use netstat to find the PID, then check whether that process still needs to run.
Error: connection refused 127.0.0.1:10808
Cause and fix: The app is still connecting to 10808, but no proxy is listening at that address. Check the current v2rayN port and update the app's proxy address. A refused connection doesn't necessarily mean the port is occupied.
Windows: Find the process using netstat and its PID
In Command Prompt, check ports 10808 and 10809 separately. netstat -ano lists local addresses, connection states, and PIDs. Look only for rows in the LISTENING state where the local address and port match the error. Seeing 10808 as a remote port doesn't indicate a local listening conflict.
netstat -ano | findstr :10808
netstat -ano | findstr :10809
tasklist /FI "PID eq 4321"In this example, 4321 is a sample PID. Replace it in the third command with the value in the last column of your results. findstr filters text and may match a nearby port or an existing connection. Verify the full local address and LISTENING state; don't terminate a process based only on the filtered results.
| Result | How to interpret it | Next step |
|---|---|---|
127.0.0.1:10808、LISTENING | The process is listening on the target local address. | Look up the program name by PID and check whether it's another v2rayN instance. |
0.0.0.0:10808、LISTENING | The process is listening on that port across all local IPv4 addresses. | Identify what the process is used for before deciding to stop it or change ports. |
Only ESTABLISHED rows | These results don't show a process listening on the target address. | Check the port in the log again, then repeat the query as you restart the core. |
You can also filter by local port and listening state in PowerShell. First find OwningProcess, then look up the process name. If another service in use owns the port, change the port in v2rayN if possible. Don't stop a system process if you don't know what it does just to free the port.
Get-NetTCPConnection -LocalPort 10808 -State Listen
Get-Process -Id 4321macOS and Linux: Check listening addresses with lsof
When running lsof in Terminal, -nP keeps addresses and ports numeric so you can compare them directly with the log. -sTCP:LISTEN limits results to TCP listeners. Try without sudo first; if permissions hide process details, run the command again with administrator privileges.
lsof -nP -iTCP:10808 -sTCP:LISTEN
lsof -nP -iTCP:10809 -sTCP:LISTEN
sudo lsof -nP -iTCP:10808 -sTCP:LISTENIn the output, COMMAND is the process name, PID identifies the process, and NAME shows the listening address. If you see 127.0.0.1:10808, *:10808, or an IPv6 listener, compare it with the bind address in the v2rayN log to determine the scope of the conflict. A previous instance may have closed while its core process is still running.
No output means only that no TCP listener matched the filters when you ran the command. Another program may have grabbed the port just as the core started, or the error may refer to a different port. Keep the full error text and query again while restarting the core.
Before stopping a process, identify where it came from and use its normal shutdown method. If a local service that needs to stay running is using the port, choose an unused port instead. Port numbers aren't speed settings: changing 10808 to 20808 won't make the remote connection faster.
Change the port in v2rayN and update proxy settings
For example, change the SOCKS listener from 10808 to 20808 and a separately configured HTTP listener from 10809 to 20809. Depending on the version, the interface may call these local listening, SOCKS, or HTTP ports. Check the current fields before changing the relevant listener. If your setup has a single mixed-proxy listener, don't assume it has a second port based on this example.
Note the current ports
Check the system proxy status on the v2rayN main screen and note the local listening ports under Settings → Parameters. Also note the
127.0.0.1ports used by your browser and terminal so you can update each one.Check the new ports
Use the system commands above to check 20808, and check 20809 if you use a separate HTTP listener. Finding no listener is only a preliminary check; after saving the settings, verify that the core can bind successfully.
Change the listening port
Go to Settings → Parameters and change the local SOCKS listening port associated with the error to
20808. If the interface has a separate HTTP port and that listener is enabled, change it to20809, then save your settings.Restart the core
Restart the core from the v2rayN interface and check the new log for bind errors. Then use
netstatorlsofto check the new port and confirm that a listener is present.Update your apps
Reapply the system proxy settings in v2rayN. For browsers, terminals, and other desktop apps with manually configured proxies, change the old port to the corresponding new one in each app. If you change the port in v2rayN but not in your apps, they'll keep connecting to the old listener.
If your browser uses the system proxy, check its server address and port after reapplying the system proxy. If it has a separate proxy configuration, update it in the browser's network or proxy settings. Point HTTP proxies to the enabled HTTP or mixed listener, and SOCKS5 proxies to the enabled SOCKS or mixed listener. Make sure the protocol matches—not just the port number.
Verify the new port and rule out “listening but no internet”
Verify in two steps: first, confirm that the expected process is listening on the new port; then send a request through that port from an app. The curl commands below test separate HTTP and SOCKS5 listeners. Run only the command for a listener that's actually configured. socks5h resolves the destination hostname through the proxy, avoiding interference from your computer's DNS results during this test.
curl -I --proxy http://127.0.0.1:20809 https://example.com
curl -I --proxy socks5h://127.0.0.1:20808 https://example.comIf the command returns connection refused, first check that a listener is present, the address is 127.0.0.1, and the port and protocol are correct. If the request reaches the core but then times out, investigate node connectivity, routing rules, or DNS instead of changing the local port again.
Why does my browser still fail to connect after changing the port to 20808?
Check whether your browser uses the system proxy or has its own proxy settings. A standalone setting such as 127.0.0.1:10808 won't update when you change v2rayN parameters. Change it to the listener that's actually enabled, then reload the page and test again.
Why does curl still use the old address after I change the port in Terminal?
Check HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and their lowercase equivalents in the current terminal session. Also check whether the command specifies --proxy directly. After updating the variables, run the test again in the same terminal session.
netstat shows that v2rayN is using the port. Can I just terminate it?
First, check whether two v2rayN instances are open, then quit the extra one normally through its interface. Confirm that the old core process has exited, start just one instance, and check the listening PID again.
What if the port is listening but all subscription nodes time out?
A working local listener confirms only that apps can connect to the proxy. Check the core log and current node status in v2rayN, then investigate the subscription, connection to the remote server, and routing rules separately. A remote timeout isn't a local port conflict.
Finally, make sure the system proxy and any manually configured proxies all point to the same new ports. If you set terminal proxy environment variables, close and reopen the terminal, then check that the port in its startup configuration is also up to date. Keep a record of the original ports. To revert, first confirm they're no longer occupied, then restore the corresponding settings in v2rayN and each app.