Clash Port Already in Use: Find the Process and Change the Listening Port

When Clash starts, it needs to create one or more listening ports on the local machine. Browsers, the operating system, and other applications send proxy requests to these ports, and Clash processes the traffic according to the rules and proxy groups in the configuration. If another process is already listening on the target port, the system rejects the second bind attempt. The core usually reports that the address is already in use, listening failed, or the port is occupied.

Common causes include an old Clash process that did not exit cleanly, two clients running at once, another proxy tool using the same port, multiple listeners configured with one port, or a control interface or DNS service colliding with a local development service. Do not keep clicking Start. First identify the address and port involved, then find the process using it, and finally decide whether to stop that process or change the Clash configuration.

1. Identify a port conflict from the error message

Different clients format core logs in different ways, but the underlying error usually contains bind, listen, address already in use, or wording such as “port already in use.” The most useful details are the protocol, listening address, and port number. For example, 127.0.0.1:7890 listens only on the local loopback address at port 7890, while 0.0.0.0:7890 attempts to listen on that port across all IPv4 network interfaces.

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

The first entry usually refers to an HTTP, SOCKS, or mixed proxy endpoint; the second is more likely to be the external control interface. A port number alone cannot identify the configuration item because the default can be changed. Check the surrounding log entries together with the active configuration.

If the log shows no bind failure but instead reports that TUN device creation failed, permissions are insufficient, route setup failed, or a network interface is missing, the issue may not involve a proxy port. Changing a port such as 7890 will usually not help; check administrator permissions, the virtual adapter, the TUN driver, and system routes instead.

2. Confirm which listening ports Clash is using

Clash and mihomo configurations can contain several local listeners. The exact fields depend on the client and active configuration, but the following are the most common.

mixed-port can already handle both HTTP and SOCKS5 requests. With mixed mode enabled, you usually do not need to set port or socks-port to the same value. Two listeners cannot use the exact same transport protocol and port combination on one address.

Also distinguish between a subscription configuration and the client’s runtime settings. Some desktop clients generate the final configuration at runtime by merging the ports, control interface, and TUN options from the UI into the subscription content. Direct edits to the subscription file may be overwritten during a subscription update or client restart. Prefer the client’s General Settings, port settings, or override configuration. Edit the YAML fields only when you have confirmed that the client reads that file directly.

3. Find the process using the port on Windows, macOS, or Linux

Windows: Find the PID and process name

Using port 7890 as an example, run this in Command Prompt:

netstat -ano | findstr :7890

LISTENING means the process is listening on the port; the final column is the PID. Query the program associated with that PID next:

tasklist /FI "PID eq 1234"

You can also use a structured command in PowerShell:

Get-NetTCPConnection -LocalPort 7890 -State Listen
Get-Process -Id 1234

If the command reports insufficient permissions, run the query again from an elevated terminal. You can also find a process by PID on Task Manager’s Details tab. If you find another Clash client or an old core, exit it normally from its own interface first, confirm that the tray process has ended, and only then consider terminating it.

macOS: Use lsof to find the listener

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

The output lists the process name, PID, user, and listening address. If you are checking a DNS service, query UDP as well, because local DNS listeners may use both UDP and TCP:

sudo lsof -nP -iUDP:1053
sudo lsof -nP -iTCP:1053 -sTCP:LISTEN

Linux: Use ss or lsof

sudo ss -lntp 'sport = :7890'
sudo lsof -nP -iTCP:7890 -sTCP:LISTEN

ss uses -l to show only listening sockets, -n to keep ports numeric instead of resolving service names, -t to query TCP, and -p to show processes. To check UDP listeners, use:

sudo ss -lnup 'sport = :1053'

4. Stop the process or change the Clash port?

Once you identify the process, the right action depends on what it does. If it is a leftover Clash core, normally exiting the old client is best. If both clients must remain running, assign different proxy ports, control ports, and DNS listening ports. Changing only mixed-port while leaving the same external-controller may still prevent the second core from starting.

If the port belongs to a long-running development service, container mapping, or LAN service, changing the Clash port is usually more stable. Before choosing a new port, use a system command to confirm that no process is listening on it. Ports must be between 1 and 65535, and HTTP, SOCKS, the control interface, and DNS should not share the same address and port.

If the process appears to have exited but the port query still shows it as listening, one of these situations may apply:

• The client remains in the system tray after its window is closed, so the core process is still running.
• A service manager automatically restarted the process, such as a system service or container restart policy.
• Multiple clients are installed, and one of them is configured to start at boot.
• You queried a different network protocol; for example, you checked only TCP while the conflict comes from a UDP DNS listener.
• The configuration listens on both IPv4 and IPv6 addresses, so check the specific address shown in the log.

Force-terminating a process should be reserved for cases where its identity has been confirmed. On Windows, use Task Manager to end the task. On macOS and Linux, send a normal termination signal first so the program can save its state. If the process keeps returning, disable its startup entry, background service, or container restart policy instead of repeatedly killing its PID.

