Clash Port 7890 Already in Use: Find the Process and Change mixed-port on Windows

Check the error first: port already in use or permission denied

A Clash window opening does not mean the proxy core is listening correctly. If the log shows listen tcp 127.0.0.1:7890: bind, along with “Only one usage of each socket address is normally permitted” or Only one usage of each socket address, another process is usually using the same listening address and port. Toggling the system proxy repeatedly will not free the port.

7890 is a common local proxy port, not a fixed requirement for every client. Check the active configuration and core logs to find the port in use. HTTP, SOCKS, mixed, and controller ports serve different purposes; don't substitute one for another just because their numbers look similar.

Log message or symptom	Check first
Address already in use, Only one usage	Find the listening process and check whether two cores are running at once.
Access denied, forbidden by its access permissions	Check Windows excluded port ranges, system policies, and security software restrictions.
The core is listening, but the browser connection is refused	Check whether the browser or system proxy still points to the old port.
The log reports a different port, such as 9090	Troubleshoot the port shown in the log; changing only mixed-port may not fix it.

Find the process listening on port 7890 with netstat

Step 1: Filter for TCP listening sockets

Open PowerShell or Command Prompt in Windows Terminal and run the command below. Standard permissions are usually enough to view listening ports; if you get a permission error, reopen the terminal as an administrator.

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

-a shows connections and listening ports, -n displays addresses numerically, and -o shows the PID. The filter string includes a space after 7890 so it won't match ports such as 78900. This is an example; the final-column value 12480 is for illustration only:

  TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    12480

127.0.0.1:7890 means the process is listening only on the IPv4 loopback address.
0.0.0.0:7890 means the process is listening on all local IPv4 addresses, which may conflict with a listener on the loopback address.
[::]:7890 is an IPv6 wildcard listener; check the socket settings to determine whether it conflicts.
The same PID appearing on multiple lines does not necessarily mean multiple programs are running; one process may be listening on several addresses.

Step 2: Identify the process by PID

Press Ctrl + Shift + Esc to open Task Manager, go to Details, and find the process by PID. If the PID column isn't visible, right-click a column heading and enable it. Right-click the process and select Open file location to confirm which client or service it belongs to.

tasklist /FI "PID eq 12480"

Replace the example number in the command with the PID you found. Common causes include an older client still running in the system tray, another client already running, or a core service that hasn't stopped. Don't end a process just because its name contains Clash or mihomo; check its path and which client it belongs to first.

Alternative: Find the PID in PowerShell

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

The OwningProcess value in the output is the PID. If the command returns no listeners, check the logs from the time of the error; a core that started and exited quickly may have released the port before you checked.

Resolve the conflict: close the extra client or switch to a free port

If another client you no longer use is occupying the port, exit it normally from its system tray menu. If it runs as a separate service, closing the window may only hide the interface without stopping the core. Stop the service through that client's service management screen, then check the port again.

Note the current system proxy address and port, then temporarily turn off the system proxy so apps don't keep trying to use a broken endpoint while you troubleshoot.
Exit the other client normally. If needed, use services.msc to check for its associated service.
Run netstat again to confirm the old listener is gone.
Start the client you want to keep and check the logs to confirm it is listening on port 7890.

If the port is used by a program you need, don't force it to close. Assigning Clash a free port is usually simpler. This guide uses 7897 as an example, but it may not be available on every PC; check before switching:

netstat -ano -p tcp | findstr LISTENING | findstr ":7897 "

Change mixed-port: this is the local proxy endpoint

mixed-port lets HTTP and SOCKS proxy connections use the same local listening port. It is not the node server port or the subscription URL port. The port for a proxy node in your configuration is for remote connections and cannot resolve a local listening conflict on port 7890.

First, check which configuration the client actually uses

Port settings and where they're saved vary by client. Look in Settings for Port, Mixed Port, or mixed-port; if there's a UI setting, change it there first. Clients using the mihomo core may also manage ports through overrides, merged configuration, or runtime settings. Editing a cached subscription file directly may not stick after the next update.

If you need to edit YAML, back up the original file first, then change the active configuration's existing mixed-port value. The example below shows only the field to change, not a complete configuration file; don't use it to replace your entire subscription:

mixed-port: 7897

