How to Fix a Clash Port Conflict: Find the Process and Change the Port

First confirm that the error is a port conflict

When starting its core, Clash needs to create one or more listening ports on the local machine. Browsers, the system proxy, and other apps send requests to these ports, while the core handles traffic according to proxy groups and rules. If another process already occupies the same port on the same listening address and network protocol, the new listener will usually fail.

Common symptoms include a client interface that opens but whose core stops immediately; a system proxy switch that can be enabled while websites remain unreachable; and log messages such as address already in use, bind, listen tcp, or “port already in use.” Some graphical clients repeatedly try to start the core, so the same error may appear several times in the log.

Do not change the port solely because the network is unavailable. Configuration parsing errors, expired subscription content, unavailable proxy nodes, a disabled system proxy, and firewall restrictions can cause similar symptoms. To confirm a port conflict, first find the exact address in the log, such as 127.0.0.1:7890, 0.0.0.0:7890, or :9090. The number after the colon is the port to check.

Port conflicts versus permission errors

“Address already in use” usually means another listener is present. “Insufficient permissions” or permission denied does not necessarily mean that the port is occupied. Low-numbered ports, reserved system ports, security software policies, or an operating system’s excluded port range can all prevent binding. For everyday configurations, choose an unused high-numbered port and avoid common service ports.

Understand mixed-port, port, and socks-port

Before handling a conflict, identify which configuration field the error refers to. Each field serves different protocols, and different apps must be updated after a change. Common Clash and mihomo listeners include the following.

The most common desktop conflict involves mixed-port. For example, if Client A is still running in the background on 7890 and Client B also tries to use 7890, the core started later cannot create its listener. Another easily missed case is a working proxy port combined with an occupied 9090 used by external-controller. The result may be a graphical interface that cannot connect to the core or read its runtime status.

Do not keep overlapping fields set to the same port number. For example, setting both mixed-port and port to 7890 creates a binding competition inside the same core. If you mainly use a standard desktop system proxy, keeping one mixed-port is usually easier to maintain. Set separate port and socks-port values only when you specifically need separate HTTP and SOCKS5 entry points.

Find listening processes on Windows, macOS, and Linux

After the log identifies the port, find out what is listening on it. First fully quit the current Clash client, wait a few seconds, and then run the command. If the port is still listening, the owner may be another proxy client, a leftover core process, a development server, a container mapping, or a system service.

Windows: find the PID from the port

Check TCP port 7890 in Command Prompt:

netstat -ano | findstr :7890

The last column is the PID. Focus on records whose status is LISTENING, then query the program name by PID:

tasklist /FI "PID eq 1234"

PowerShell can also list the process that owns the listening port directly:

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

Get-Process -Id 1234

If the command reports insufficient permissions, retry from a terminal with the required permissions. When multiple records appear, compare the local addresses. Some programs listen separately on IPv4 and IPv6, so Task Manager may show one process while the command displays two listening records.

macOS: use lsof to view the listener

lsof -nP -iTCP:7890 -sTCP:LISTEN

COMMAND in the output is the process name, and PID is its process number. If standard permissions do not show complete information, use the following after confirming the command:

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

On macOS, closing a window does not always quit the client. Check the menu bar status item and use the client’s quit command to end the main program. If the core process remains after the main program exits, use its PID and executable path to determine which client it belongs to.

Linux: check TCP and UDP separately

sudo ss -ltnp | grep ':7890 '
sudo ss -lunp | grep ':7890 '

The first command checks TCP, and the second checks UDP. Standard HTTP, SOCKS5, and controller interfaces mainly use TCP; DNS listeners and some transparent proxy setups also require a UDP check. If lsof is available, you can use a command similar to the macOS version.

Decide whether to stop the old process or change Clash’s port

Once you identify the owner, there are two ways forward. The deciding factor is not which step is faster, but which service should own the port in the long term.

When stopping the old process makes sense

• The owner is another Clash or proxy client that you no longer use.
• An abnormal exit left an independent old core process running.
• The client starts at boot, but you are switching to another client.
• A test program temporarily occupied the proxy port and can be closed without affecting other work.

Prefer the application’s own quit function or service stop command so it can save state and restore network settings. Consider ending the process by PID only after confirming that it has lost interface control. Run the port check again afterward, confirm that the listening record is gone, and then start Clash.

When changing Clash’s port makes sense

• The original port belongs to a service that must keep running.
• Two proxy cores must run simultaneously for separate testing tasks.
• An organization or device policy reserves a particular port range.
• The client conflicts with a container mapping, development tool, or virtual machine service every time it starts.

The new port should meet three conditions: no current listener uses it, it does not duplicate another field in the configuration, and every client that calls it can be updated. You might first choose a high-numbered port such as 7891 or 17890, then use a system command to confirm that it is free. The maximum port is 65535; negative numbers, text, and out-of-range values are invalid.

Change the YAML configuration without losing it to updates

If the client allows port changes in its settings, use that interface first. The client may use it to generate a synchronized runtime configuration. Before editing YAML directly, confirm whether the file is the active runtime configuration, the original subscription configuration, or a temporary copy generated by the client.

For a single mixed port, the configuration can look like this:

mixed-port: 7891
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9091

If you need separate HTTP and SOCKS5 entry points, assign different ports to the two fields:

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

Validate the configuration before restarting the core. YAML uses spaces for hierarchy; tabs, incorrect indentation, or duplicate fields can cause new parsing errors. Port values should be integers. If the same field appears in merged configurations, override scripts, and subscription content, the effective value depends on the client’s merge process, so checking only one file is not enough.

When running two cores, do not only separate the proxy ports. Check the controller, DNS listener, and transparent proxy ports one by one. Using mixed-port: 7890 for one instance and mixed-port: 7891 for the other is not enough; if both bind to external-controller: 127.0.0.1:9090, the second instance can still fail to start.

Sync system proxy and app settings after changing the port

If the network is still unavailable after fixing the conflict, the most common reason is that the listener changed but requests are still sent to the old port. For example, Clash may now use mixed-port: 7891 while the Windows or macOS system proxy still points to 127.0.0.1:7890. The browser then cannot connect to the new listener.

System proxy

If the Clash client manages the system proxy automatically, first turn the system proxy switch off and then on again so the client writes the new address. Next, check the operating system’s network settings to confirm that the HTTP and HTTPS proxies point to 127.0.0.1 and the new port. With mixed-port, the same port can be entered as the HTTP proxy.

Browsers and independent apps

Some browser extensions, download tools, code editors, chat apps, and remote access tools do not follow the system proxy and instead save their own proxy address. Check their HTTP or SOCKS5 ports individually. If an app is configured for SOCKS5 while only port remains enabled, the protocols will not match. Switch to mixed-port, or assign the app a dedicated socks-port.

Terminal environment variables

Command-line tools may read HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY. Environment variables in an existing session are not updated automatically when the Clash configuration changes. For example, temporary environment variables must use the actual listening port:

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

Variable syntax differs between shells; the example only illustrates the address format. Before changing a startup script or system-wide environment variable, confirm that no other tool depends on the old port.

LAN devices

If a phone or another device uses the Clash proxy on the computer, set allow-lan: true and use the computer’s actual LAN address with the new port. The listening address, inbound firewall rules, and network isolation settings all affect the connection. Do not enter 127.0.0.1 on the phone, because it refers to the phone itself.

Continue checking DNS and the controller port in TUN mode

After TUN mode is enabled, many apps no longer read the system HTTP proxy, so it is easy to assume that mixed-port is unrelated. In practice, the core may still start a mixed proxy port, a controller interface, and a DNS service at the same time. A conflict in any required listener can interrupt startup or cause partial failures.

If the log points to dns.listen, check the DNS configuration, for example:

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

If 1053 is occupied by another DNS forwarder, change it to another free port, and update any configuration that depends on that listening address. If DNS is managed automatically by TUN, do not change it blindly based on an example; use the client’s actual generated configuration and logs.

A controller conflict may look like a core that is still running while the graphical interface reports “connection failed,” “unable to retrieve configuration,” or remains stuck loading. Check the port in external-controller and confirm that the client uses the same address to connect to the core. After changing the controller port, update external panel bookmarks or the controller address in the client as well.

Transparent proxy setups may also involve redir-port, tproxy-port, and firewall rules. Changing only the YAML while leaving the redirection target unchanged sends traffic to the old port. Linux users should also check policy routing, firewall rules, and service startup parameters for a fixed port stored in a separate script.

Review the port conflict in order

After making changes, do not rely only on a green client interface. Review four layers—listeners, proxy entry points, rule processing, and real-world access—to separate port issues from node issues.

1. Fully quit and restart the client. Confirm that the old core has ended so leftover processes do not affect the test.
2. Check the startup log. Confirm that the original bind or address already in use error no longer appears.
3. Query the new port. Use netstat, lsof, or ss to confirm that the listener is the current Clash or mihomo core.
4. Check the system proxy. The address is usually 127.0.0.1, and the port must match mixed-port or port.
5. Check independent app settings. Pay particular attention to browser extensions, terminal variables, download tools, and programs using SOCKS5.
6. Run a local connection test. First confirm that the request reaches the local proxy, then check the log for the corresponding connection record.
7. Separate node failures from port issues. If the log shows the request and rule matching completed but the target connection times out, inspect proxy nodes, policy groups, and the network environment instead of changing the local port again.
8. Trigger a subscription update. Check the port value again afterward to confirm that local settings were not overwritten by subscription content.

The core workflow for a port conflict is: extract the port from the log, find the actual listening process, determine who should own the port, change only the conflicting field, and synchronize every request entry point. Following these steps is more maintainable than repeatedly reinstalling the client or changing several ports at random.