Clash Port Already in Use: How to Find the Conflicting Process and Change the Mixed Port

Clash clients (including the various offshoots built on Clash Meta / mihomo cores) listen on one or more local ports at startup to receive proxy traffic forwarded by the system or browser. The most common one is mixed-port (the mixed port), usually defaulting to 7890, which handles both HTTP and SOCKS5 connections at once — replacing the older setup where you had to configure port (HTTP) and socks-port (SOCKS5) separately. There's also the external-controller port used for the dashboard/API, commonly set to 9090.

When the client tries to bind these ports at startup and the OS reports that the port is already held by another process, it throws a bind: address already in use error and either aborts startup or shows a connection failure in the UI. This is an OS-level exclusivity rule: only one process can hold an exclusive listener on a given TCP port at any moment — whoever grabs it first wins, and everyone else gets rejected.

The exact commands for checking port usage differ across operating systems, but the logic is the same everywhere: look up the port to get the process ID (PID), then look up the PID to find out which process it actually is.

Windows

Open Command Prompt or PowerShell and run:

netstat -ano | findstr :7890

The last column in the output is the PID — say it's 12480. Run:

tasklist /FI "PID eq 12480"

This shows the name of the process holding the port. It's often a leftover clash.exe, clash-verge.exe, another proxy tool's executable, or a forwarding component from some security software.

macOS / Linux

macOS and most Linux distros ship with lsof built in. Run:

lsof -i :7890

The COMMAND column is the process name, and PID is its process number. If lsof isn't available, Linux users can also try:

netstat -anp | grep 7890
# or use the newer ss command
ss -ltnp | grep 7890

Note that netstat -anp often needs sudo on some distros to actually show process names — otherwise the PID column comes back blank.

Once you've identified the process holding the port, don't just kill it on reflex. Figure out who it is and why it's running first, then decide how to handle it.

1. It's a leftover Clash process. This usually happens when you closed the client window last time but the background process didn't fully quit, or a crash left a zombie process behind. Just kill this one and restart the client — no config changes needed.
2. It's another proxy or VPN tool running in the background. Maybe you've got two proxy clients installed, or a company-mandated VPN component that's been squatting on the same port for a while. These processes are usually kept around on purpose, so force-killing them could break something else. The safer move is to change Clash's port instead, so you don't have to deal with this every time you boot up.
3. It's a system service or container port mapping. Some routing software, Docker containers, or local dev servers happen to use the same port range. These aren't usually safe to just kill, so again, changing Clash's port to get out of the way is the better option.

Most GUI clients have a port setting built in — usually under a "Settings" or "General" tab where you can change the mixed port value directly, and the client restarts its listener automatically after you save. If your client doesn't offer this option, or you're editing the config file directly, find and change this line in your YAML:

mixed-port: 7891
external-controller: 127.0.0.1:9091

Just change the default 7890 to any port number that isn't currently in use — 7891 or 17890 are common picks since they rarely clash with other common software. If your config still uses the older-style port (HTTP) and socks-port (SOCKS5) instead of mixed-port, remember to update both and make sure they're different from each other, or you'll hit the same bind failure again.

After making the change, you need to fully restart the client (not just reload the config) — port binding happens during process startup, and a hot config reload usually won't re-bind the listener.

If you were connecting through "system proxy" mode (rather than TUN mode, which takes over all traffic) before changing Clash's port, you also need to update the port recorded in your system's proxy settings — otherwise your browser and other apps will keep sending requests to the old port and get flat-out refused.

• Windows: update the port field under manual proxy in Settings → Network & Internet → Proxy. If your client has an "auto-configure system proxy" toggle, it usually rewrites this automatically after a restart, so you won't need to touch it manually.
• macOS: under System Settings → Network → [your network interface] → Details → Proxies, update the port for both Web Proxy (HTTP) and Secure Web Proxy (HTTPS).
• Linux: if you're setting the proxy via environment variables, update the port number in http_proxy, https_proxy, all_proxy, and similar variables, for example:

export all_proxy=http://127.0.0.1:7891
export http_proxy=$all_proxy
export https_proxy=$all_proxy

If you're using a PAC auto-configuration script or the system's "auto-detect settings" option, you usually don't need to change anything manually — but it's still worth opening a browser and visiting a site afterward to confirm the proxy is actually working, so a silently broken proxy doesn't slip past you.

First: if you only changed mixed-port and forgot to update the external-controller port, and 9090/9091 happens to also be taken, the client's dashboard won't open — but proxy forwarding is actually working fine. Don't mistake this for "the config broke again." Second: some clients cache the port number in a local config snapshot. If you edit the YAML file directly but the client keeps reading the old value from cache, try manually clearing or re-importing the config in the client to make sure the new port actually takes effect.