Clash Port Already in Use? How to Find and Fix a 7890 Conflict

Check the logs first: confirm a bind conflict

Follow these steps: identify the port in the error, find the process listening on it, decide whether to free the port or change it, then update anything that connects to it. Port 7890 is common in Clash configurations, but it isn't fixed or required. Changing it to an available port such as 7893 can resolve a conflict—but only after the client applies the new configuration and your browser, system proxy, and terminal all use the new port.

In the client's logs, look for bind, listen, or address already in use. The exact wording varies by core and operating system; focus on the address, port, and protocol in the error. For example, the log below indicates that the TCP listener failed to bind to port 7890. It doesn't tell you whether the proxy server is reachable:

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

• 127.0.0.1:7890: listening on port 7890 at the local loopback address.
• 0.0.0.0:7890: attempting to listen on all IPv4 interfaces, which may conflict with an existing loopback listener.
• [::]:7890: the IPv6 wildcard address; whether it also covers IPv4 depends on the operating system and socket settings.
• connection refused: usually means the destination isn't listening or has actively refused the connection—not that the port is already in use.

Know the difference between mixed-port and the controller port

The Clash client provides the management interface; a core process usually handles the actual listeners. Clients using Clash Meta (now called mihomo) follow the same separation. A “port” in the interface could refer to several different endpoints. Trace the number shown in the logs instead of changing every field just because you see 7890.

For example, mixed-port: 7890 can handle both HTTP and SOCKS5 connections; you don't also need to set port and socks-port to 7890. Multiple independent listeners configured with the same address and port can conflict with each other. If you only need one mixed endpoint, keep the mixed port and remove any separate endpoints you don't use, once you've confirmed the client supports this setup.

external-controller: 127.0.0.1:9090 is a separate service. Don't set 9090 as your system proxy port; changing it won't fix a failed proxy listener on 7890. The controller port provides administrative access, so keep it bound to localhost and retain its existing authentication settings. Don't expose it to your local network just to troubleshoot a conflict.

Windows: Find the process with netstat

Step 1: Find the listening entry and PID

Open PowerShell or Command Prompt and run the commands below. The first filters for lines containing 7890; the second uses PowerShell to query the local listening port directly:

netstat -ano -p tcp | findstr ":7890"

powershell -NoProfile -Command "Get-NetTCPConnection -LocalPort 7890 -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess"

When reading netstat output, first check that the port in “Local Address” is 7890, then look for a line with the state LISTENING. Searching for the number anywhere in a line can match a remote port or 17890 instead. The last column is the PID. For example, if you find PID 6240, look up the process name with:

tasklist /FI "PID eq 6240"

6240 is only an example; replace it with the PID from your results. To check the executable path and startup arguments, you can continue in PowerShell. You may need administrator privileges to inspect processes owned by other users:

Get-CimInstance Win32_Process -Filter "ProcessId = 6240" |
  Select-Object ProcessId, Name, ExecutablePath, CommandLine

Step 2: Decide what to do based on the process

• Another proxy client: Quit it from the system tray, confirm its background core has stopped, then start the client you want to use.
• A leftover core from the same client: Exit the client normally and check the port again. Once you've confirmed the process path and ownership, end the leftover process in Task Manager.
• A local service you need to keep: Don't force it to stop. Use a proxy port you've confirmed is available instead.
• An unknown process or system service: Check its path and origin first. Don't force-terminate a process based on its PID alone.

If there are no listening entries but you get “An attempt was made to access a socket in a way forbidden by its access permissions,” check whether the port is reserved or the issue is permissions-related. Run netsh interface ipv4 show excludedportrange protocol=tcp to view excluded TCP port ranges. If your candidate port falls within a range, choose an available port outside it rather than deleting system reservations.

macOS and Linux: Check with lsof or ss

macOS: Check TCP listeners only

Open Terminal and run the command below. -nP keeps addresses and ports in numeric form, and -sTCP:LISTEN shows listeners only, making it easier to rule out regular connections. Add sudo only if you need to inspect processes owned by other users:

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

Check the COMMAND, PID, and NAME fields in the output. If another client is using the port, quit it from the menu bar first. If it quickly reappears, check for login items, background services, or automatic restarts.

Linux: Check TCP and UDP separately

sudo ss -ltnp 'sport = :7890'
sudo ss -lunp 'sport = :7890'

# You can also check TCP listeners if lsof is installed
sudo lsof -nP -iTCP:7890 -sTCP:LISTEN

In ss, -t checks TCP, -u checks UDP, and -p displays process information. TCP and UDP use separate port spaces, so a process using UDP 7890 doesn't necessarily explain why a TCP bind failed. Check the protocol shown in the logs.

If systemd manages mihomo, closing the desktop window may not stop the service. If the unit is actually named mihomo.service, check its status with systemctl status mihomo.service, then run sudo systemctl stop mihomo.service if you're sure it should be stopped. If the unit has a different name, use the name from your deployment; otherwise, you may mistakenly think the core has stopped.

