v2rayN Port Conflict: Fixing 10808 and Changing Local Listener Ports

1. Confirm the local listener failed before changing nodes

Check the startup entries in the log area of the v2rayN main window. Look for listen, bind, and 127.0.0.1:10808. If the core hasn’t created a local entry point, requests can’t reach a node. Updating a subscription or changing the server port for VLESS or VMess won’t fix a local port conflict.

Error messages vary by system language and core version. Diagnose the issue by checking the local address, port, and meaning of the error. 127.0.0.1 is your computer’s loopback address, not the subscription server address. 0.0.0.0 listens on all IPv4 interfaces, so a port bound there may also conflict with a loopback listener.

2. Check what ports 10808 and 10809 do in your current setup

Go to Settings → Parameter Settings and check the local listener fields. Older setups with separate entry points often use 10808 for SOCKS and 10809 for HTTP. A mixed listener can handle both HTTP and SOCKS on the same port. Don’t assume both ports must be listening just because an older guide says so.

The local port determines how an app connects to the client. Routing rules determine which outbound route it uses; the remote node’s port determines where the core connects. Don’t change these interchangeably. The 11808 and 11809 ports used here are candidates, not guaranteed to be free.

3. Find the process using the port with netstat

Search for “Terminal” in the Windows Start menu and open PowerShell or Command Prompt. Run the two commands below. You can usually view connection records without elevated permissions; use an administrator terminal only if you need details about a protected process.

netstat -ano -p tcp | findstr ":10808"
netstat -ano -p tcp | findstr ":10809"

Focus on the Local Address column and the LISTENING state. The output below is an example format, not a result from your computer. The last column, 6420, is the PID. A process may listen on both IPv4 and IPv6.

TCP    127.0.0.1:10808    0.0.0.0:0    LISTENING    6420
TCP    [::1]:10808        [::]:0       LISTENING    6420

Use the actual PID from your results in the next command. If the only states shown are ESTABLISHED or TIME_WAIT, don’t assume those PIDs are causing a listener conflict. Make sure you matched the local port, not the address of a remote connection.

tasklist /FI "PID eq 6420"

1. Another v2rayN instance appears: check the system tray and Task Manager. If possible, exit the old instance from its tray menu.
2. A proxy core process appears: confirm which client it belongs to and where its file is located before closing it. Don’t stop the instance that’s working correctly.
3. Another app or system service appears: check what it does. If you still need it, leave it running and change v2rayN’s local port.
4. An unfamiliar process appears: find it by PID under Task Manager’s Details tab, then choose “Open file location.” Don’t guess based on the process name alone.

4. Close duplicate instances or change the local listener port

First, select “Clear system proxy” from the tray menu so apps don’t keep connecting to a broken entry point while you make changes. If you’ve confirmed that two instances were opened by mistake, exit the extra one and restart the instance you’re keeping. You may not need to change any ports.

1. Record the current settings

   Go to Settings → Parameter Settings and note the current local listener ports, whether LAN connections are allowed, and whether you’re using separate or mixed entry points. Field names may vary by version; use the options shown in your app.

2. Check candidate ports

   Use the method above to check port 11808. If your setup has a separate HTTP entry point, check 11809 as well. If either port is already listening, choose another pair of candidates rather than overriding another service.

3. Change the local entry point

   Under Settings → Parameter Settings, change the SOCKS port in the local listener settings to 11808. If there’s a separate HTTP port field, change it to 11809. If the app has only a mixed listener, change that entry to 11808; there’s no need to find or create a separate 11809 entry.

4. Save and restart

   Click OK to save, then restart the core if prompted. If the old values still appear, close and reopen v2rayN. Check the log afterward to confirm the new local address doesn’t produce another bind error.

5. Verify the new listener

   Query port 11808 and the HTTP entry point used in your setup. The listening PID should belong to the core currently running under your client. The old port disappearing doesn’t prove the new port started successfully.

netstat -ano -p tcp | findstr ":11808"
netstat -ano -p tcp | findstr ":11809"

If you use a custom configuration file, the listener address usually comes from inbounds, and the port shown in the UI may not override that file. Back up the file first, then check the loaded configuration’s listen, port, and protocol values. Otherwise, you may change the UI while the running core continues to use the old port.

5. Update system and app proxy settings

Once the core is listening on the new port, select “Set system proxy” from the v2rayN tray menu. Then check the active address under Windows Settings → Network & Internet → Proxy. “Set system proxy” doesn’t automatically update every app’s manually configured proxy.

If your browser has separate proxy settings, update them there too. Command-line tools don’t necessarily use the Windows system proxy. Check existing HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY environment variables, especially values that still contain 10808 or 10809. After changing user environment variables, open a new terminal before testing.

6. No listening process found? Check excluded ports and startup settings

If the port query returns no results but access-permission errors continue, check Windows TCP excluded port ranges in an administrator terminal. Virtualization, containers, or system networking components may use these ranges, and a standard listener query may not show a PID for them.

netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp

• Candidate port falls within the start and end of an excluded range: Choose a port outside that range and check for listeners again. Don’t remove a system exclusion just to set up a proxy entry point.
• Works when started manually, but conflicts after sign-in: Check Task Manager → Startup apps and any scheduled tasks you created. Make sure the same client isn’t being launched from two places.
• Port reappears immediately after exit: Query the PID again and check whether a background task is relaunching an old instance. Ending one process won’t fix the source of repeated launches.
• Only UDP reports an error: Check the port with netstat -ano -p udp. TCP and UDP are separate transport protocols; a TCP query alone can’t verify every entry point.

Changing the local port usually doesn’t require adding a firewall inbound rule. For local use, keep the listener bound to the loopback address. Changing it to 0.0.0.0 won’t fix a port conflict and may let other devices on your LAN access the proxy. Assess the access scope and firewall rules separately only if you need to share the proxy.

7. Verify the fix at three layers

Check the local TCP entry point first, then the app’s proxy settings, and finally the node connection. The PowerShell command below only checks whether a TCP connection can be made to a local port; it doesn’t verify the remote node, DNS, or routing rules.

Test-NetConnection -ComputerName 127.0.0.1 -Port 11808

1. Local: TcpTestSucceeded is True, the log shows no new listener errors, and the PID belongs to the correct core process.
2. App: The system proxy and any manual proxy settings point to the new port. Fully close and reopen the app you’re testing to rule out settings cached by an older process.
3. Outbound: Test the page or service you originally needed to access. If the local entry point works but the log shows remote connection timeouts, check the node address, subscription status, and network connection.

On Android, v2rayNG uses the Xray core, but its VPN permission and per-app proxy settings are separate from the Windows system proxy. The commands in this guide are for v2rayN on Windows and shouldn’t be used on a phone. Desktop troubleshooting doesn’t require changing phone settings unless the phone connects to this computer’s proxy over the LAN.