现象：为什么升级或重装后突然「启不动」？

不少用户在 Windows 上更新、覆盖安装或同时试过多个 Clash 系客户端后，会遇到一种很烦人的情况：软件一点启动，日志里就出现 bind: address already in use、listen tcp 失败，或者图形界面直接提示端口已被占用。这时订阅还没机会更新，规则也来不及加载，本质是监听端口这一步就卡住了。这类问题与「规则写错」「节点全红」完全不同，却被误以为是内核损坏，反复重装仍然复现，浪费时间。

从工程角度看，只要你本机已经有一个进程占住了 Clash 想绑定的那个 TCP 端口，新的实例就无法再在同一地址、同一端口上监听，操作系统便会返回「地址已在使用」类错误。占用者通常有三类：上一次未退干净的 Clash / Mihomo 进程、你手动打开的另一个同类客户端，以及碰巧选了同一端口端号的其它软件（本地调试服务、旧版代理工具等）。下文先把Clash 端口被占用常见场景说清楚，再落到Windows netstat 的可复制命令上，最后说明如何通过调整 external-controller（控制端口）或相关监听端口来恢复启动。

先搞清：Clash 在 Windows 上通常占哪些端口？

排障时最怕「不知道冲突的是哪一个」。在典型的 Clash / Mihomo 配置里，至少会涉及以下几类端口（名称以常见 YAML 字段为准，不同图形客户端可能在设置页里用中文表述）：

  • 混合端口（mixed-port）或分别的 HTTP/SOCKS 端口：给你本机浏览器、其它应用做本地入站代理，常见如 7890、7891 等。若此端口被占用，同样会导致启动失败或部分功能不可用。
  • external-controller（外部控制器 / API / 「控制端口」）：用于 Dashboard、脚本或其它组件访问内核 REST API，文档里常写作 127.0.0.1:9090 这类监听。很多读者搜索的「控制端口」指的就是它；本教程后面会用它做示例说明如何改掉冲突。
  • 其它可选监听：例如透明代理、DNS 监听端口等，视你的配置而定；若曾从模板里复制过端口，也容易与旧环境「撞车」。

因此，当你看到报错时，务必对照当前配置里写的端口号去查占用，而不是凭印象猜。若你刚完成安装与基础配置，建议先把订阅与端口页截图保存，再按下面步骤在系统里核对。

第一步：用 netstat 精确查出是谁占了端口（含 PID）

在 Windows 上，Windows netstat 与任务管理器配合，可以快速把「端口 → 进程」这条链打通。以下命令在「命令提示符」或 PowerShell 中均可执行；若权限不足，可尝试右键「以管理员身份运行」后重试。

假设你从配置或报错信息里确认冲突端口是 9090，可先列出监听该端口的相关行（把 9090 换成你的实际数字）：

netstat -ano | findstr :9090

输出末尾一列通常是 PID（进程 ID）。记下这个数字后，可用以下命令查看进程名（将 12345 换成你的 PID）：

tasklist /FI "PID eq 12345"

若你看到进程名是 clash-windows.exe、verge-mihomo.exe、mihomo.exe 或你曾经安装过的客户端主程序名，基本可以认定是旧实例仍在后台，或存在多开冲突。若是其它软件，则需要换端口、退出该软件，或修改其配置。

ℹ️
小技巧：若同一端口出现多行监听，逐行核对协议（TCP/UDP）与本地地址（是否仅为 127.0.0.1）。控制端口往往只监听回环地址，与局域网共享场景下的监听不同，可据此减少误判。

第二步：结束旧进程还是改配置？怎么选

一旦确认 PID 属于不再需要的 Clash 相关进程，最干净的思路是先正常退出托盘里的所有同类客户端，再观察端口是否释放。若托盘已空、任务管理器里仍有残留，可在确认无重要未保存操作的前提下，用以下方式结束进程（将 PID 换成上一步的值）：

taskkill /PID 12345 /F

请谨慎对不清楚的系统进程使用强制结束命令。若 PID 属于正在工作的数据库、远程桌面或其它关键服务，强行终止可能导致数据异常；此时更安全的做法是：保留该进程，转而给 Clash 换一个不冲突的端口。这也正是下一节修改 external-controller 的意义所在。

