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

First, confirm that the port is actually in use

When the Clash or Clash Meta (mihomo) core starts, it needs to listen on one or more local ports. A common setup assigns mixed-port to 7890, allowing the same port to accept both HTTP and SOCKS5 proxy connections. If another process is already listening on that port, the new core cannot bind to it. The client may remain stuck at “Starting” or report that the core failed to start.

When logs contain messages like the following, check the port first. Wording varies slightly by core version and operating system, but the key terms usually include bind, address already in use, Only one usage, or the specific port number.

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

listen tcp 0.0.0.0:7890:
bind: Only one usage of each socket address is normally permitted

Do not check only 7890. Your configuration may also define separate HTTP, SOCKS, transparent proxy, or external control ports. For example, a configuration might use port: 7890, socks-port: 7891, and external-controller: 127.0.0.1:9090. Check the port whose address the log says failed to bind.

A port conflict is not the same as a connection failure

• Port conflict: The core cannot start, and the log reports a listen or bind failure.
• Node connection failure: The core has started, but the proxy node times out; the log usually points to a remote address.
• System proxy not updated: The core is listening normally, but the browser is still connecting to the old port, so pages fail to load.
• Control port conflict: The proxy port is available, but the GUI cannot connect to the core. This often involves external-controller on port 9090 or another custom port.

Find the complete error in the client log before checking the corresponding port. This prevents a node failure from being mistaken for a local port problem. If the log reports a configuration parsing error, such as invalid YAML indentation or a wrong field type, changing 7890 will not fix the startup failure.

Windows: find the process using netstat

Windows 10 and Windows 11 include netstat. Fully quit Clash Nyanpasu, then open Windows Terminal or Command Prompt with standard permissions and run:

netstat -ano | findstr :7890

If the port is being listened on, the output may look like this. The final column, 18432, is the process PID, not the port number.

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    18432
TCP    [::1]:7890        [::]:0       LISTENING    18432

Pass the PID you found to tasklist to confirm the process name:

tasklist /FI "PID eq 18432"

If the result is another proxy client, an older Clash core, or a desktop client still running in the background, close it normally from that program’s own Quit menu. If it is simply a leftover process from a crash, end it after confirming its name and PID:

taskkill /PID 18432 /F

Get clearer results with PowerShell

PowerShell can return the process ID that owns the listening port directly. On Windows 11, Windows Terminal usually opens PowerShell by default:

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

After obtaining OwningProcess, query the process details:

Get-Process -Id 18432

If the Clash configuration also enables UDP listening, an empty TCP result does not completely rule out a conflict. Check UDP as well:

Get-NetUDPEndpoint -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

Use the listening address to determine the scope

Seeing the same PID on two lines usually does not mean two conflicting programs; it often means the program is listening separately on IPv4 and IPv6. The key questions are whether the process owning the port is the core you are about to start and whether another instance is still running on the system.

macOS and Linux: check ports with lsof and ss

On macOS, run lsof from Terminal in Applications → Utilities. The following command checks only TCP 7890 and filters for listening sockets:

lsof -nP -iTCP:7890 -sTCP:LISTEN

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   4217 user   11u  IPv4  0x01      0t0  TCP 127.0.0.1:7890 (LISTEN)

First check the menu bar to see whether a Clash client is still running. Once you have confirmed that it is a leftover process no longer under GUI control, send it a normal termination signal first:

kill 4217

Wait two seconds, then run lsof again. Only consider force termination after confirming that the process is still running and that its identity is correct:

kill -9 4217

Prefer ss on Linux

Most modern Linux distributions include ss. To see what is listening on TCP 7890, run:

sudo ss -lptn 'sport = :7890'

To check UDP, use:

sudo ss -lpun 'sport = :7890'

If lsof is installed, you can also use this cross-platform command:

sudo lsof -nP -i :7890

On Linux, also check systemd services. After a manually launched GUI client exits, a system-level mihomo service may still be listening in the background. Check the service status first, then decide whether to stop it:

systemctl status mihomo
sudo systemctl stop mihomo

The service name depends on how it was installed; it may also be clash or a custom unit name. Do not disable a service before confirming what it is used for. If it is the proxy core you use every day, keep it running and configure the GUI client to use a different set of ports.

Change the mixed port in Clash Nyanpasu

If the program using 7890 must keep running, assign Clash Nyanpasu an unused port. The usual path is Settings → Clash Settings → General → Mixed Port. Labels may vary by version, but look for mixed-port in the core or Clash parameter settings.

1. First use netstat, lsof, or ss to check the new port you plan to use, such as 7893.
2. Change the mixed port from 7890 to 7893.
3. Save the setting, then restart the core or fully quit and reopen the client.
4. Return to the log and confirm that it records listening on 127.0.0.1:7893.
5. Turn the system proxy back on so the operating system uses the new port.

Prefer an unused port above 1024. Port numbers can range up to 65535. Avoid switching to low ports such as 80 or 443 just to bypass a conflict: they may require additional permissions and are more likely to conflict with web services.

Why websites still will not open after changing the port

Changing the port successfully only means that the core can listen on it. Browsers, terminals, and other apps must also connect to the new port. If the system proxy still points to 127.0.0.1:7890, requests will continue going to the old address. The simplest fix is to turn the system proxy off once, then turn it back on so the client writes 127.0.0.1:7893.

