Fix Clash Verge Rev address already in use errors

On this page

Author: Clash Official
Published: September 5, 2026
Updated: October 14, 2026
Estimated reading time: About 10 minutes

Closing a window may leave the proxy core or another local program holding the same port. A new program failing to start does not mean the subscription is damaged. Match the actual port to its owning process, then address only the confirmed conflict while preserving connections that still work.

address already in use: which actual port failed to bind?

Keep the address already in use, Bind failed, or Start Mixed(http+socks) server error messages and note the local port they identify. These errors mean the new program did not complete its port binding.

A port is the numbered entry where a program receives requests. Use the mixed-port, DNS, or external-controller value in your own logs; 7890 and 1053 in the reports are only examples.

The Mihomo documentation defines mixed-port as the local inbound for both HTTP(S) and SOCKS requests. If the new core cannot bind it, that core has not taken over the inbound. An existing listener may still handle requests, so check the actual process using the port and the connection records.

Clash Verge Rev issue #7861 documents verge-mihomo running as root continuing to hold the mixed-port and DNS ports after the GUI exits abnormally under Service Mode on macOS. Issue #6741 documents the old and new cores competing for mixed-port after logging back in on Linux.

Both remain open issues. Their root-cause analyses come from the reporters and should not be presented as a general conclusion confirmed by the maintainers.

Start Mixed(http+socks) server error: listen tcp :7890: bind: address already in use
Start DNS server(TCP) error: listen tcp 0.0.0.0:1053: bind: address already in use
Start DNS server(UDP) error: listen udp 0.0.0.0:1053: bind: address already in use

Branch from the first error

Log or symptom	More likely direction	Next step
Only mixed-port reports address already in use	An old client, another program, a leftover core, or a Windows reserved port	Identify the actual listener
Both mixed-port and the DNS port fail	Another core is more likely to be holding the whole port set	Check the process owner and start time
Only the external-controller port conflicts	The control interface or Dashboard is using the same port	Check the controller port separately
The log shows only connection refused, with no bind error	Nothing is listening on the destination port; the port is not occupied	Troubleshoot core startup and configuration
Only one website fails to open	A rules, DNS, or node problem	Do not terminate a process using this guide

After the client quits, has the port been released?

Turn off TUN and the system proxy, confirm the device can connect without Clash Verge Rev, then fully quit from the tray. Save the current Profile, port settings and first failure log without updating subscriptions or rules. Hide subscription URL values, passwords and secret values before public feedback.

After exiting, wait a few seconds and check the port again. If the listener has disappeared, start the client only once and observe it. Continue identifying the owner only if the port remains occupied.

Identify the program using the port by its PID, the account running it, and its path

Do not identify the program using a port by its process name alone. Find the PID (process ID), then check the process name, owner (the account running it), start time, and program path. This distinguishes the current core working normally, an old core left behind after exit, and unrelated programs.

The 7890, 1053, and 12345 values below are examples. Replace them with the ports from your log and the PID you just identified before running anything. If a read-only query returns no result, do not terminate random processes just to produce one.

$Port = 7890
$Tcp = Get-NetTCPConnection -LocalPort $Port -State Listen -ErrorAction SilentlyContinue
$Tcp | Select-Object LocalAddress, LocalPort, OwningProcess
$Tcp | ForEach-Object {
  Get-Process -Id $_.OwningProcess | Select-Object Id, ProcessName, Path
}
Get-NetUDPEndpoint -LocalPort 1053 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess

PORT=7890
sudo lsof -nP -iTCP:${PORT} -sTCP:LISTEN
sudo lsof -nP -iUDP:1053
ps -o user,pid,ppid,lstart,command -p 12345

sudo ss -ltnp 'sport = :7890'
sudo ss -lunp 'sport = :1053'
ps -o user,pid,ppid,lstart,cmd -p 12345

What should you do if another program or a leftover core occupies the port?

The port belongs to another Clash client, VPN, development server, or local proxy

Exit that application normally from its own interface, or configure the two programs to use different ports. Do not stop an unknown system process.

Clash Verge Rev has exited, but the port still belongs to verge-mihomo

This matches the signs of a leftover core. Save its PID and owner, then follow the platform-specific method below to terminate only that PID. Do not stop other processes with the same name.

The process belongs to root or an administrator and reappears immediately after being stopped

Do not repeatedly force-kill it; move to the client's Service Mode repair or reinstall workflow.

