What to Do When Clash Port 7890 Is Already in Use: How to Find the Conflicting Process and Change mixed-port

First, confirm which listening port is conflicting

When Clash, Clash Meta (mihomo), or a graphical client starts, it needs to create one or more listening ports on the local machine. Common errors include address already in use, bind: Only one usage of each socket address, listen tcp 127.0.0.1:7890: bind, and “port already in use” in the client interface. These messages mean the operating system rejected a new listening request; they do not necessarily mean the entire configuration file is damaged.

7890 is a common proxy port in Clash configurations, not a mandatory fixed value. With mixed-port: 7890, the same port accepts both HTTP and SOCKS5 proxy connections. Some older configurations use port: 7890 and socks-port: 7891 separately. A mihomo configuration may also include additional ports for transparent proxying, DNS, and the control interface, so read the complete error line before troubleshooting.

Common ports and their uses

Find the process using port 7890 on Windows

Fully exit the current Clash client, then start it again. If the error persists, another core process may still be running in the background, or another proxy application may be using the port. Do not simply close the window: many clients minimize to the notification area when closed, while the core continues listening in the background.

Method 1: Use netstat and tasklist

Open Terminal or Command Prompt with standard permissions and run:

netstat -ano | findstr :7890

A typical result looks like this:

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    18432

The final column, 18432, is the process PID. Only entries with the LISTENING state directly show that the port is being listened on. A large number of TIME_WAIT connections usually does not indicate a listening conflict, so do not terminate a process based on that alone. Query the program associated with the PID:

tasklist /FI "PID eq 18432"

If the result is mihomo.exe, clash.exe, or a core file bundled with a client, it is usually a leftover instance. If another proxy tool is listed, stop its service or exit that application first, then decide whether to change the Clash port.

Method 2: Use PowerShell

PowerShell can read the listening endpoint and process name directly:

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 18432

If the first command reports insufficient permissions, open Windows Terminal as an administrator and try again. You can also sort by PID in Task Manager → Details, then verify the process path and start time. If the path is inside the current client directory but the start time is clearly earlier than the current operation, a leftover core is likely.

Safely stop a leftover instance

First, use the notification-area menu to choose Exit so the client can close the core, system proxy, and service together. If the interface is no longer responsive, use:

taskkill /PID 18432 /T

If normal termination fails and you have confirmed the PID is correct, add the force parameter:

taskkill /PID 18432 /T /F

Check port usage on macOS and Linux

Use lsof on macOS

Open Terminal and find the program listening on TCP port 7890:

lsof -nP -iTCP:7890 -sTCP:LISTEN

COMMAND is the process name, PID is the process ID, and NAME shows the listening address. If there is no output, check whether the error actually points to 7891, 9090, or 1053. You can also remove the listening-state filter to view all connections related to the port:

lsof -nP -i :7890

After confirming that a leftover mihomo or Clash core is responsible, try a normal termination first:

kill 18432

Wait about 2 seconds, then run lsof again. If the process is still present, check whether a graphical client or background service is launching it again automatically. Running kill -9 only terminates the current instance; it does not solve repeated restarts by a daemon.

Use ss or lsof on Linux

Most modern distributions include ss by default:

sudo ss -ltnp 'sport = :7890'

You can also use:

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

If mihomo runs through systemd, do not simply kill the core process. systemd will restart it according to the service configuration. Check the service status first, then stop the corresponding unit:

sudo systemctl status mihomo
sudo systemctl stop mihomo

The service name depends on how it was installed and may not be mihomo. Run systemctl list-units --type=service | grep -Ei 'clash|mihomo' to search for it. Container deployments also require checking Docker port mappings; 127.0.0.1:7890 on the host may be held by a container proxy process rather than shown directly by the core inside the container.

Decide whether to stop the process or change mixed-port

Once you find the process using the port, do not change the port immediately. First determine whether both programs need to keep running. If the port holder is a leftover core from an abnormal exit of the same client, terminate it and restart the client. If two proxy tools must run in parallel, or 7890 is reserved by a local development service, assign a new port to one of them.

When stopping the old process is appropriate

• The process uses the same core file and configuration directory as the current client.
• Two mihomo or Clash core instances appear in Task Manager or Activity Monitor.
• The old client has been uninstalled, but its startup entry, service, or scheduled task still exists.
• Only one proxy client is needed after the port is released.

When changing the port is appropriate

• 7890 is used by another proxy or debugging tool that must remain running.
• A stable configuration and a test configuration must run at the same time, with both cores isolated.
• A centrally managed environment has assigned the application a fixed port range.
• The current configuration is shared with other devices, so stopping the process would disrupt an existing workflow.

Choose a new local port that is not being listened on, such as 7893, 17890, or 27890. Use the same query commands to check each candidate before changing it. Valid ports range from 1 to 65535; typical desktop setups should avoid common system-service ports from 1 to 1023, and should not overlap with the control interface, DNS listener, or transparent proxy ports.

Change mixed-port in the configuration file

When editing YAML directly, find the top-level mixed-port key. The following configuration changes the mixed proxy port from 7890 to 7893:

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

mixed-port must be at the top level of the configuration, not nested under proxies, proxy-groups, or dns. Keep one space after the colon and write the port as an integer. After saving, fully reload the core configuration; switching proxy groups alone does not recreate the listening port.

