For cases where v2rayN fails to start its core on Windows and the log shows bind or address already in use. First distinguish a port conflict from a permissions issue, then use netstat or PowerShell to identify the listening process. Check what it does before closing a duplicate instance or changing the local listening port. Finally, update your system proxy and app settings, then test the connection.
Check the log: Is the local listener failing?
A v2rayN window opening doesn't mean the proxy core started successfully. The interface manages your configuration; the core accepts local connections and connects to remote servers. If the log says it can't listen on 127.0.0.1:10808, the problem is at your local entry point. Repeatedly updating subscriptions or switching between VMess and VLESS nodes usually won't fix a listener failure.
Start with the log area in the main window. Note the full error line, especially the address, port, and system error at the end. Wording can vary by core, system language, and version. The examples below show common fragments from real errors; the entire line doesn't need to match exactly.
bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
Cause and fix: Another process is using the same listening address and port. Find the corresponding PID and check whether it's another v2rayN instance or a different local service. Then decide whether to close the process or use another port.
bind: address already in use
Cause and fix: The target socket is already in use. Check the port shown in the log for a listening process; don't check only the usual port 10808.
bind: An attempt was made to access a socket in a way forbidden by its access permissions.
Cause and fix: Windows refused the bind. This may be due to an excluded port range or a security policy, not an existing listener. If you can't find a PID, check the system's reserved ports.
Check the ports: 10808 and 10809 may not both be in use
Some older versions or configurations use 10808 for SOCKS and 10809 for HTTP. Others use a single mixed port for both HTTP and SOCKS traffic. Check the fields under Settings → Parameter Settings and the startup log for your current setup. Don't follow a tutorial by adding an entry that isn't already there.
The local listening port and server port are different settings. The Port field in a node editor controls the remote server connection; changing it won't fix a conflict on local port 10808. Leave the server address, user ID, transport, and TLS settings from your subscription unchanged.
Rule of thumb: Change only the conflicting local entry point
If the log reports 10808, first find what's listening on 10808. Check 10809 only if your current configuration has a separate HTTP entry point. Changing the node's remote port can cause a different connection problem.
Find the process: Identify the listener by PID
Open Windows Terminal or Command Prompt and run the commands below. You usually don't need administrator access for these checks. If the process path isn't visible, open a terminal as an administrator and try again. These commands only read network status; they won't stop any processes.
netstat -ano -p tcp | findstr ":10808"
netstat -ano -p tcp | findstr ":10809"Check whether the Local Address column ends with the port you're looking for and whether the state is LISTENING. Examples include 127.0.0.1:10808, 0.0.0.0:10808, and [::]:10808. Don't mistake 10808 in a remote address, or an old connection in TIME_WAIT state, for an active listener.
The last column shows the PID. The line below is a format example, not a result from a real device. The number 6420 only illustrates how to look up a process name; replace it with the PID shown on your screen.
TCP 127.0.0.1:10808 0.0.0.0:0 LISTENING 6420
tasklist /FI "PID eq 6420"Filter for a specific port in PowerShell
To avoid checking each line manually, filter by local port and listening state in PowerShell. No output usually means there was no matching TCP listener at the time of the query. It doesn't guarantee the port can be bound, and a process that keeps restarting may not show up.
Get-NetTCPConnection -State Listen -LocalPort 10808,10809 -ErrorAction SilentlyContinue |
Select-Object LocalAddress,LocalPort,OwningProcess
Get-Process -Id 6420 | Select-Object Id,ProcessName,Path- Found v2rayN or a core process: Check whether the client was launched from two different folders, or whether a core process was left running after the last exit.
- Found another app: Check the process path, window, and startup entries. You don't have to close a service you need; you can switch v2rayN to a free port instead.
- Found a system service or an unfamiliar process: Note its PID and path; don't force it to stop. Try changing v2rayN's local entry point first.
Resolve the conflict: Close the duplicate instance or change the local port
If the port is in use by a duplicate client instance, right-click its system tray icon and select Exit. Clicking the window's close button may only hide it, leaving the listening port active. After exiting, run the query again and confirm the old listener is gone before starting the v2rayN instance you want to keep.
- Note the current settings: Open Settings → Parameter Settings and find the local listening options. Depending on the version, the field may be called Local Listening Port, Local Mixed Listening Port, or something similar. Note the port, listening address, and whether there's a separate HTTP entry point.
- Check alternative ports: Run the command below to check 11808. Check 11809 only if you need a second, separate entry point. No listener is a good first sign, but confirm startup succeeds after saving your changes.
- Change the local entry point: Set the conflicting local listening port to 11808. If the interface has a separate HTTP port and that port is also in use, choose another free port for it, such as 11809. With a mixed-port setup, there's no need to add a second port.
- Save and restart: Save the settings to reload the configuration. If no new startup entry appears in the log, exit and reopen v2rayN, then check whether it's listening on the new port.
- Keep the listener local: If you only use the proxy on this PC, keep it bound to the loopback address. Don't enable Allow connections from the LAN to work around a port conflict. Widening the listening scope won't resolve it.
Get-NetTCPConnection -State Listen -LocalPort 11808,11809 -ErrorAction SilentlyContinue |
Select-Object LocalAddress,LocalPort,OwningProcess11808 and 11809 are example alternatives, not guaranteed-free ports. If another service is using one, choose a different high-numbered port that isn't in use or excluded by Windows. Port conflicts and routing rules are separate issues. You don't need to change GeoSite rules, DNS, or TUN mode while troubleshooting the port; changing those too just adds more variables.
No listening process found? Check Windows excluded port ranges
If netstat shows no listener but the log keeps reporting a permissions-related bind error, check Windows TCP excluded port ranges from an administrator terminal. Virtualization, containers, and Windows networking components can reserve ports; a reserved port may not have a visible listening PID.
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcpThe output lists a start port and an end port, and both endpoints are included. If a line shows 11700 to 11799, for example, 11750 falls within that range. This illustrates how to read the output; it doesn't mean Windows will necessarily reserve those ports. Check the results for the address family used by the listening address in the log.
- If an alternative port falls within an excluded range, choose a port outside that range, then save your settings and start the core again.
- Don't remove a system exclusion range or stop an unfamiliar networking service just to free up a local proxy port.
- If the port isn't in use or excluded but still won't bind, check security software events, core logs, and duplicate inbound configurations.
- Duplicate listening entries in the same configuration can also cause conflicts. If you're using a custom configuration, check the address and port combinations for its inbounds.
Verify the fix: Update system and manual proxy settings
Once the new port is listening, apps that use the proxy also need to point to the new entry. Otherwise, the core may be working while your browser still tries the old port, 10808, and can't load pages. In v2rayN, open the System Proxy menu at the bottom, select Clear System Proxy, then select Set system proxy to auto-configure so the client writes the current proxy address again.
For a mixed entry point at 127.0.0.1:11808, you can make a test request through the HTTP proxy from Windows Terminal. This uses curl.exe to avoid PowerShell environments where curl may be interpreted as a different command. If you have a separate HTTP entry point, replace the port in the command with its actual port.
curl.exe --proxy http://127.0.0.1:11808 --connect-timeout 10 --max-time 20 -I https://example.com/The 10-second value in the command is the connection timeout; 20 seconds is the overall request timeout. Neither is a speed test result. An HTTP response from the destination confirms that the local proxy entry and the rest of the route worked for this request. A message saying the proxy tunnel was established alone doesn't confirm that the destination page loaded. One successful request also doesn't mean every app is using the system proxy.
- Check the listener: Confirm the new port has a
LISTENINGentry and that its PID belongs to the core for the client you're using. - Check the log: Make sure the original bind error is gone. If you see a remote connection timeout, troubleshoot the node instead of continuing to change the local port.
- Check app settings: Browser extensions, developer tools, terminal environment variables, and other manual proxy settings won't necessarily update with the system proxy. Change each one to use the new address.
- Check after restarting: Exit and start the client again to confirm the port change was saved. Also check whether a system startup entry launches another client instance.
FAQ: Still not working after changing the port?
The window is closed. Why is 10808 still listening?
Check whether the v2rayN icon is still in the system tray. Closing the window may only minimize it to the tray; right-click the icon and select Exit. Then look up the PID again. If a listener remains, check for another instance in a different folder or a leftover core process, and handle only the process you've confirmed is responsible.
Nothing shows up on 10809. Does that mean the configuration is broken?
Not necessarily. If your current version uses a single mixed entry point, nothing may be listening on 10809. Check the entry point type under Settings → Parameter Settings. Use the port actually enabled for HTTP and SOCKS requests rather than relying on the defaults in an older tutorial.
The browser works on 11808, but the terminal doesn't. Why?
Check whether the terminal's HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY variables still point to the old port. Changing the client's port doesn't update proxy variables automatically; you usually need to open a new terminal after changing them. You can also try the command above with --proxy to specify the entry point directly and rule out environment variables.
Do I need to keep changing ports every time I start my PC?
No. Check Task Manager → Startup apps and the client's own startup settings, then keep only the startup entry you need. If the other item is a local service you need, assign a different port to each and keep those settings. Then update the proxy settings in your apps.