Clash Port Already in Use: How to Find and Fix the 7890 Conflict

How Port Conflicts Happen

When the Clash core starts up (whether the original Clash or Mihomo), it binds to a local port to receive proxy traffic, with 7890 as the common default. In the config file this corresponds to the mixed-port field (older versions split this into separate port and socks-port fields, but most clients now use a unified mixed-port that supports both HTTP and SOCKS5). If another process already has that port, the core fails to bind, and the log typically shows something like this:

ERRO[0000] Start HTTP server error: listen tcp 127.0.0.1:7890: bind: address already in use

The cause is simple: only one process can listen on a given port at a time. Conflicts usually fall into three categories. First, duplicate launches — a previous Clash process didn't shut down cleanly, and a new instance is trying to start while the old one still holds the port. Second, the port is taken by unrelated software — other proxy tools (v2ray, trojan, other Clash forks), local dev servers, or even ports exposed by containers. Third, two Clash-related services are running on the same machine at once — for example, a system-level clash service alongside a manually started test instance.

Whatever the cause, the approach is the same: first identify exactly what's holding the port, then decide whether to kill it or have Clash use a different port instead.

Finding the Culprit with ss / lsof / netstat

There are three common Linux tools for checking port usage — pick whichever you have. ss is recommended first since it's built into most modern distros and performs best.

Method 1: ss

sudo ss -tulnp | grep 7890

The output shows the local address, port, and the name and PID of the process holding it, something like:

tcp   LISTEN 0      4096   127.0.0.1:7890   0.0.0.0:*   users:(("mihomo",pid=8123,fd=12))

The pid=8123 in parentheses is the PID of the process holding the port, and "mihomo" is the process name. If it turns out to be Clash's own core process (mihomo or clash), that means the previous instance didn't exit cleanly — just kill the old process and restart the client.

Method 2: lsof

If ss isn't installed, or you prefer lsof, run:

sudo lsof -i :7890

This lists fields like COMMAND, PID, and USER, giving you the same process name and PID. lsof may need to be installed separately on minimal distros — use sudo apt install lsof on Ubuntu/Debian, or sudo dnf install lsof on Fedora.

Method 3: netstat

netstat is gradually being replaced by ss on newer distros, but plenty of scripts and older tutorials still rely on it:

sudo netstat -tulnp | grep 7890

All three commands give you essentially the same information — pick whichever works on your system, no need to install all of them.

Note

If grep returns no output at all, port 7890 isn't actually in use. The error is more likely caused by a misconfigured address elsewhere in the config file (such as an incorrect bind-address), or a permissions issue preventing the bind — not a port conflict. In that case, check the full startup log instead of continuing to chase the port.

Deciding Whether to Kill the Process or Change Ports

Once you've identified the process, how you handle it depends on what it actually is.

It's a leftover Clash/Mihomo process: this means the previous instance didn't shut down properly. Just kill that PID and restart the client — no config changes needed.
```
sudo kill 8123
# If a normal kill doesn't work, use
sudo kill -9 8123
```
It's another proxy tool or a long-running service: these processes usually serve a real purpose, so killing them isn't advisable. It's safer to just move Clash to a different port.
It's an unfamiliar process you can't identify: run ps -p PID -o comm=,args= first to see the full launch command and check whether it's a critical system service (such as a container networking component or a database proxy client). When in doubt, change the port rather than kill the process, to avoid disrupting something else that's in use.

As a general rule: if the conflict comes from Clash's own leftover process, killing it is the cleanest fix. If it's an unrelated third-party service, changing the port is safer — especially on servers or shared machines, where killing an unfamiliar process carries more risk.

Changing mixed-port and Restarting the Core

Once you've decided to change the port, locate the Clash config file (GUI clients usually show the config path in settings; for CLI deployments, common paths include ~/.config/clash/config.yaml or /etc/clash/config.yaml) and update mixed-port to an available port, such as 7891:

mixed-port: 7891
allow-lan: false
bind-address: "*"
mode: rule
log-level: info

If your config still uses the older split-field style with port and socks-port, update both accordingly, and double-check there's no leftover reference to the old port anywhere else:

port: 7891
socks-port: 7892

Before restarting, double-check the new port is actually free by running ss -tulnp | grep port_number again, so you don't trade one conflict for another. Once confirmed, restart the Clash service or client to apply the change:

# For systemd-managed setups
sudo systemctl restart clash

# If you're running the core manually, kill the old process first, then restart
sudo pkill mihomo
mihomo -d /etc/clash

After restarting, check the startup log once more to confirm there's no more bind: address already in use error, and that the new listening port has taken effect:

sudo ss -tulnp | grep mihomo

Updating Your System Proxy Settings

Changing mixed-port only moves where the core listens. If your OS or browser proxy settings still point to the old port, traffic still won't get through — this step is easy to miss and often leads people to think the port change didn't take effect.

GNOME Desktop

gsettings set org.gnome.system.proxy mode 'manual'
gsettings set org.gnome.system.proxy.http host '127.0.0.1'
gsettings set org.gnome.system.proxy.http port 7891
gsettings set org.gnome.system.proxy.https host '127.0.0.1'
gsettings set org.gnome.system.proxy.https port 7891

You can also update the port number directly through Settings → Network → Network Proxy in the GUI.

Command-Line Environment Variables

If you route traffic through the proxy using environment variables, update the port there too — it's best to add these to ~/.bashrc or ~/.zshrc so they persist:

export http_proxy="http://127.0.0.1:7891"
export https_proxy="http://127.0.0.1:7891"
export all_proxy="socks5://127.0.0.1:7891"

Don't forget to run source ~/.bashrc to apply the change to your current terminal session — otherwise already-open terminal windows will keep using the old port.

Browser Extensions

If you configure proxy rules through a browser extension (such as SwitchyOmega or similar proxy switchers), update the port there too, from 7890 to the new one. Extension settings and system-level settings are independent and don't sync automatically.

Heads up

If TUN mode is enabled to take over all system traffic, TUN mode doesn't use the mixed-port HTTP/SOCKS port, so it's unaffected by this particular conflict. But if you still have system proxy settings or browser extensions pointing at the old port, they'll stop working once TUN mode is disabled — worth double-checking as well.

Other Details Worth Checking

Old port numbers in autostart scripts: if you've set up autostart via systemd or another method, the script or environment file may hard-code the port separately. Updating mixed-port in the config alone isn't enough — check the startup script too.
External controller port: the external-controller field (usually port 9090) is Clash's API/dashboard port, entirely separate from the proxy port mixed-port. If 9090 is also taken, the dashboard won't open — troubleshoot it the same way, as a separate issue.
Multiple users sharing one machine: if several users each run their own Clash config on the same server, it helps to assign each user a distinct port range to avoid repeated conflicts — for example, 7890–7899 for user A and 7900–7909 for user B.
Docker containers: if Clash runs inside a container, port conflicts can also happen at the host's port mapping layer. In that case, check the port mappings in docker ps on the host, not mixed-port inside the container.

Frequently Asked Questions

Changed the port but the browser still can't connect to the proxy? It's most likely that the system proxy settings or a browser extension still point to the old port. Go back to the "Updating Your System Proxy Settings" section above and check each item.

Why does the port conflict happen every time I restart my computer? Check whether Clash is set to autostart as a service, and whether you're also manually launching the client by double-clicking the icon — two instances end up competing for the same port. Stick to just one launch method to fix it.

Still won't start after killing the process? Run ss -tulnp | grep port_number again to confirm the port is truly free. Some processes leave the port in TIME_WAIT for a few seconds after exiting, so wait a bit or try a different port to rule this out.