Do not keep duplicate listeners

If the configuration already uses a mixed port, you usually do not need to assign the same number separately to HTTP and SOCKS. The following setup makes multiple listeners compete for 7893:

mixed-port: 7893
port: 7893
socks-port: 7893

Choose one approach. If you need a single entry point, keep only:

mixed-port: 7893

If you genuinely need separate HTTP and SOCKS5 endpoints, use different ports and remove mixed-port:

port: 7893
socks-port: 7894

Change the port in a graphical client

Menu names vary by client. Common paths include Settings → Preferences → Ports or Settings → Core Settings → Mixed Port. Change 7890 to the confirmed free port 7893, save, then choose Restart Core or fully exit and reopen the client.

Some interfaces show HTTP, SOCKS, and Mixed as separate options. After enabling Mixed, use the mixed port as the primary entry point. If the client lets you disable separate HTTP and SOCKS listeners, turn off unused entries to reduce duplicate configuration. If the port field is read-only, its value is usually controlled by the current configuration file or an override rule, so change it in the configuration management page.

Update the system proxy as well

After changing the port, the system proxy may still point to the old 127.0.0.1:7890. The core may be running normally while the browser reports that it cannot connect. Turn the client's System Proxy switch off and on again; this usually writes the new port. You can also verify it manually in the operating system:

• Windows: Settings → Network & Internet → Proxy. Check that the address is 127.0.0.1 and the port is 7893.
• macOS: System Settings → Network → Current Network → Details → Proxies. Check the web proxy and secure web proxy ports.
• Browser extensions, developer tools, and command-line programs may have their own proxy address configured; update 7890 to 7893 there as well.

Command-line environment variables may also retain the old value. Using the new mixed port as an example:

http_proxy=http://127.0.0.1:7893
https_proxy=http://127.0.0.1:7893
all_proxy=socks5://127.0.0.1:7893

The syntax for setting environment variables depends on the operating system and shell. The important step is to check every caller, not just the port number shown in the client interface.

Listening conflicts still matter in TUN mode

TUN mode receives system traffic through a virtual network interface, but that does not make mixed-port conflicts harmless. If the configuration declares mixed-port: 7890, the core will usually still try to create that listener. A port-binding failure may stop the core from starting or make some explicit proxy features unavailable.

If you rely only on TUN, you may be able to remove unnecessary explicit proxy listeners depending on the client and core configuration. However, graphical clients, browser extensions, and LAN devices may still depend on mixed-port. Check for manual proxy usage before changing it. TUN auto-routing, strict routing, and DNS hijacking are separate settings and should not be replaced by changing 7890.

When allow-lan: true is enabled, the client may listen on 0.0.0.0:7893, allowing LAN devices to connect. For local-only use, keep allow-lan: false or restrict the listening address to the loopback interface. Whether LAN access is enabled or not, the port must remain unique within the same address family.

Verify that the new port is actually working

Step 1: Confirm the listening state

After restarting the core, query the new port again. On Windows, use:

netstat -ano | findstr :7893

On macOS, use:

lsof -nP -iTCP:7893 -sTCP:LISTEN

On Linux, use:

ss -ltnp 'sport = :7893'

The expected result is that the mihomo or Clash core is in the LISTEN state, while the old port 7890 is no longer held by that instance.

Step 2: Test the proxy endpoint directly

If curl is installed, bypass the system proxy settings and specify the new port directly:

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

An HTTP response header confirms that the local proxy endpoint can accept requests. If you see Connection refused, the new port is not listening or the address is incorrect. If the connection succeeds but the request times out, continue checking node availability, proxy-group selection, DNS, and rules instead of changing the port again.

Step 3: Check the client logs

On the Logs page, filter for keywords such as error, listen, and bind. After a normal startup, there should be no binding errors for 7890 or 7893. If the error changes to 127.0.0.1:9090, mixed-port is fixed but the control interface still conflicts with another instance; use the same method to check external-controller.

Checklist for recurring port 7890 conflicts

1. After closing the client window, check the notification area, menu bar, and Task Manager for a core process that is still running.
2. Check whether two Clash or mihomo graphical clients are installed and both configured to launch at startup.
3. On Windows, check Task Manager → Startup apps and the services list; on Linux, check systemd; on macOS, check Login Items and background items.
4. After a subscription update, confirm that mixed-port in the runtime configuration has not changed from 7893 back to 7890.
5. Confirm that the system proxy, browser extensions, terminal environment variables, and LAN devices use the current port.
6. Check other listening ports such as 9090, 1053, and 7891 to avoid being blocked by another conflict after fixing the first one.
7. Keep a clear port plan, for example: mixed proxy on 7893, control interface on 9093, and DNS on 1053. Avoid reusing ports across multiple instances.

Use a consistent order when resolving port conflicts: read the exact port from the logs, locate the PID with system tools, decide whether the process should remain, then either terminate the leftover process or change the configuration. After changing mixed-port, update the system proxy and every manual proxy caller as well. Changing only the YAML while leaving clients pointed at the old port turns “startup failed” into “the core runs but applications cannot connect,” making later troubleshooting harder.