5. Change mixed-port, HTTP, and SOCKS listening settings

When you need one unified proxy endpoint, keep mixed-port and remove duplicate standalone HTTP and SOCKS listeners. The example below changes the unified endpoint to 7893 and places the control interface on 9091:

mixed-port: 7893
external-controller: 127.0.0.1:9091
allow-lan: false
mode: rule

If different applications need separate HTTP and SOCKS5 endpoints, assign them two different ports:

port: 7893
socks-port: 7894
external-controller: 127.0.0.1:9091
allow-lan: false
mode: rule

Do not configure mixed-port: 7893, port: 7893, and socks-port: 7893 together. Even if some clients ignore certain fields when generating the configuration, do not rely on ambiguous behavior. Every enabled standalone listener should have a clear, unique port.

When editing YAML, preserve correct indentation and data types. Ports are normally written as integers. After saving, reload the configuration in the client or restart the core, then check the log to confirm that the new port is listening. If the client offers settings such as Mixed Port, HTTP Port, or SOCKS Port, use the UI first to avoid a mismatch between the runtime configuration and what the interface displays.

Update the system proxy after changing the port

A core listening successfully on the new port does not mean applications have switched to it automatically. The system proxy may still point to 127.0.0.1:7890. Turning the system proxy off and on again in the client usually writes the current port back to the system. Update browsers, command-line tools, download tools, and development environments that use manual proxy settings as well.

For example, if an application used the HTTP proxy 127.0.0.1:7890 and the new mixed-port is 7893, change it to 127.0.0.1:7893. Applications using SOCKS5 can also connect to mixed-port, but the proxy type must still be set to SOCKS5 in the application. Changing only the port while selecting the wrong protocol can cause connection failures or authentication format errors.

6. Special cases: TUN mode, DNS listeners, and LAN addresses

TUN mode takes over traffic through a virtual network interface, so applications may not connect directly to mixed-port. However, whenever mixed, HTTP, SOCKS, or the control interface is enabled in the configuration, the core still attempts to create the corresponding listener at startup. Enabling TUN does not make ordinary proxy port conflicts irrelevant.

When troubleshooting TUN, first identify the stage where the error occurs. If the log clearly reports a bind failure on 127.0.0.1:7890 or 0.0.0.0:9090, handle it as a port conflict. If it points to a virtual adapter, routing table, permissions, or firewall, inspect the TUN environment instead. Both types of problems can coexist, so resolve them one by one according to the log.

The DNS module is another commonly overlooked source of conflicts. An example configuration might include:

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip

If port 1053 is already used by a local DNS forwarder, the Clash DNS service will fail to start. Check both TCP and UDP usage before deciding whether to change dns.listen in Clash or modify the other service. After changing the DNS listening port, also check whether the system, routing scripts, or other forwarding programs still send requests to the old port.

When LAN access is enabled, the listening scope may expand from the loopback address to network interfaces. One program listening on 127.0.0.1:7890 and another attempting to listen on 0.0.0.0:7890 can still conflict because the latter wants to cover every IPv4 interface. Always consider the address together with the port; comparing port numbers alone is not enough.

7. Verify that the port fix is complete

After fixing the issue, verify everything in a consistent order. This helps prevent leftover system proxy settings, an unapplied configuration, or a node failure from being mistaken for a port problem.

1. Restart the core and confirm that the log no longer contains bind or address already in use.
2. Use netstat, Get-NetTCPConnection, lsof, or ss to check the new port and confirm that the listening process is the current Clash core.
3. Confirm in the client that the current Profile is selected and that Rule, Global, or Direct mode matches the test objective.
4. Re-enable the system proxy and confirm that its address and port match the changes.
5. Check whether the control interface can read nodes, proxy groups, and connection information, ruling out a remaining control-port conflict.
6. Test with a browser or a command-line request configured to use the proxy, then check the connection log for the corresponding request.
7. If you use TUN, also check the virtual adapter, DNS resolution, and routing.

If the port is listening but webpages still cannot be opened, the problem has usually moved beyond the listening conflict. Check whether the configuration loaded successfully, whether the node is available, whether the rules send the destination to the correct proxy group, whether DNS returns a valid result, and whether the application is actually using the new proxy address. A successful listener only confirms that the local entry point exists; it does not guarantee that the upstream proxy path works.

You can temporarily switch to a mode that makes testing easier and watch the connection log for requests, then restore your normal rule mode afterward. If no new connection appears, focus on the system and application proxy settings. If a connection appears but fails, check the node, DNS, rules, and network connectivity.

8. Frequently asked questions about port conflicts

The key test for a port conflict is clear: a process already occupies a listening address and port, while Clash attempts to bind the same combination. Record the log, find the PID, confirm what the process does, adjust the configuration, and update the system proxy. Afterward, verify the Profile, rules, DNS, and TUN so later network failures are not incorrectly attributed to the port.