What to Do When a Clash Port Is Already in Use: Find the Process Blocking 7890 and Change the Mixed Port

First, confirm which port is conflicting

When you see “address already in use,” “bind failed,” or “port already in use,” the cause is usually straightforward: the Mihomo core is trying to listen on a local port that another process already occupies. The most common conflict is port 7890, but it may also be 7891, 9090, or a custom value from your configuration.

mixed-port is the mixed proxy port. A single listening endpoint can accept both HTTP proxy and SOCKS5 proxy connections. Many Clash clients set it to 7890 by default. Browser extensions, system proxy settings, and command-line tools commonly connect to this port, so a conflict can prevent the core from starting or make the proxy unreachable.

Extract the exact port from the logs

Open the client’s log panel first, then search for bind, listen, address already in use, or port. If the log shows listen tcp 127.0.0.1:7890, investigate TCP port 7890. If it shows 0.0.0.0:7890, the program is preparing to listen on that port across all local network interfaces, so the conflict scope is broader than with 127.0.0.1 alone.

Also check whether the same configuration contains both mixed-port: 7890 and port: 7890. In that case, you do not need to look for an external program: the configuration itself is asking two listeners to compete for the same address. Keep the mixed port and remove any unused standalone HTTP or SOCKS port.

Use netstat on Windows to find the process using 7890

Windows 10 and Windows 11 both include the built-in netstat utility. Fully quit the current Clash client, then open Windows Terminal or Command Prompt as an administrator and run:

netstat -ano | findstr :7890

A typical result looks like this. The final column, 16420, is the process identifier, or PID:

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    16420

Only entries with the status LISTENING indicate that a program is listening on the TCP port. If :7890 appears only in the foreign address, you cannot conclude that the local port is occupied. Check the “Local Address” column for 127.0.0.1:7890, 0.0.0.0:7890, or [::]:7890.

Find the program name by PID

Once you have the PID, run:

tasklist /FI "PID eq 16420"

You can also view the executable path in PowerShell:

Get-Process -Id 16420
Get-CimInstance Win32_Process -Filter "ProcessId = 16420" |
  Select-Object ProcessId, Name, ExecutablePath, CommandLine

If the result points to another Clash, Mihomo, sing-box, or proxy client, an old core may still be running after the interface was closed. Quit that client normally from its menu, wait 3 to 5 seconds, and check the port again. Closing only the window in Task Manager may not stop the background core; its tray icon may still be active.

If you have confirmed that the process can be stopped, locate it by PID on Task Manager’s “Details” tab, or run:

taskkill /PID 16420 /F

netstat shows nothing, but the error persists

• Confirm that the port in the log is actually 7890; do not mistake the control port 9090 for the mixed port.
• Check both IPv4 and IPv6. A program listening on [::]:7890 may prevent another process from binding to an IPv4 address.
• Quit the client and run the command again so you do not mistake the current client’s normal listener for a conflict.
• Check whether the client started two core instances, such as a portable build and an installed build both configured to launch at startup.
• Check whether the log actually reports insufficient permissions. Permission errors require a different fix from port conflicts.

Use lsof on macOS to find the listening process

On macOS, use lsof to see which process has opened TCP port 7890. Open Terminal and run:

sudo lsof -nP -iTCP:7890 -sTCP:LISTEN

-nP displays numeric addresses and ports directly, avoiding delays from DNS lookups. In the output, COMMAND is the process name and PID is the process ID. For example:

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
mihomo   8421 user   10u  IPv4        0t0      TCP 127.0.0.1:7890 (LISTEN)

Use the following command to inspect the startup arguments and determine which client owns it:

ps -p 8421 -o pid,ppid,user,command

If the process belongs to another proxy client that is still running, quit it normally from the menu bar icon first. Once you have confirmed that it is unresponsive, send a regular termination signal:

kill 8421

Wait a few seconds, then run lsof again. Consider kill -9 8421 only if a normal termination fails. Force-killing the process may prevent the client from saving its current configuration, so it should not be the first step.

Check the standalone SOCKS port as well

If the configuration also enables socks-port: 7891, check ports 7890 and 7891 separately. Changing the mixed port to 7892 will not resolve a conflict on another standalone listener using 7891:

sudo lsof -nP -iTCP:7890 -sTCP:LISTEN
sudo lsof -nP -iTCP:7891 -sTCP:LISTEN
sudo lsof -nP -iTCP:9090 -sTCP:LISTEN

Use ss on Linux to check listening ports

Most modern Linux distributions include ss by default. It can show listening sockets and their associated processes directly. Run:

sudo ss -ltnp 'sport = :7890'

In these options, l means listening sockets only, t means TCP, n displays numeric ports directly, and p shows the process. You can also use this more readable filter:

sudo ss -ltnp | grep ':7890'

The output may look like this:

LISTEN 0 4096 127.0.0.1:7890 0.0.0.0:* users:(("mihomo",pid=2317,fd=8))

If Mihomo is managed by systemd, do not simply use kill to stop it; the service manager may start it again immediately. Check the service status first, then stop the relevant unit:

systemctl --type=service --state=running | grep -Ei 'mihomo|clash'
sudo systemctl status mihomo
sudo systemctl stop mihomo

In a containerized environment, also check port mappings. A Docker or Podman proxy process on the host may occupy 7890 even when no host process named Mihomo exists:

docker ps --format 'table {{.ID}}\t{{.Names}}\t{{.Ports}}'
podman ps --format 'table {{.ID}}\t{{.Names}}\t{{.Ports}}'

Change mixed-port and the client’s listening port

If the process using 7890 must remain running, the safest approach is to assign Clash or Mihomo an unused port, such as 7892. Use the system commands above to confirm that 7892 has no listener before changing the client.

