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

Decoding the error: why "address already in use" happens

When Clash and clients built on the Clash Meta (mihomo) core start up, they try to listen on several ports defined in the config file: the mixed port (mixed-port, which accepts both HTTP and SOCKS5 requests), a separate HTTP port (port) and SOCKS5 port (socks-port), and some clients also open a RESTful API port (external-controller, commonly defaulting to 9090). When any one of these ports is already held by another process on the system, the core fails during the bind step, and you'll typically see something like this in the logs or a popup:

panic: listen tcp 127.0.0.1:7890: bind: address already in use

The message already tells you exactly what's wrong: the core wants to listen on port 7890, but the OS refuses because that port is already taken. This isn't a config syntax error, and it has nothing to do with your subscription or proxy nodes — it's purely a local port conflict. The fix is the same two-step process every time: find out which process holds the port, then decide whether to stop that process or give Clash a different port to use.

Windows: locate the process with netstat and PowerShell

On Windows, the most direct approach is to open Command Prompt or PowerShell, use netstat to find the process ID (PID) bound to the port, then check Task Manager or use taskkill to identify and end the process. Using the default port 7890 as an example:

netstat -ano | findstr :7890

The last column of the output is the PID — say it shows 12480. Run:

tasklist | findstr 12480

This tells you which executable is holding the port. If you're sure it's safe to close, end it directly:

taskkill /PID 12480 /F

PowerShell users can get the process name in one line, which is often clearer:

Get-Process -Id (Get-NetTCPConnection -LocalPort 7890).OwningProcess

Common culprits include: a leftover background process from a previous Clash client that didn't exit cleanly (especially when the window is force-closed via Task Manager but the core process keeps running), another tool built on a Clash-family core, and some download managers or local proxy/debugging tools that also default to the 7890 port range.

macOS: use lsof to check for port conflicts

On macOS, lsof (list open files) is the go-to tool for finding the process bound to a port:

sudo lsof -i :7890

In the output, the COMMAND column shows the process name and PID shows the process ID. Once confirmed, end it:

kill -9 the_PID

If you're used to netstat, macOS still supports a compatible syntax, but lsof is generally recommended since it gives more complete information. Also worth noting: menu-bar clients like ClashX and ClashX Meta may not terminate the background core process just because you quit the menu bar icon. If you're hitting a port conflict, check whether the core process actually exited rather than just the UI.

ps aux | grep -i clash

This lists every clash-related process currently running on the system, making it easy to clean up leftover instances in one pass.

Linux: use ss and fuser to find and end the process

On newer distributions, ss is recommended over the increasingly deprecated netstat:

sudo ss -tulnp | grep 7890

The users:(("process_name",pid=1234,...)) section of the output shows what's holding the port. You can also use the more concise fuser to locate and optionally kill it directly:

sudo fuser -k 7890/tcp

This command directly ends whatever process is holding port 7890 — use it once you've confirmed the process is a stale one that's safe to terminate. If you're managing mihomo or clash as a systemd service, it's safer to first check whether two service instances are running at once:

systemctl status mihomo
systemctl status clash

If both services are running and both are trying to bind the same port, disable one of them instead of just working around it by changing ports — otherwise rules and subscription updates end up split across two processes with inconsistent state, which is much harder to debug later.

Changing the mixed port in the Clash config file

If the program holding the port isn't convenient to close (say, it's a system service or another tool you use regularly), it's often simpler to have Clash listen on a different port instead. With the Clash Meta (mihomo) core, the recommended approach is to use the mixed-port field directly:

mixed-port: 7895
allow-lan: false
bind-address: "*"
external-controller: 127.0.0.1:9096
secret: ""

Just change mixed-port from the default 7890 to an unused port (pick something above 10000 that isn't commonly used by other software, such as 7895 or 17890), save, and restart the client. If you're using the older separate port (HTTP) and socks-port (SOCKS5) fields instead of mixed-port, check those for conflicts too:

port: 7891
socks-port: 7892
external-controller: 127.0.0.1:9097

Most GUI clients (Clash Verge Rev, Clash Plus, FlClash, etc.) also let you set port numbers directly in the settings page, which is equivalent to editing the corresponding field in the config file — and just like editing the file, you'll need to restart the core or client for it to take effect. After changing the port, remember to update the port number in your system proxy settings or browser extension as well, otherwise you'll end up in a situation where "the client is running fine but the browser still can't connect" — which isn't actually a port conflict at all, it's just that the system proxy settings weren't updated to match.

Common culprits and how to avoid this in the first place

Based on common reports, conflicts around the 7890 port range usually come from one of these sources — knowing them ahead of time can save you a round of troubleshooting:

• A previous Clash process didn't fully exit: closing the window via the top-right button may leave the core process running in the background, and the next launch ends up fighting itself for the port.
• Multiple Clash-family clients installed at once: for example, having both Clash Verge Rev and a leftover old Clash for Windows install — if both are set to auto-launch, conflicts are almost guaranteed.
• Other proxy/debugging tools: some local dev proxy tools and packet-capture tools also default to listening on 7890 or nearby ports.
• Port forwarding in containers or virtualized environments: when using Docker or a VM with port mapping, a container's mapped host port can sometimes land right in this range.

The fix is simple: keep only one active Clash-family client and uninstall or fully disable auto-launch for the rest. If you genuinely need multiple proxy tools running side by side, plan non-overlapping port ranges for each ahead of time rather than improvising once an error shows up.

Frequently asked questions

I changed the port but the client still says it's already in use — why?

First confirm that the config file you edited is the same one the client is actually loading — some clients support switching between multiple config profiles, and you may have edited one that isn't currently active. Also check whether the new port you picked happens to clash with something else too; try a less common four- or five-digit port and re-run the lookup commands from earlier to confirm it's actually free.

Is it safe to kill the process holding the port? Will it affect my system?

If you've confirmed the process is a leftover Clash process or an ordinary app you can restart, ending it is safe. But if lsof/netstat shows the process is a system-level service or something you don't recognize, look up the process name first to confirm what it does, or simply give Clash a different port instead — that way you avoid accidentally killing a system service.

Do port conflicts happen on mobile (Android/iOS) too?

Mobile sandboxing is much stricter, so port conflicts mainly show up when multiple VPN/proxy apps try to run at the same time — the system usually only allows one active VPN profile. If a connection fails, check whether another proxy app is running a VPN service in the background and disable one of them; the fix is simpler than on desktop.