A conflict appears intermittently after logging in again or rapidly restarting the client

The new core may have started before the old core finished exiting. Disable duplicate autostart entries, then start the client only once to test.

Windows shows no listener, but the port still cannot be bound

Check whether the port falls within a Windows excluded port range.

Terminate the process and recheck the port only after confirming that the PID belongs to a verge-mihomo left behind after client exit. On macOS/Linux, send TERM first. On Windows, Stop-Process terminates the process directly; -Confirm only adds a confirmation prompt. Do not use a broad pkill or stop a core that is still forwarding traffic normally.

# 把 12345 换成刚才确认的 PID
sudo kill -TERM 12345

# 把 12345 换成刚才确认的 PID
Stop-Process -Id 12345 -Confirm

On Windows, check reserved ports when no listener appears

In the Windows report in issue #6947, changing the port and restarting the system proxy restored connectivity. A project collaborator also recommended checking the Mihomo log for Bind failed and inspecting the Windows or Hyper-V reserved ports. Follow this branch only when no listening process appears but the log still clearly reports a bind failure.

If the current mixed-port falls inside a reserved range, choose a new port in Clash Verge Rev that has no listener and is outside the reserved range, then return to the home screen and enable the system proxy again. Changing only the port without identifying its owner will not resolve a leftover core that is still running.

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

# 17890 只是示例，不能保证每台电脑都可用
Get-NetTCPConnection -LocalPort 17890 -ErrorAction SilentlyContinue
Get-NetUDPEndpoint -LocalPort 17890 -ErrorAction SilentlyContinue

Repair Service Mode if a leftover core keeps returning

The Clash Verge Rev v2.5.2 source provides service install, uninstall, reinstall, and repair commands. The repair path performs a forced reinstall and waits for service IPC to recover. Button labels can differ by operating system and build, so use the Service Mode controls in your current client settings rather than deleting service files manually.

The v2.5.2 release notes mention more robust service lifecycle management, but that does not prove the stable release completely fixes the leftover-core and port-race reports filed afterward. This guide is a recovery path, not a release fix announcement.

Service Mode recovery sequence

Keep a direct connection available
Turn off the system proxy and TUN, then confirm that the system can still connect while the client is stopped.
Save the diagnostic results
Record the port, PID, process owner, client version, and first bind error.
Use the controls in the client
You can disable or uninstall the old service in the current client’s service-mode settings. On Windows, repair, reinstall, or enable it only after confirming that the service component meets the fix requirements in the official security advisory; keep it disabled if unconfirmed. On other systems, use the client’s uninstall, repair, or reinstall controls and wait for the permission prompt and operation to finish.
Restart the system if necessary
If an administrator-level core still holds the port, restart the system, confirm the port has been released, and only then launch the client.
Restore one feature at a time
Start with the original Profile and system proxy. Once those work, restore TUN only if needed.

Verify the port, proxy, and port release after exit

# 把 7890 换成当前 mixed-port
curl -I -x http://127.0.0.1:7890 https://example.com

Completion criteria

No unknown listener occupies the target port before startup
After startup, only one expected verge-mihomo listens on mixed-port
The new log no longer shows address already in use or Bind failed
A curl request through mixed-port receives an HTTP response
The system proxy points to the current actual port, and Connections shows the test request
The port is released after a normal client exit, and the system proxy can be restored
No second leftover core appears after another launch or login

Enable TUN only as needed after a real HTTPS request works through the system proxy. If networking fails only with TUN and logs show no binding error, check DNS and routes instead of changing mixed-port again.

If changing ports or reinstalling the service fails, restore direct access and keep evidence

If changing the port or reinstalling the service makes the problem worse, turn off the system proxy and TUN so the device stays on a direct connection. Restore the original port only after it has been released. If service reinstallation fails, keep Service Mode disabled and do not continue deleting system files manually.

When reporting the problem upstream, describe your local conclusion as an observation instead of declaring a root cause on the maintainers' behalf. Do not upload a complete configuration, subscription URL, node password, controller secret, or unredacted log.

Keep this evidence before filing an official issue

Full Clash Verge Rev version and installation source
Operating system version and CPU architecture
Whether Service Mode, TUN, and launch at startup are enabled
Whether the GUI exited normally, crashed, or was force-quit
The first address already in use log entry and actual port
The listener's PID, owner, start time, and executable path
Whether the port is released after exiting and whether the problem returns after service repair

How to fix a port conflict in Clash Verge Rev