第三步：修改 external-controller（控制端口）让新实例能启动

若你希望保留其它软件占用的原端口，或不想动系统里未知进程，可直接在配置中为 API / Dashboard 指定新的监听地址与端口。在 Clash / Mihomo 系配置中，对应项一般为 external-controller，常见写法如下（仅作结构示例，端口请换成你选定且未被占用的空闲端口）：

# Example YAML snippet — replace port with a free one on your PC
external-controller: 127.0.0.1:9091

修改后请保存配置文件，并完全重启客户端，让内核重新读取。若你使用图形界面（例如 Clash Verge Rev 等），往往还有「外部控制器地址」或类似表单项；请保证界面里填写的端口与配置文件一致，否则会出现「配置文件已改、面板仍连旧口」的脱节现象。与此同时，若你把混合端口与其它本地软件对齐过，也要一并检查 mixed-port 是否与系统代理里填写的端口一致，避免出现「能启动但浏览器仍不走代理」的第二层问题。

值得一提的是：仅改掉 external-controller 并不会自动修改你用浏览器打开的 Dashboard 书签或脚本里写死的旧地址。请把你收藏的 http://127.0.0.1:9090/ui 这类 URL同步更新为新端口，否则会误以为「面板坏了」。

第四步：排除多开、残留与「安装器没杀干净」

部分用户习惯同时试用多个发行版（例如经典 Clash for Windows 与另一款 Mihomo 图形壳）。若它们默认使用相同或重叠的本地端口，就会产生「先到先得」式的端口抢占。建议在同一台机器上长期只保留一套主用工具链，卸载不用的版本前先退出托盘，再检查任务管理器是否仍有同名进程。

开机自启、计划任务、或服务形态的代理也会在你未留意时绑定端口。若端口反复被占、且 Windows netstat 显示的 PID 指向你并不认识的程序，可结合「进程所在路径」「数字签名」做进一步判断；实在不行，换一个远高于默认段的空闲端口（例如 19090）往往比与未知进程纠缠更快恢复可用性。

若报错指向混合端口或其它监听项

有时日志里写的并不是 external-controller，而是 mixed-port 或单独的 port、socks-port。处理逻辑完全一致：用同一套 netstat + PID 流程定位占用者，再决定杀进程或改配置文件中的端口字段。若你曾把本地代理端口改成与某开发框架默认端口相同（例如 3000、8080）， clash 与开发服务器争抢同一端口的情况会非常常见，值得优先怀疑。

对需要给局域网内其它设备做入站代理的读者，监听地址可能不是 127.0.0.1 而是 0.0.0.0；此时在 netstat 里会看到不同的本地地址列，排查时请以端口号一致为主键，不要被多行输出吓到。我们曾在局域网代理与防火墙一文中写过监听与放行要点，可与本文顺序衔接。

可打印快速清单

  • 从报错或配置中确认冲突端口号，区分是控制端口还是混合端口。
  • 执行 netstat -ano | findstr :端口，读取 PID，用 tasklist 对应到进程名。
  • 若是旧 Clash 实例：先正常退出，无效再考虑 taskkill。
  • 若需保留其它进程：修改 external-controller（及必要时 mixed-port）为空闲端口，保存并重启客户端。
  • 更新 Dashboard 书签、脚本与图形界面里的 API 地址，避免仍指向旧端口。

写在最后

Clash 端口被占用本质是操作系统层的监听冲突，不是玄学问题；掌握 Windows netstat 与 PID 对应关系后，多数「装完就起不来」「更新后一打开就报 address already in use」的案例都能在几分钟内落地。把控制端口（external-controller）与混合端口分清，并在改端口后同步界面与书签，能避免后续一系列「以为坏了其实是连错口」的假故障。

相比在论坛里碎片化搜索命令，更可复制的做法是：固定好你的客户端版本与配置路径，遇到启动失败先跑一遍端口排查，再动规则与订阅。若你希望使用维护活跃、默认设置清晰的发行版，可从我们的客户端下载页获取适合你系统的安装包；与仅依赖过时网帖相比，稳定工具链加上清晰排障顺序，更利于长期使用。→ 立即免费下载 Clash，开启流畅上网新体验。