How to fix a port conflict in Clash Verge Rev

This guide applies only when the log explicitly shows address already in use, Bind failed, or Start Mixed(http+socks) server error. The 7890 and 1053 values in the issue reports are examples; use the mixed-port, DNS, or external-controller port from your own log while troubleshooting.

The Mihomo documentation describes mixed-port as the local inbound that accepts both HTTP(S) and SOCKS requests. If the new core cannot bind to it, the system proxy will not get a working new connection even if it still points to that port.

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.

First turn off TUN and the system proxy, confirm that the device can connect without Clash Verge Rev, and then exit the client completely from the tray. Save the current Profile, port settings, and failure log; do not refresh subscriptions or change rules while isolating the problem.

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.

A port conflict is not a process-name guessing game. Find the PID first, then check the process name, owner, start time, and executable path so you can distinguish the active core from a leftover old core or an unrelated program.

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.

Terminate a single process only after confirming that its PID belongs to a leftover verge-mihomo from an exited client. Start with a normal termination request and query the port again; do not begin with a broad pkill command or a force signal.

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.

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.

Confirm that the target port is free before launch, then start Clash Verge Rev and check that only one expected core is listening. Next, replace the example port with the current mixed-port, make a real HTTPS request through the local proxy, and verify the entry in Connections.

Enable TUN only after the system proxy path has passed verification. If the connection fails only when TUN is enabled and the log contains no bind error, switch to troubleshooting TUN, DNS, and routing instead of continuing to change mixed-port.

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.