Port Already in Use in Clash: Find the Process Blocking 7890 and Change Mixed Port

What the error actually means

The Clash core listens on a local port defined in the config file at startup. The default mixed port mixed-port is 7890, which handles both HTTP and SOCKS5 traffic. If the startup log shows a line like this, the core failed to bind to port 7890:

level=fatal msg="Start Http Server error: listen tcp 127.0.0.1:7890: bind: address already in use"

This error has nothing to do with connectivity — it's purely an OS-level port conflict: some process is already listening on port 7890, so the newly started Clash core can't grab it and either exits immediately or the proxy page shows "not running." Common triggers include: a previous Clash process that didn't fully exit, two Clash-family clients installed on the same machine, or another proxy tool (some download managers or dev debugging proxies) happening to use 7890 as well.

The troubleshooting logic is straightforward: first confirm which process is holding the port, then decide whether to close it or change the Clash port to a different number. Commands for each platform below.

Windows: locate the process with netstat

Open Command Prompt or PowerShell and run:

netstat -ano | findstr 7890

The last column of the output is the process PID, for example:

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    8824

With the PID in hand, search Task Manager for the matching process name, or check it via command line:

tasklist /FI "PID eq 8824"

Once you've confirmed it's a leftover Clash process or another program you don't need to keep running, end it directly:

taskkill /PID 8824 /F

If the blocking process is just another leftover Clash instance (common after a forced shutdown left a process running), simply end it and restart the client to get things working again. If the blocker is another program that needs to keep running long-term, use the port-change approach below instead of manually killing the process every time.

macOS and Linux: locate the process with lsof or ss

macOS and most Linux distributions ship with lsof, which can query directly by port number:

lsof -i:7890

In the output, the COMMAND column is the process name and PID is the process ID, for example:

COMMAND     PID   USER   FD   TYPE   NODE NAME
clash-core 3021   dev    3u  IPv4        TCP *:7890 (LISTEN)

Once confirmed, use kill to end the process:

kill -9 3021

Some minimal Linux systems (certain container images or OpenWrt routers) may not have lsof preinstalled. In that case use ss instead, which does the same job:

ss -tulnp | grep 7890

ss puts the process name and PID directly in the last column, formatted like users:(("clash",pid=3021,fd=3)), and can also be ended with kill -9. On older systems without even ss, fall back to netstat -tulnp | grep 7890 — the logic is the same.

Changing mixed-port in the client

If the program holding port 7890 can't easily be closed, or the conflict keeps recurring, the simpler fix is to change the port Clash listens on and avoid the conflict entirely. The method varies by client, but they all edit the same underlying setting.

Method 1: change it in the client's settings panel

Mainstream clients like Clash Verge, Clash Nyanpasu, and FlClash all provide a port input field on the "Settings" or "General" page. Look for "Mixed Port" or "Local Port," and enter a number that's not in use. A high port above 10000, such as 17890 or 27890, is recommended to steer clear of commonly used system port ranges. After saving, the client will automatically restart the core to apply the change.

Method 2: edit the config file directly

If the client has no corresponding setting, or you run the core via the command line, edit the config file by hand:

mixed-port: 17890
allow-lan: false
mode: rule
log-level: info

If the config file still uses the old-style split-port fields (port for HTTP, socks-port for SOCKS5) instead of the merged mixed-port, change whichever of those is conflicting:

port: 17891
socks-port: 17892

What to check after changing the port

Saving the config isn't the end of it — a few related settings are easy to overlook, and skipping them makes the proxy look "on but not actually working":

• System proxy setting: if the client has a "set as system proxy" toggle enabled, the system still has the old port number recorded. Turn the toggle off and back on so the system proxy setting refreshes with the new port.
• Browser extensions: some browser extensions (like SwitchyOmega-style proxy switchers) keep their own separate port configuration, independent of the client. You'll need to update the port manually in the extension's settings.
• Proxy environment variables in the terminal: if you're used to setting a terminal proxy with something like export https_proxy=http://127.0.0.1:7890, remember to update the port number there too, or requests from the terminal will still target the old port and fail to connect.
• Other devices on the local network: if other devices are browsing through this machine's LAN proxy, the port number saved on their end needs updating as well.

Common sources of port conflicts

Besides leftover Clash processes, port 7890 conflicts often come from these sources — worth checking first:

1. Two Clash-family clients installed at once: for example, having both Clash Verge and ClashX Meta installed on the same machine — both default to port 7890, so whichever starts first blocks the other. It's best to keep just one client running as your daily driver.
2. A core run directly from the command line that didn't exit properly: when running the core manually in a terminal for debugging, force-closing the terminal window by any method other than Ctrl+C can leave the core process running as an orphan, still holding the port. Find and end it manually using the commands above.
3. Other proxy or packet-capture tools: some network debugging tools and download managers with a built-in proxy module occasionally default to the common port 7890, and the odds of colliding with Clash aren't low.
4. Virtual machine or container port mapping: if you're running a VM or Docker container that maps a service inside it to port 7890 on the host, that will also block Clash. In this case, it's better to change the container's mapped port rather than Clash's.

Once you've identified the source of the conflict, whether to close the blocking process or change the Clash port depends on which program needs to stay on the default port. For most everyday use, changing Clash's mixed-port to a less common high port is the most hassle-free one-time fix, and it should keep this kind of conflict from coming back.