Change mixed-port: using 7893 as an example

Replace 7890 with 7893 in the earlier commands and make sure the candidate port isn't already in use. Port 7893 isn't guaranteed to be available on every machine; it's just an example for this configuration. Change the configuration the client actually loads—not an unused YAML file.

1. Look for “Mixed Port” or mixed-port in the client's active configuration or runtime settings. Menu labels vary by client, so use the actual field name as your guide.
2. If you manage the configuration with YAML, change the top-level field and use spaces for indentation. Don't put the port under proxies or proxy-groups.
3. Check whether the client has any port overrides. Subscription, override, and runtime settings may all affect the final value.
4. Save and apply the configuration. If the client asks you to restart the core, do so, then check the logs and listening status again.

The following is a port-related snippet, not a complete subscription configuration. If an application still needs a separate SOCKS endpoint, you can use a different port:

# Merge into the top level of your existing configuration; keep other proxies, groups, and rules
mixed-port: 7893
socks-port: 7894
allow-lan: false

# Keep the control API separate from proxy endpoints; retain existing authentication settings
external-controller: 127.0.0.1:9090

If you only use the mixed port, you don't need to add socks-port just to match this example. If your existing configuration also enables port: 7890, changing only mixed-port may leave the separate HTTP listener on 7890 and still cause an error. Check each listener field individually.

Update your system proxy, browser, and terminal

After a port change, the most common follow-up problem is that the core listens on 7893 while applications still send requests to 7890. Reimporting the subscription usually won't help; check where traffic enters the proxy instead.

If the client manages your system proxy automatically, toggle its “System Proxy” setting off and back on after applying the new port, then check your system settings. If you use PAC auto-configuration, check the proxy address returned by the PAC file; changing the manual proxy fields may not affect traffic routed through PAC.

Terminal environment variable example

In the current shell on macOS or Linux, you can set an HTTP proxy like this. Use http:// for https_proxy: HTTPS sites are accessed through the HTTP proxy's CONNECT method, not downgraded to plaintext:

export http_proxy=http://127.0.0.1:7893
export https_proxy=http://127.0.0.1:7893

# Use a separate SOCKS5 proxy if needed and supported by the tool:
export all_proxy=socks5h://127.0.0.1:7893

These commands affect only the current shell and processes started afterward; they don't update applications that are already running. If you set both HTTP and SOCKS variables, precedence depends on the tool. When troubleshooting, specify the proxy explicitly to avoid ambiguity. Also check uppercase variables such as HTTP_PROXY and HTTPS_PROXY, as well as old values in your shell startup files.

TUN mode routes traffic through a separate path; it doesn't resolve a bind conflict on a local proxy endpoint. An application may connect normally through TUN while the listener on 7890 still fails. Alternatively, it may have an incorrect explicit proxy set, causing the connection to fail before normal forwarding begins. Test these issues separately.

Verify the fix: listener, request, and restart

1. Check the listener: Query port 7893 again, confirm the PID belongs to the expected core process, and check that the logs no longer show a bind error for that endpoint.
2. Test a proxy request: Send a request with an explicit proxy setting before relying on your system proxy or browser configuration.
3. Check your everyday apps: Open your browser and the tools you actually use, then make sure they no longer point to the old port.
4. Check that the fix persists: Restart the client and update the subscription once. Confirm the port hasn't been overwritten and that another client hasn't started and claimed it first.

The commands below send an HTTP proxy request through the new mixed port. On Windows, use curl.exe to avoid conflicts with a same-named command alias in some PowerShell environments:

# macOS / Linux
curl --noproxy "" --proxy http://127.0.0.1:7893 --connect-timeout 5 --max-time 15 -I https://clash03.com/

# Windows
curl.exe --noproxy "" --proxy http://127.0.0.1:7893 --connect-timeout 5 --max-time 15 -I https://clash03.com/

An HTTP response confirms that the request received a response, but doesn't prove it went through a remote proxy node: in rule mode, the destination may match a direct-connection rule. If you see Failed to connect, check the local listener and port first. If the local proxy accepts the connection but the request later times out upstream or fails with a TLS error, investigate your node, DNS, rules, and network environment. Don't keep changing the local port without evidence.

Common issues that remain

• Port stays busy after exit: Check for background services, other user sessions, or a leftover client core.
• Port immediately reverts: Check port overrides and subscription update behavior, and make sure you're editing the active configuration.
• Port is free but the client won't start: Check for permissions issues, system-excluded ports, an invalid bind address, or a YAML parsing error. Follow the new error in the logs.
• Dashboard is offline but websites work: Check the control API address, port, and authentication separately. The proxy endpoint isn't the dashboard API.

After troubleshooting, set only one client to start automatically for everyday proxy use, and note the actual settings—for example, “mixed port 7893, standalone SOCKS port enabled or disabled, controller port 9090.” If the conflict returns, start by checking which process is listening; that's usually more useful than reinstalling the client. For a full reference to the configuration fields, see the Configuration Reference. For installation and first-time setup, see Quick Start.