Put the field at the top level of the YAML, not inside the proxies, proxy-groups, or rules lists.
Don't define mixed-port more than once in the final configuration.
If port: 7890 or socks-port: 7890 is also enabled, the old port may still be in conflict. Check these separate listeners individually.
external-controller is the management interface for the client and core, not a browser proxy port.

Reload, then verify the listening port

After saving, use the client's reload configuration or restart core option. Saving the file without reloading may leave the old process using the previous port. Check the logs, then query port 7897 again; the PID listening on it should belong to the intended core. If the UI shows 7897 but the logs still show 7890, check for configuration overrides and make sure you're editing the active configuration.

Update the Windows system proxy and app-specific proxy settings

Changing the port doesn't automatically update the system proxy in every client. If the core is listening on 7897 while Windows still points to 127.0.0.1:7890, your browser may fail to connect to the proxy. Once the new port is listening, turn the client's system proxy back on and check the address saved in Windows.

Windows 11: Go to Settings → Network & internet → Proxy → Manual proxy setup → Set next to Use a proxy server.
Windows 10: Go to Settings → Network & Internet → Proxy and check the manual proxy settings.
Use 127.0.0.1 for the address and set the port to the active mixed-port, which is 7897 in this example. If you use a proxy script, also check which proxy endpoint the script returns.

Firefox, developer tools, Git, and terminal environment variables may have their own proxy settings and may not follow Windows. To check the proxy variables in the current terminal session, run:

Get-ChildItem Env: | Where-Object Name -Match 'proxy'

If the result still points to 7890, update the setting in the relevant app or variable. To change only the current PowerShell session, run the two lines below. This won't update other open terminals or change settings for all programs.

$env:HTTP_PROXY = 'http://127.0.0.1:7897'
$env:HTTPS_PROXY = 'http://127.0.0.1:7897'

Using http:// in HTTPS_PROXY means the connection to the HTTPS site is tunneled through a local HTTP proxy; it does not downgrade the destination to HTTP. Don't run WinHTTP reset commands casually while troubleshooting: WinHTTP proxy settings are separate from the Windows user proxy settings commonly used by browsers.

No process is listening on the port, but it still won't bind

If netstat shows no process using the port but the log says “access denied,” check Windows TCP excluded port ranges from an administrator terminal. Hyper-V, WSL, containers, and other networking components can affect reserved ranges, but their presence alone doesn't prove they're the cause.

netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=tcp

Check whether 7890 or the proposed port 7897 falls between the start and end ports in the output. If it does, choose a port outside that range that also has no listener. Don't delete Windows reserved port ranges just to free one proxy port; this may affect virtual networking services.

Check the protocol and address in the log

This guide focuses on TCP proxy listeners. If the error specifically mentions UDP, check the relevant UDP endpoint rather than only looking for TCP LISTENING entries. UDP output doesn't have the same listening-state column; use:

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

If the log shows a bind address for a local network interface that no longer exists, check bind-address as well. For local use only, don't expose the proxy to your LAN just to work around the error. Enabling allow-lan changes who can access the proxy; it won't resolve a local port conflict.

Verify the fix: check the listener, proxy endpoint, and outbound connection

Getting a web page to load again doesn't mean every setting is in sync. Check these three layers to quickly distinguish a port issue from a proxy rule or node connection problem.

Check the listener: Query port 7897, confirm the PID belongs to the intended client core, and make sure the logs no longer show a bind error.
Check the proxy endpoint: Send a request with the proxy explicitly specified to test the local endpoint without relying on system proxy settings.
Check the outbound connection: In the client's connection log, check the rule, policy group, and actual route used for the request to confirm they match your expectations.

curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7897 https://www.microsoft.com/

The command above connects directly to the local HTTP proxy. If it immediately reports that it can't connect to 127.0.0.1:7897, keep checking the listener and port. If the proxy connection succeeds but the request times out, investigate node availability, DNS, rules, or the remote network. Getting an HTTP response doesn't necessarily mean the request went through a proxy node: in Rule mode, the destination may connect directly. Check the connection log to confirm.

Finally, reopen your browser and any apps that need the proxy, then restart the client to confirm the port setting persists. If it reverts to 7890 after a restart or subscription update, fix the client's saved settings or override configuration instead of repeatedly editing temporary files. TUN mode won't free the port; even if some traffic is routed through a virtual network adapter, a broken local HTTP proxy endpoint still needs to be fixed separately.