Terminal environment variables do not always update automatically with the system proxy. If you configured a proxy manually, update these variables as well:

export HTTP_PROXY=http://127.0.0.1:7893
export HTTPS_PROXY=http://127.0.0.1:7893
export ALL_PROXY=socks5://127.0.0.1:7893

With a mixed port, the same 7893 port accepts both HTTP and SOCKS5 proxy connections, so the examples above can share one port. If your configuration uses separate port and socks-port values, enter each corresponding port instead of replacing everything with 7893.

Edit mixed-port directly in the configuration file

When using the mihomo command line, a container, or a self-managed configuration file, edit the YAML directly. The minimal form is:

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

mixed-port is the inbound port shared by HTTP and SOCKS5. When this field is in use, you usually should not also assign the same value to port and socks-port. Duplicate or overlapping listeners can trigger another bind failure and make troubleshooting harder.

If you genuinely need separate HTTP and SOCKS5 ports, use different values:

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

The external control interface must also use its own port. For example:

mixed-port: 7893
external-controller: 127.0.0.1:9091
secret: "change-this-controller-secret"

Here, the proxy entry point is set to 7893 and the control interface to 9091. They serve different purposes: 7893 receives proxy traffic from apps, while 9091 lets the GUI or control panel call the core API. If the log clearly says 9090 is in use, changing mixed-port will not help; change external-controller and update the client’s controller connection settings too.

Validate the configuration before restarting the core

When running mihomo from the command line, use the core’s configuration-check option first. The executable name depends on how it was installed:

mihomo -t -f config.yaml

Start it the usual way after validation passes. If it still fails, read the complete log and confirm whether the port in the error has changed to 7893. If the log still shows 7890, the process is usually using a different configuration file, or the GUI client regenerated its runtime configuration at startup.

Five checks when the core still fails after changing the port

1. The new port is also in use

Do not choose 7891 or 7892 based on guesswork; proxy tools commonly use those ports too. Run a query before changing anything. On Windows, use netstat -ano | findstr :7893; on macOS, use lsof -nP -iTCP:7893 -sTCP:LISTEN. No output usually means no TCP listener is currently present, but check UDP if UDP inbound is enabled.

2. Two core instances started at the same time

Automatic startup, service mode, and manual launching can create duplicate instances. Fully quit the client, confirm that 7890, 7893, and the control port are all free, then start it only once. If the port reappears immediately after the client exits, check startup apps, scheduled tasks, login items, or systemd services.

3. The configuration override did not take effect

The subscription’s mixed-port: 7890 may be overridden by the client’s global settings, or startup arguments may override the configuration file. Rely on runtime logs and actual listening results rather than only the YAML in your editor. Query the ports again after startup to see exactly which address the core is listening on.

4. External control port conflict

An idle proxy port does not mean every listener can be created. Check whether the log points to 127.0.0.1:9090, 9091, or another control port. After changing the control port, update the GUI connection address as well; otherwise the core may be running while the panel shows “Disconnected”.

5. The listening address or permissions are unsuitable

With allow-lan enabled, the configuration may listen on 0.0.0.0 or a specific LAN address. If that address is no longer available, the log may show “cannot assign requested address”, which is not an ordinary port conflict. Restore a valid interface address or listen only on 127.0.0.1. Ports below 1024 may also require elevated permissions, so use a higher port instead.

Configuration habits that help prevent another 7890 conflict

• Keep only one automatic startup entry: Do not let the GUI client, background service, and scheduled task all start the core.
• Assign different ports to different clients: For example, use 7890 for the main client, 7893 for a test instance, and 7895 for a container instance.
• Document the control port: Record the proxy port separately from external-controller, then check each one against the logs during troubleshooting.
• Quit from the tray after closing: Closing a window does not necessarily end the process. Use the complete Quit operation before upgrading or switching clients.
• Let the client manage the system proxy: After changing the mixed port, toggle the system proxy off and on again to reduce stale references to the old port.
• Store local ports in persistent settings: Let subscriptions provide nodes and rules, while the client’s overrides or global settings manage local listening ports.

If multiple mihomo instances must run on the same device, assign each instance a different mixed port, control port, and runtime directory. Changing only 7890 is not enough to isolate every resource; caches, databases, Unix sockets, or named pipes may also need separate paths, depending on the launch method and client implementation.

Quick troubleshooting sequence

1. Open the client log and note the complete address and port that failed to bind.
2. Fully quit Clash Nyanpasu and check whether the port is released.
3. On Windows, use netstat or PowerShell; on macOS, use lsof; on Linux, use ss to find the PID.
4. Confirm the process name, then quit the duplicate client normally or stop the duplicate service.
5. If the process must remain running, change mixed-port to a confirmed free port such as 7893.
6. Also check external-controller so you do not solve only the proxy port conflict.
7. Restart the core, then use the logs and listening results to confirm that the new configuration is active.
8. Turn the system proxy back on, and update terminal environment variables and apps with manually entered proxy ports.

A port conflict is fundamentally a clash over a local listening resource. The solution is not repeated client reinstalls: find the port in the log, identify its PID with system tools, then decide whether to quit the process or change the configuration. Afterward, synchronize the system proxy and terminal environment variables; otherwise the core may be running again while apps continue using the old port.