Use this guide if v2rayN reports that binding to port 10808 failed when starting the core, or your browser is still using the old port. First confirm the error concerns a local listener, then identify the process by PID. If it is a duplicate instance, exit it and keep the original port; otherwise, switch to an available port such as 10818. Update your system proxy, browser, and command-line tools, then test the local listener and remote access separately.
First, tell a local listening failure from a node connection failure
127.0.0.1:10808 is your local proxy endpoint, not a subscription server address or a node's remote port. Being able to open the v2rayN interface does not mean Xray started successfully. If the core cannot bind to the endpoint, the interface may still show your node list, but your browser will have no local proxy to connect to.
Start troubleshooting at the left side of the connection path. Open the v2rayN log and look for listen, bind, and 10808 entries around the startup time. Follow this guide only if the error explicitly identifies a listening address. Remote connection timeouts, certificate errors, and subscription update failures won't be fixed by changing the local port at random.
bind: address already in use
Cause and fix: Another process is already listening on the target address and port. Identify it, exit a duplicate instance, or set v2rayN to a confirmed available port.
Only one usage of each socket address (protocol/network address/port) is normally permitted.
Cause and fix: Windows won't allow the same socket address to be bound twice. Check the IP, TCP or UDP protocol, and port shown earlier in the log. Don't assume a conflict based on the port number alone.
An attempt was made to access a socket in a way forbidden by its access permissions.
Cause and fix: The issue may involve an excluded system port range or a security policy, rather than a process listening on the port. If no listener is found, check for port reservations.
Windows: Find the process with netstat
Open PowerShell or Command Prompt and run the query below. These commands only inspect the current state; they won't stop any programs. If you can't view a process path, reopen the terminal as an administrator and try again.
netstat -ano -p tcp | findstr ":10808"
netstat -ano -p udp | findstr ":10808"
For TCP, check the Local Address column and the LISTENING state. A text filter may also match a remote address or a longer port number that starts with the same digits, so don't assume every result indicates a conflict. UDP doesn't have an equivalent listening-state column; focus on its results only if the log reports a UDP bind error.
TCP 127.0.0.1:10808 0.0.0.0:0 LISTENING 6420
This is an instructional example, not output from your computer. The final number, 6420, is a sample process ID (PID). Replace it with the value in your own output. To filter specifically for the TCP local listening port in PowerShell, run:
Get-NetTCPConnection -LocalPort 10808 -State Listen -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, State, OwningProcess
tasklist /FI "PID eq 6420"
Get-CimInstance Win32_Process -Filter "ProcessId=6420" |
Select-Object ProcessId, Name, ExecutablePath, CommandLine
- Leftover core in the same folder: Exit v2rayN from the system tray menu, wait a few seconds, then check whether the port has been released.
- Copy launched from another folder: Use the process path to find its window or tray icon, then exit the copy you don't need. This prevents two startup entries from competing for the same port.
- Another application you need: Leave it running and change the v2rayN port. Don't force-quit a working process just to free the proxy endpoint.
- System process or unknown purpose: Check where the process came from and which service owns it. Don't force-terminate it without investigating.
macOS and Linux: Check listeners with lsof
The v2rayN desktop interface may vary slightly between systems, but the same approach applies to listening conflicts. On macOS, use lsof. On Linux, you can use the same command if the tool is installed. Run separate queries for TCP and UDP:
lsof -nP -iTCP:10808 -sTCP:LISTEN
lsof -nP -iUDP:10808
In the output, COMMAND is the process name, PID is its process ID, and NAME shows the listening address. On Linux, you can also run the command below to view TCP listeners and process details. If you don't have permission to see process information, query from an elevated terminal in accordance with your system's administration policies.
ss -ltnp 'sport = :10808'
ps -p 6420 -o pid,comm,args
- Exit the application normally from its menu, then run the query again. Don't start by force-quitting it.
- Closing a window doesn't necessarily stop a background service. Check the system tray, menu bar, or service manager as well.
- If a service manager automatically restarts the process, adjust that service's configuration or change the v2rayN port instead of repeatedly terminating the process.
Change the v2rayN local listening port
This example changes 10808 to 10818. Port 10818 is just an easy-to-recognize example, not a guaranteed free port. First, change the query above to check 10818. Once you've confirmed there are no relevant listeners, open settings. Before making changes, note the current port, listening address, and whether connections from your LAN are allowed.
-
Note your current settings
Open Settings → Parameter Settings and note the current local port under Basic Settings. Labels vary between versions; in the 7.x interface, look for the Core: Basic Settings section and the Local Mixed Listening Port field. Use the labels in your current version as your guide.
-
Enter an available port
Change Local Mixed Listening Port to
10818. If your version shows separate local SOCKS and HTTP ports, note and update the relevant fields individually. Don't assign the same port to two separate listeners. -
Keep the listener on loopback
For local use only, keep the listener bound to a loopback address. Don't enable Allow connections from the LAN to resolve a port conflict. Widening the listening scope won't free a port that's already in use, and it changes who can access the endpoint.
-
Save and restart
Click OK to save. If the core doesn't restart automatically, exit v2rayN normally from the system tray menu and launch it again. Then check port 10818 and confirm the new listener belongs to the core started in this session.
-
Reset the system proxy
In the system tray menu, open System Proxy, select Clear System Proxy, then select Auto-configure system proxy. This rewrites the current proxy address; it doesn't change direct or proxy routing modes.
The earlier 6.x interface differs from later versions in its separate HTTP endpoint, mixed endpoint, and field names. Don't assume that HTTP always uses port 10809: a mixed endpoint can accept both HTTP and SOCKS requests on the same port, while separate endpoints must be entered according to your actual configuration. Don't edit temporary core configuration files generated automatically; the interface may overwrite those changes when you save settings or switch nodes.
Update your browser, system proxy, and command-line tools
A common oversight after changing the port is that the core listens on 10818 while an application still connects to 10808. The system proxy affects only programs that follow its settings. Check apps with manually configured proxies, environment variables, and one-off command-line arguments separately.
| Proxy entry | Where to check | Value in this example |
|---|---|---|
| Windows system proxy | Settings → Network & Internet → Proxy: check the manual proxy address and port | Address: 127.0.0.1; port: 10818 |
| Browser proxy set manually | The active configuration in the browser's connection settings or proxy extension | Enter HTTP or SOCKS5 according to the endpoint type; port 10818 |
| Command-line tools | HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and command-line arguments | Replace any values that still point to 10808 |
| Other applications | The app's Network or Proxy settings | Reconnect after saving |
If you use a PAC script, check not only whether the script URL has changed, but also which proxy port the script actually returns. Your browser may cache an old script or reuse existing connections. Reload the script or restart the relevant app after updating the configuration. Don't let an app's manual proxy and the system proxy point to different ports, then assume everything is working because a page occasionally loads.
# Windows PowerShell: Check proxy environment variables in the current terminal
Get-ChildItem Env: | Where-Object Name -Match '^(HTTP|HTTPS|ALL|NO)_PROXY$'
# macOS / Linux: Check proxy environment variables in the current terminal
env | grep -iE '^(http|https|all|no)_proxy='
Environment variable changes usually affect only processes started afterward. Existing terminals, editors, and downloads may keep the old values. If you find a variable, update it where it's actually set, such as a terminal configuration file or the system environment variables interface, then reopen the relevant app. Don't stop troubleshooting after changing a temporary value in just one terminal.
Verify the result: a local connection doesn't prove remote access works
Test in two stages: first confirm that the local endpoint is available, then test a proxy request. In Windows PowerShell, start with the command below. If TcpTestSucceeded is True, it only means a TCP connection to the port can be established; it doesn't confirm that subscriptions, nodes, or DNS are working.
Test-NetConnection 127.0.0.1 -Port 10818
If 10818 is a mixed endpoint, you can test HTTP and SOCKS separately. The requests below use a documentation example domain; they aren't a node speed test or a guarantee of availability. In Windows PowerShell, use curl.exe explicitly to avoid older environments interpreting curl as a different command. On macOS and Linux, use curl.
curl.exe --noproxy "" --proxy http://127.0.0.1:10818 --connect-timeout 10 --max-time 20 -I https://example.com/
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10818 --connect-timeout 10 --max-time 20 -I https://example.com/
- Connection refused immediately: Check the port, address, and whether the core is still running. Don't switch nodes yet.
- The endpoint connects, but the request times out: Check the core's DNS, routing, and outbound logs. The local binding issue may already be resolved.
- The command succeeds, but the browser fails: Check the proxy configuration the browser is using, its PAC cache, and existing connections.
- Only HTTP or SOCKS fails: Confirm whether the port is a mixed endpoint or a dedicated protocol endpoint. Don't mistake a protocol mismatch for a port conflict.
Common questions: What if no process appears, or the issue returns after a restart?
Why does the port still appear unavailable when netstat shows no results?
First confirm that the log is from the current startup, then check the IP version (IPv4 or IPv6) and protocol (TCP or UDP). On Windows, run the command below to check the TCP excluded port ranges. If 10808 falls within a range, use a port outside it that also has no listener. Don't delete system reservations directly.
Does port 10808 get occupied again every time you restart your computer?
Check Settings → Apps → Startup in Windows, as well as Task Scheduler, for entries that launch v2rayN from different folders. Keep the copy you actually use and verify the full path of the process occupying the port. Don't identify it by process name alone.
Will changing the port to 10818 affect VMess or VLESS nodes?
The local listening port and a node's remote port are separate settings. Changing the local endpoint doesn't require changing the VMess or VLESS server port in your subscription or generating a new user ID. Update only the apps that connect to your local proxy.
Can enabling TUN or running as an administrator bypass the conflict?
TUN works differently, but the core may still start a local inbound listener, so it doesn't guarantee that a duplicate bind will be avoided. Administrator privileges won't release another process's socket either. First fix the listening failure identified in the log, then check TUN routing and DNS separately.
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp