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

First, identify which listening port is conflicting

When Clash, Clash Meta (mihomo), or a GUI client fails to start, the log often includes bind: address already in use, listen tcp 127.0.0.1:7890, or Only one usage of each socket address is normally permitted. They all indicate the same type of problem: the core is trying to listen on a local port, but that address-and-port combination is already occupied by another process.

Do not change the configuration just because you see 7890. Read the complete log first and confirm whether the failed listener is HTTP, SOCKS, mixed proxy, the controller, or DNS. Each port has a different role, and changing it may require corresponding updates in client settings.

Check the address shown in the log as well

• 127.0.0.1:7890: listens only on the local IPv4 loopback address, so devices on the LAN cannot access it directly.
• 0.0.0.0:7890: listens on all IPv4 network interfaces and is usually related to “Allow LAN” in the client.
• [::]:7890: listens on all IPv6 interfaces. On some systems, it may also affect IPv4 listeners on the same port.
• 127.0.0.1:9090: typically the external controller, not the proxy port to enter in a browser.

The same port number on different listening addresses does not necessarily mean a conflict; whether both can coexist depends on the operating system, IPv6 dual-stack behavior, and application settings. During troubleshooting, record the protocol, listening address, port, and process ID rather than just one number.

Find the process holding the port with netstat on Windows

Windows 10 and Windows 11 both include netstat. Fully quit the Clash client, then open PowerShell or Command Prompt with standard permissions and check whether port 7890 still has a listener.

Step 1: Find the listener on port 7890

netstat -ano | findstr :7890

The output may contain several lines. Look for a TCP entry whose state is LISTENING; the last column is the PID. In the example below, the PID is 14672:

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    14672

findstr :7890 also matches connections to a remote port 7890, so the port number alone is not enough. Confirm that 7890 appears in the “Local Address” column and that the state is LISTENING.

Step 2: Map the PID to a program

tasklist /FI "PID eq 14672"

If the result is mihomo.exe, clash.exe, or another proxy client core file, the old instance probably did not exit. If it is a development server, container port-forwarding tool, or another local network program, decide which process is safer to move to a different port.

You can also open “Task Manager” → “Details”, sort by the PID column, and find 14672. If PID is not shown by default, right-click the header, choose “Select columns”, then enable “PID (Process Identifier)”.

Step 3: Check TCP and UDP separately with PowerShell

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

Get-Process -Id 14672

DNS, TProxy, and some forwarding entries may also use UDP. To inspect UDP endpoints, run:

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

UDP has no LISTENING state, so you cannot reuse the TCP filter as-is. If the Clash log explicitly says listen udp, use Get-NetUDPEndpoint or netstat -ano -p udp.

Step 4: Exit normally before forcing a process to stop

1. If another proxy client owns the port, choose Exit from its tray menu.
2. If the process runs as a Windows service, open services.msc, locate the service, and stop it.
3. Only consider ending the process after confirming that it is not handling downloads, container forwarding, or development tasks.
4. Run netstat -ano | findstr :7890 again and confirm that the listening entry has disappeared.

Force-stopping a process only releases the port temporarily. If the program launches at startup, has automatic service recovery enabled, or restarts after a crash, the port may reappear within seconds. In that case, change the startup settings or assign one of the programs a fixed new port.

Find conflicts with lsof and ss on macOS and Linux

macOS includes lsof for checking listeners. Quit the Clash GUI client, open Terminal, and run:

lsof -nP -iTCP:7890 -sTCP:LISTEN

-nP keeps addresses and ports in numeric form, avoiding delays from hostname resolution. In the output, COMMAND is the program name and PID is the process ID. To view the complete launch arguments, run:

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

To check UDP listeners, use:

lsof -nP -iUDP:1053

If the old core was launched by the client, quit the client from the macOS menu bar first. Running kill 14672 directly may cause the client’s watchdog to start the core again immediately, making the PID change while port 7890 remains occupied.

Prefer ss on Linux

Modern Linux distributions usually include ss. The following command shows TCP processes listening on port 7890:

sudo ss -ltnp 'sport = :7890'

To check DNS listeners or other UDP ports:

sudo ss -lunp 'sport = :1053'

If mihomo is managed by systemd, also check the service status. The service name depends on how it was installed; common commands include:

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

Once you confirm that a duplicate service is responsible, stop the old instance using its service name, then decide whether to disable automatic startup. Do not delete service files without understanding their purpose: they may also configure TUN permissions, route initialization, and firewall cleanup.

Change mixed-port, port, and controller ports

If the conflicting program must keep using the original port, assign Clash an unused one. Choose a port above 1024 with no current listener, such as changing 7890 to 17890. The valid range is 1–65535, but ports below 1024 usually require extra privileges on macOS and Linux and are not ideal for a regular desktop proxy entry.

Configuration using only mixed-port

mixed-port accepts both HTTP and SOCKS5 proxy traffic on one port. For a desktop setup that needs a single local entry point, the configuration is straightforward:

mixed-port: 17890
allow-lan: false
bind-address: 127.0.0.1
external-controller: 127.0.0.1:19090

After the change, set both the HTTP and HTTPS system proxy addresses to 127.0.0.1:17890. Applications using SOCKS5 should use 127.0.0.1:17890 as well, with the protocol set to SOCKS5.

Separate HTTP and SOCKS5 listeners

port: 17890
socks-port: 17891
allow-lan: false
external-controller: 127.0.0.1:19090

Use this setup when the protocols must remain distinct. Set browsers or the system HTTP proxy to 17890, and terminal tools that support SOCKS5 to 17891. Do not assign the same port to mixed-port and port, or the core will still fail because of a duplicate bind.

How to change the DNS listening port

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

After moving DNS from 1053 to 11053, update any forwarder that depends on that address as well. If local dnsmasq, routing rules, or the client’s DNS hijacking configuration still points to 1053, DNS requests will not automatically move to the new port.

Check the configuration source when changing ports in a GUI client

Menu names vary between clients. Common paths include “Settings” → “Preferences” → “Port settings” or “Settings” → “Clash settings” → “Mixed port”. After saving, use “Restart core” rather than simply closing the settings window.

If the port comes from a subscription configuration, editing the current YAML directly may be overwritten during the next update. A more reliable approach is to use the client’s override feature, such as “Profiles” → “Overrides” → “Port”, and save the local port as a persistent setting. If no override feature is available, record the change and check whether the port reverted after each subscription update.

Verify the port, system proxy, and an actual connection after changing settings

A successful configuration save does not mean the issue is resolved. A complete check has four steps: verify that the old port is free, confirm that the new port is listening, update the system proxy, and make a real proxy request.

1. Confirm that the new port is listening

On Windows, run:

netstat -ano | findstr :17890
Test-NetConnection 127.0.0.1 -Port 17890

In the Test-NetConnection output, TcpTestSucceeded should be True. On macOS or Linux, run:

lsof -nP -iTCP:17890 -sTCP:LISTEN

Check 7890 again at the same time. If another program still listens on the old port, it may not affect Clash, but it confirms that the original source of the conflict remains and that the old and new programs now coexist on different ports.

2. Check whether the system proxy still points to the old port

• Windows 11: open “Settings” → “Network & internet” → “Proxy” and check the port for the manual proxy server.
• macOS: open “System Settings” → “Network” → current network → “Details” → “Proxies”, then check Web Proxy and Secure Web Proxy.
• Browser extensions: check the HTTP, HTTPS, or SOCKS5 port in the proxy profile.
• Terminal environment variables: check whether HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY still contain 7890.

Most Clash GUI clients write the new port automatically when “System Proxy” is enabled, but manually configured browsers, development tools, and command-line environments do not update themselves. If the client shows that it is running but the browser cannot connect after a port change, the caller is usually still using the old port.

3. Make an explicit proxy request with curl

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

If you use the separate SOCKS5 port 17891, run:

curl -I --socks5-hostname 127.0.0.1:17891 https://example.com

If the command returns HTTP response headers, the local port accepted the connection, the proxy protocol matched, and the request completed. Connection refused means the new port is not listening. A long timeout means you should continue checking the node, proxy group, DNS, and network connectivity. A protocol error may mean that an HTTP client connected to a SOCKS5-only port.

4. Monitor the core log and connection list

Open the client’s “Logs” page and set the level to info. During a test request, you should see the target domain, the matched rule, and the selected policy—for example, a domain matching DOMAIN-SUFFIX and being routed through a proxy group. Then open “Connections”, confirm that the source address is 127.0.0.1, and check that the uploaded and downloaded byte counts change.

Troubleshooting order for recurring port conflicts

If the conflict returns some time after changing the port, the system likely has an automatic startup item or a configuration override. Check the following in order; it is more effective than repeatedly switching ports.

1. Check whether two Clash clients start automatically. For example, an old client may remain in the login items while a new client is also configured to launch at startup; both will try to listen on 7890.
2. Check for both a GUI and a standalone core service. When a GUI client already manages mihomo, do not also let systemd, launchd, or a Windows service start another copy with the same configuration.
3. Check the override after a subscription update. If the port was 17890 before the update and changed back to 7890 afterward, the local change was not saved as a persistent override.
4. Check external-controller. If the proxy port works but the interface continually reports connection failures, the conflict may be on 9090 rather than 7890.
5. Check both TCP and UDP for DNS. Some DNS services listen on both protocols, so checking only TCP may miss a process occupying UDP 1053.
6. Check how “Allow LAN” changed the listening scope. Switching from 127.0.0.1 to 0.0.0.0 exposes the listener on more interfaces and may create a conflict with an existing service.

A port plan that can scale long term

The port number itself does not affect rule matching, node latency, or proxy speed. What matters is that each listening address is owned only by the intended process and that the system proxy, browser, DNS forwarder, and control panel all use the same updated configuration. Keep a port record after making changes so you can quickly check it when upgrading the client, switching cores, or updating subscriptions.