Change it from the graphical interface

Clients with a graphical interface usually provide this under Settings → Preferences → Mixed Port. Change 7890 to 7892, save, and restart the core. Menu labels may vary—“Mixed Port,” “Mixed Proxy Port,” or “Port Settings”—but the setting to change is always the current core’s mixed-port.

If the page lists HTTP, SOCKS, and mixed ports separately, do not assign the same value to multiple entries. When you need only one entry point, enable the mixed port and disable unused standalone listeners to reduce possible conflicts.

Edit the YAML configuration directly

In the configuration file, change the field to:

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

mixed-port must be an integer. It cannot be written as an address with a colon, and it must not duplicate the address and port used by port, socks-port, or the control interface in the same configuration. After saving, reload the configuration in the core; editing the file on disk alone does not change an already-running listener.

When multiple profiles coexist, make sure you are editing the active configuration. Some clients copy subscription content into the application data directory, so the original subscription file and the runtime configuration are not the same file. Check the current profile name in the interface, then open that profile’s editor to avoid changing an inactive copy.

Verify that the new port is listening

After restarting the core, do not check only whether a webpage opens. First confirm that the system has created the new listener and that the old port is no longer owned by the current client:

# Windows
netstat -ano | findstr :7892

# macOS
sudo lsof -nP -iTCP:7892 -sTCP:LISTEN

# Linux
sudo ss -ltnp 'sport = :7892'

The expected result is for 127.0.0.1:7892, or the explicitly configured listening address, to show the state LISTEN. If LAN connections are enabled, you may see 0.0.0.0:7892; in that case, also review access controls and firewall rules. Do not broaden the listening scope merely to resolve a local port conflict.

Update system and application proxy settings together

If webpages still fail to load after changing the port, the most common cause is that the system proxy still points to 127.0.0.1:7890. The core is running normally on 7892, while the browser continues connecting to 7890, making it appear that the change did not work.

Let the client reset the system proxy first

1. Turn off the “System Proxy” switch in the client.
2. Confirm that the mixed port is saved as 7892, then restart the core.
3. Turn “System Proxy” back on.
4. Open the operating system’s proxy settings and verify the address is 127.0.0.1 and the port is 7892.

In Windows 11, check the manual proxy server under Settings → Network & internet → Proxy. On macOS, open System Settings → Network → your current network → Details → Proxies and check the web proxy or secure web proxy. Letting the client manage these settings is usually more reliable; if you enter them manually, the port must match the active listener.

Check browser extensions and command-line variables

A proxy-switching extension may bypass system settings while retaining the old port. Change its HTTP or SOCKS5 port to 7892 in the extension’s proxy configuration. Developer tools may also set a proxy through environment variables; check each of these:

HTTP_PROXY=http://127.0.0.1:7892
HTTPS_PROXY=http://127.0.0.1:7892
ALL_PROXY=socks5://127.0.0.1:7892

The same mixed-port accepts both protocols above, but the protocol prefix used by the application must still be correct. If you use a standalone socks-port, ALL_PROXY should point to that separate port rather than mechanically copying the mixed port.

How TUN mode differs

TUN mode takes over traffic through a virtual network interface and normally does not depend on the system HTTP proxy switch. However, if the configuration still asks Mihomo to create mixed-port: 7890, an occupied 7890 can still prevent the core from starting. The fix remains the same: stop the conflicting process or change the listening port.

During troubleshooting, keep only one traffic-capture method enabled: either disable TUN and use the system proxy to test 7892, or disable the system proxy and test TUN alone. Enabling both adds variables and can make DNS, routing, or browser-extension issues look like a port conflict.

What to check when the port is still reported as busy

If you changed the port to 7892 but the log still says 7890 is in use, the runtime configuration did not apply the change. Follow the order below to quickly determine whether the issue is the configuration, a process, or an unsynchronized proxy setting.

1. Read the latest logs again. Confirm that the error occurred after this restart and record the complete address and port shown in the log.
2. Confirm the active profile. Check the configuration name currently selected by the client so you do not edit a test profile while the subscription profile remains active.
3. Reload the configuration. After saving the YAML, use the client’s “Reload Configuration” or “Restart Core” action; do not simply close the settings window.
4. Check for duplicate clients. Inspect the tray, menu bar, startup items, systemd services, and containers to make sure there is no second core instance.
5. Check for duplicate fields. Confirm that mixed-port, port, socks-port, and external-controller do not share the same address and port.
6. Confirm the new port is listening. Use netstat, lsof, or ss to verify 7892 instead of relying only on the client interface saying “Running.”
7. Update every proxy entry. Replace the old port in system proxy settings, browser extensions, terminal environment variables, development tools, and LAN devices.

Perform a final check with curl

After confirming that 7892 is listening, use curl to send a request explicitly through the mixed port. The command below displays the connection process and HTTP response headers:

curl -I -v -x http://127.0.0.1:7892 https://example.com

The output should first show a connection to 127.0.0.1:7892, followed by a CONNECT tunnel to the target site. Connection refused means no listener is available at that address. If the connection succeeds but the target request times out, the port conflict is resolved; next check the node, rules, DNS, or network connectivity.

Reusable troubleshooting conclusions

• Log says address already in use: find the listening process first; do not change the node first.
• An old proxy program occupies 7890: quit it and remove duplicate startup entries.
• The occupying program must remain: change mixed-port to a confirmed free port, such as 7892.
• The core listens on the new port but the application cannot connect: update the system proxy and in-app proxy settings together.
• The problem returns after a subscription update: put the port change in the client’s persistent override settings.
• TUN is enabled but startup still fails: check whether the mixed port conflicts with the control port in the configuration.