What "Port Already in Use" Really Means for Clash on Windows

Clash, Clash Verge Rev, and other shells built on the Mihomo/Clash Meta core all rely on a local listener that your browser and other apps can reach through the system proxy, manual PAC files, or per-app settings. A very common default is to expose a single mixed port that serves both HTTP and SOCKS on one TCP number. Tutorials, subscription snippets, and template configs often set that number to 7890 because it is easy to remember and has become a de-facto convention. When the core restarts, it asks Windows for an exclusive lock on that port. If the operating system says no, the UI surfaces an error in plain language: the address is in use, bind failed, or the listener is unavailable.

Users interpret that message as a mysterious bug, but the mechanism is simple. Port numbers are 16-bit identifiers on each machine. One process may listen on a port at a time for a given address family, interface, and protocol mode. A second process that needs the same combination must wait or choose a different number. A Clash port conflict on Windows therefore is not a certificate issue and not a failed subscription download; it is a scheduling problem between programs that all want 7890.

Two situations appear constantly in support threads. The first is an honest second consumer: a previous instance of a proxy, a developer tool, a container helper, or even another user session still holding 7890. The second is self-inflicted: you updated the GUI, installed a second client for testing, or the tray icon hid while the process remained alive, so the "new" Clash cannot bind. Both resolve once you name the process occupying the port and decide who gets to keep it.

Read the Error and Your Active Profile

Before you type a single netstat line, look at the exact wording in the log or status banner. It should mention a TCP port, sometimes together with 127.0.0.1, ::1, or 0.0.0.0. If the text references 7890, you already know the listener that failed. If it references 9090, 7891, 7892, or another value, the mixed listener may be customized, or a different service such as the external controller may be the one colliding. Always chase the number that the error names instead of assuming 7890 forever.

Open the merged runtime configuration the core actually uses, not a stale export on your desktop. In GUI clients you often have a view running config action, or a path in settings that points to the profile directory. Scan for a top-level mixed-port key. That field defines the local TCP port the core tries to own. A matching port key may exist for legacy HTTP-only mode; a socks-port can appear in older material. In modern Meta configs the mixed listener is the one most users need for a single "system proxy" style endpoint, which is why mixed-port and port 7890 show up in the same conversation.

Pairing this read with a structural layout guide keeps you oriented when multiple YAML documents exist. For everyday Windows install flows and where ports appear in the UI, the Clash Verge Rev Windows setup guide remains a good companion because it walks through the relationship between the tray app, the core, and the configuration path where your numbers live.

Use netstat to Find the Process ID (PID)

On Windows, the netstat command lists active connections and listening endpoints. The combination you want displays listening sockets, numeric addresses, the protocol, and the owning PID. Open either Command Prompt or PowerShell with ordinary user rights; administrator elevation is not required to view local listeners, though you may need admin rights later if you decide to terminate a protected service.

Run a filter that only shows TCP entries in the listening state, prints numeric hostnames and ports, and includes process identifiers:

netstat -ano | findstr "7890"

Replace 7890 with the port you saw in the error. You should get one or more lines similar to LISTENING on 127.0.0.1:7890 or 0.0.0.0:7890, with the last column as a positive integer. That integer is the PID on Windows you will resolve to a human-readable name in the next step. If the output is empty, the bound port is gone already or you mistyped; rerun while the app that should hold the port is started.

When multiple rows appear, read them carefully. You might see both IPv4 and IPv6 loopback, or a bind on all interfaces plus another on localhost. You still get one canonical PID for the owning service in typical setups. If two different PIDs show up, you are looking at two separate programs, which means one situation is rarer: two listeners split across dual-stack or a bugged restart. The resolution path remains: identify each PID, map each to a process, and decide which one should remain.

Map the PID to a Program Name

With the PID from netstat, you have three lightweight options that work everywhere on Windows. First, tasklist /FI "PID eq 12345" prints the image name, which is often enough. Second, PowerShell: Get-Process -Id 12345 | Select-Object Name,Path includes the on-disk path, which is valuable when the image name is generic. Third, Task Manager, Details tab, with columns configured to show PID, lets you right-click a row and open file location if you are more comfortable in a GUI than in a shell.

Interpreting the name is the heart of the decision tree. If the process is the same Clash core you thought you had quit, the fix is a clean shutdown, killing the stuck child if necessary, and reopening. If the process is another Clash-based GUI, uninstall or exit it before reusing 7890. If it is a different proxy, IDE, or cloud sync agent that you rely on, your choices are: change that other program’s port in its own settings, or change your Clash mixed-port to a free value and re-point Windows at the new number.

Change mixed-port in the Real Config

Pick a new TCP port that is not reserved by Windows well-known services, not used by the other app you just identified, and not blocked by a corporate policy list. A practical range for personal proxy listeners is 10000–65535, excluding anything you already use for game launchers, remote desktop helpers, or development servers. For example, 7897 or 17890 are easy to type and unlikely to overlap if you are not already running a dozen custom tools. Document your final choice in a text note, because the next three layers must match it: the YAML, the Windows proxy dialog, and any secondary devices that shared your PC’s address.

