How to Fix a Port Conflict: Find the Process and Change V2Ray's Local Listening Ports

When v2rayN starts its core, it first creates inbound listeners on the local machine. The common defaults are SOCKS on port 10808 and HTTP on port 10809, usually bound to 127.0.0.1. If another process already occupies either port, the new Xray or V2Ray core cannot bind to it. Even a correctly configured node will remain unusable.

The right fix is not to reinstall the client immediately, but to work through the sequence: confirm the conflicting port, identify the process, determine whether it should remain, release the port or choose a new one, sync the system proxy, and test again. Changing the client port without updating the system proxy can turn a startup error into “the core is running, but webpages will not open,” so both sides must be checked together.

Confirm that it is a port conflict before troubleshooting the node

A port conflict occurs during local inbound setup, before the client connects to a remote VMess or VLESS node. The server address, UUID, transport, and routing rules have not yet taken part in communication; the client has already stopped because it cannot listen on the local port. Repeatedly updating subscriptions, switching nodes, or changing transport protocols usually will not change the result.

Open the v2rayN log panel and look for lines containing listen, bind, address already in use, or the specific port number. If the log only reports a connection timeout, TLS handshake failure, or remote connection refusal, troubleshoot the node path instead of the local port.

Find the processes using 10808 and 10809 on Windows

Exit v2rayN completely, then open it again. If the error persists, an old core process may still be running, or another proxy tool, development service, or security program may have taken the port. Do not force-close a process just because you found a PID; first verify its executable name and launch path.

Run the following commands in Terminal or Command Prompt. Query 10808 and 10809 separately, because different processes may be listening on the two ports.

netstat -ano | findstr :10808
netstat -ano | findstr :10809

Find the line whose status is LISTENING; the number at the far right is the PID. For example, if the result ends in 6420, query the process name with the task list command:

tasklist /FI "PID eq 6420"

In PowerShell, you can read listening connections together with their owning processes. Replace 6420 in the second command with the PID you actually found.

Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 6420 |
  Select-Object Id, ProcessName, Path

1. The result is a v2rayN core process that is still running: exit from the client first, then end the leftover core in Task Manager and start the client again.
2. The result is another local service that must remain running: keep it and assign v2rayN a different port.
3. The result shows multiple connections but no LISTENING entry. These are usually client connections using the port, not necessarily the process holding the listening endpoint.
4. If the query returns nothing but startup still fails, reopen an elevated terminal and check whether the address in the log is IPv4, IPv6, or a different port.

Stop the old process or assign the client a new port

If the process is a leftover Xray or V2Ray core from a previous abnormal exit, choose “Exit” from the v2rayN menu, wait about 5 seconds, and check the port again. Closing the client window does not always mean the background core has stopped, especially after waking from sleep, an interrupted core update, or multiple client launches.

Once you confirm that it is a leftover process, locate it by PID on Task Manager’s “Details” tab and end the task. PowerShell can also stop a specific PID, but run the command only after checking the process name and path:

Stop-Process -Id 6420

If the process must keep running, changing v2rayN’s local listening ports is safer. Choose an unused port from the 20000–50000 range, such as 20808 and 20809. Always query the ports first and confirm that no LISTENING entry exists.

netstat -ano | findstr :20808
netstat -ano | findstr :20809

• Stop the process: Use this for duplicate client instances, old cores whose main window is gone, and temporary services you have confirmed are no longer needed.
• Change the ports: Use this when a development server, another local proxy, or a long-running background service already reserves 10808 or 10809.
• Avoid trying random ports repeatedly: Query each port before changing it to reduce the chance of moving the conflict to another port that is already occupied.
• Keep the address scope explicit: For local-only use, keep 127.0.0.1. Do not switch to 0.0.0.0 just to bypass a conflict; changing the listening address does not resolve a port collision.

Change the ports in v2rayN and sync the system proxy

The wording in v2rayN 7.x may vary between minor releases, but the controls are located under “Settings.” Open “Settings” → “Parameter Settings,” then find Core basic settings or the local listening options and review the SOCKS port, HTTP port, and local listening address. Change 10808 to 20808 and 10809 to 20809, save, and restart the core.

If your version derives subsequent ports from one base port, change the base value as described in the interface. Do not create two conflicting sets of values in the configuration file and graphical interface. After saving, return to the log and confirm a successful listening message with no further bind errors.

1. Open “Settings” → “Parameter Settings” and note the listening address and ports before changing them.
2. Set the SOCKS port to 20808 and the HTTP port to 20809. If the interface provides only a base port, follow that version’s port instructions.
3. Save the configuration, choose “Restart service,” or exit and reopen v2rayN.
4. From the main interface, open the “System Proxy” menu and choose “Auto-configure system proxy” so v2rayN writes the current HTTP listening port to the system settings again.
5. Open Windows “Settings” → “Network & Internet” → “Proxy” and verify that the manual proxy address is 127.0.0.1 and the port has been changed to 20809.

Browsers generally use the Windows system proxy, while some programs have independent proxy settings. If a program was manually set to 127.0.0.1:10808, update that program after changing v2rayN. The subscription URL and the remote ports of VMess or VLESS nodes do not need to change with the local port.

How Android differs from other desktop platforms

When v2rayNG uses Android’s VPN service to handle traffic, other apps usually do not need to enter its local SOCKS listener directly. However, 10808 can still be occupied by a custom inbound, LAN sharing, or duplicate service. Stop v2rayNG’s connection first, close any old instance from the app switcher, then reopen it and start the current configuration.

The same port-conflict principles apply to v2rayNG with the Xray core and v2flyNG with the v2fly core: first find the exact listening address and port in the log, then check whether LAN access, a custom SOCKS inbound, or an additional HTTP inbound is enabled. Do not mistakenly replace a node’s remote port with a local port.

Complete verification sequence after changing the ports

A successful port fix means more than making the error window disappear: the core listener, system proxy, and actual requests must all agree. First verify that the current core is listening on the new ports, then verify the system proxy, and finally browse the network while watching for a new inbound connection in the log.

1. Check the listeners: Run netstat -ano | findstr :20808 and netstat -ano | findstr :20809, and confirm the status is LISTENING.
2. Verify the PID: Look up the listening PID and confirm that it belongs to the current v2rayN core, not another background service.
3. Verify the system proxy: The address should be 127.0.0.1, and the HTTP port should match the client’s current configuration, such as 20809.
4. Check the client log: After opening a webpage, a new connection record should appear. There should be no further listening failure or connection refusal on the old port.
5. Test routing: Visit destinations that should connect directly and others that should use the proxy, confirming that changing the ports did not alter the existing routing rules.
6. Test after a restart: Exit the client completely and start it again to confirm that an old instance does not claim the ports again.

netstat -ano | findstr :20808
netstat -ano | findstr :20809
tasklist /FI "PID eq actual PID"

If the listener is working but the network is still unreachable, investigate node availability, routing, and DNS. Do not keep changing local ports; the port layer has already been verified. Narrowing the issue by layer prevents node, DNS, and local inbound failures from being treated as the same problem.