Edit the configuration file the core loads. Set mixed-port: 7897 (or your chosen value) and remove conflicting combinations if the template also sets redundant legacy ports you no longer use. Some GUIs let you type the new number in a settings form and will rewrite YAML for you; that is fine as long as you save and confirm the file on disk. After saving, restart the core, not just the front window. A partial reload sometimes keeps the old socket around in edge cases, especially after sleep, so a full stop from the tray and relaunch is the least ambiguous path for beginners.

When the listener comes up, repeat netstat -ano | findstr "7897" to verify that your expected PID is now LISTENING and that 7890 is no longer in use for your stack unless you left another program on it intentionally. A quick loopback test from PowerShell—for example, opening a TCP client against 127.0.0.1:7897—is optional, but the successful absence of a bind error in the Clash log is the primary signal you need.

Update Windows System Proxy to the New Port

Changing mixed-port alone does not change how the operating system forwards browser traffic. Windows Settings, the classic Internet Options dialog, and the proxy toggle that your GUI may manage all need the same 127.0.0.1 address with the new port number in the system proxy fields. A mismatch produces symptoms that feel like a dead proxy even though the core is healthy, because the browser still talks to the old empty socket.

If the client offers an integrated "set system proxy" switch, turn it off and on to rewrite the value, or re-save the same toggle after the port field updates. If you set proxies manually, open Settings > Network & Internet > Proxy and update the address under Manual setup. The HTTP and secure lines often share one host:port; SOCKS may live in a separate field depending on the Windows build. The goal is simple alignment: the host remains loopback, the port is your new 7890 replacement, and HTTPS traffic uses the same proxy endpoint your mixed listener advertises, unless you intentionally split schemes.

WSL, Docker, and Browsers: Remember Every Consumer

Loopback and port forwarding deserve a callout. Windows Subsystem for Linux does not use 127.0.0.1 the same way the host does; a Linux distribution in WSL2 reaches the host through a different gateway IP, and environment variables that embed http://127.0.0.1:7890 must be updated in every shell profile that exported them. Our walkthrough for WSL2, apt, and git through Clash on Windows already explains discovery of the host address and the firewall angle; after you change mixed-port, revisit those exports so apt and git still point at a live listener, not a closed door.

Container Desktop tools that inject proxies into application manifests need the same check. A stale HTTP_PROXY at 7890 will fail silently until you trace it. Browser extensions with their own per-extension proxy, corporate VPNs that layer PAC files, and antivirus HTTPS scanners can also interpose unexpected flows. If only one browser is broken, suspect extension-level overrides first and system proxy second.

When the Conflict Is Not 7890 at All

Advanced users run multiple local services around the same stack. external-controller commonly defaults to 9090; a dashboard, dashboard container, or phone remote might collide there. TUN and meta fields like redir-port and tproxy-port matter when you use transparent interception on specialized interfaces. dns listeners on 53/5353 can clash with other resolvers. If the error name never mentions mixed-port, search your YAML for the exact value that appears in the log and then run the same netstat pass with that number. The triage method stays identical: find PID, map name, make a port decision, restart listeners in order, and re-test.

Safety Notes Before You Delete or Kill Processes

Never terminate a system process you do not recognize until you are sure it is not part of a security or enterprise stack. Forum threads on Clash port conflicts and similar searches in multilingual communities show how often people kill the wrong PID and break connectivity their school or employer requires, not realizing that another agent owned the port. If the PID is a Windows service, prefer stopping it with service management tools, not brute force, unless you are already comfortable repairing boot configuration.

Back up your working YAML before editing. The change is small, but a typo in indentation can prevent the whole profile from loading, which is worse than a port collision because the last valid mixed listener is down entirely. A dated copy in Documents costs nothing and shortens recovery time. If the GUI has an export, take it, then make your numeric change on the copy, validate, and promote.

Open Source, Verifiable Builds, and Download Hygiene

Clash Meta remains an open project; reading the upstream changelog helps when the core tightens default listeners or renames log lines between releases. For day-to-day installation, a curated download page that matches the documentation reduces the chance you mix an older beta that still hammers 7890 with a new GUI that expects 7891. Keeping one maintained client, one profile directory, and a predictable mixed-port is cheaper than random reinstalls when Windows reports an address in use.

Bottom Line

A port 7890 or other mixed listener error on Windows is almost always a concrete second owner of the same TCP number. netstat with findstr makes that owner visible, tasklist or PowerShell names it, and you either free the number or re-home Clash to a new mixed-port and rewire the system proxy to match. Once those layers agree, the core starts, browsers connect, and you can return to the routing problems you actually care about. → Download Clash for free and experience the difference between guessing at port ghosts and a listener you can see in the task list and verify with a single command.