Clash 提示端口被占用怎么办:用命令定位冲突进程并修改混合端口

报错信息解读:为什么会出现 address already in use

Clash 与基于 Clash Meta(mihomo)内核的客户端启动时,会尝试监听配置文件里指定的几个端口:混合端口(mixed-port,同时接受 HTTP 与 SOCKS5 请求)、独立的 HTTP 端口(port)与 SOCKS5 端口(socks-port),部分客户端还会额外监听一个 RESTful API 端口(external-controller,常见默认值 9090)。当其中任意一个端口已经被系统里另一个进程占用,内核在绑定(bind)阶段就会失败,日志或弹窗里通常会看到类似下面的信息:

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

这条报错本身已经把问题说得很清楚:内核想监听 7890 端口,但操作系统拒绝了,因为这个端口已经"名花有主"。这类问题不是配置文件语法错误,也不是订阅或代理节点的问题,纯粹是本机端口资源冲突,处理思路统一分两步:先找出占用端口的进程,再决定"停掉它"还是"换个端口给 Clash 用"。

注意

如果你同时装了两个 Clash 系列客户端(例如 Clash Verge Rev 和 ClashX Meta),又都设置成开机自启,几乎必然会互相抢占默认端口。这种情况优先卸载或关闭其中一个,而不是反复改端口。

Windows:用 netstat 与 PowerShell 定位占用端口的进程

Windows 上最直接的办法是打开命令提示符或 PowerShell,用 netstat 查看端口对应的进程 ID(PID),再用任务管理器或 taskkill 反查、结束进程。以默认的 7890 端口为例:

netstat -ano | findstr :7890

输出的最后一列就是 PID,例如显示 12480,再执行:

tasklist | findstr 12480

就能看到是哪个可执行文件占用了这个端口。如果确认这个进程可以关闭,可以直接结束它:

taskkill /PID 12480 /F

PowerShell 用户也可以用一条命令直接拿到端口对应的进程名,信息更直观:

Get-Process -Id (Get-NetTCPConnection -LocalPort 7890).OwningProcess

常见的占用来源包括:上一次 Clash 客户端异常退出后残留的后台进程(尤其是通过任务管理器强制关闭窗口、但内核进程未随之退出的情况)、其他基于 Clash 内核的工具、以及部分下载工具或本地代理调试工具默认也会占用 7890 附近的端口段。

macOS:用 lsof 排查端口占用

macOS 下最常用的是 lsof(list open files),它可以按端口号反查占用进程:

sudo lsof -i :7890

输出中 COMMAND 列是进程名,PID 列是进程号。确认无误后,结束进程:

kill -9 对应的PID

如果习惯用 netstat,macOS 也保留了兼容写法,但普遍建议直接用 lsof,信息更完整。另外要注意,ClashX、ClashX Meta 这类基于菜单栏的客户端,退出菜单栏图标不一定会同步终止后台的核心进程,遇到端口冲突时先确认核心进程是否真的退出了,而不是只关闭了界面。

ps aux | grep -i clash

这条命令能把当前系统里所有和 clash 相关的进程列出来,方便一次性清理残留实例。

Linux:用 ss 与 fuser 定位并结束进程

较新的发行版建议用 ss 代替已经逐渐被弃用的 netstat:

sudo ss -tulnp | grep 7890

输出里 users:(("进程名",pid=1234,...)) 部分即为占用信息。也可以用更简洁的 fuser 直接定位并选择性结束:

sudo fuser -k 7890/tcp

该命令会直接结束占用 7890 端口的进程,适合确认占用方是可以安全终止的旧进程时使用。如果通过 systemd 管理 mihomo 或 clash 服务,更稳妥的做法是先检查是否存在两个服务实例同时启动:

systemctl status mihomo
systemctl status clash

如果两个服务都在运行且都尝试监听同一端口,应停用其中一个,而不是靠改端口"绕过去",否则规则、订阅更新等功能会分裂在两个进程上,状态不一致,排查起来更麻烦。

修改 Clash 配置文件中的混合端口

如果占用端口的程序不方便关闭(比如是系统服务或另一个长期在用的工具),更省事的办法是让 Clash 换一个端口监听。Clash Meta(mihomo)内核推荐直接使用混合端口字段:

mixed-port: 7895
allow-lan: false
bind-address: "*"
external-controller: 127.0.0.1:9096
secret: ""

只需要把 mixed-port 的值从默认的 7890 改成一个未被占用的端口(建议选 10000 以上、且不与常见软件冲突的号段,如 7895、17890 等),保存后重启客户端即可。如果同时使用旧式的 port(HTTP)与 socks-port(SOCKS5)字段而不是 mixed-port,也要一并检查是否有冲突:

port: 7891
socks-port: 7892
external-controller: 127.0.0.1:9097

提示

external-controller(RESTful API 端口,默认常见为 9090)同样会占用一个端口,如果 Clash 面板(Dashboard)打不开,报错信息里出现的是 9090 而不是 7890,原理和处理方式完全一样,只是要改的字段不同。

大多数图形界面客户端(Clash Verge Rev、Clash Plus、FlClash 等)也提供了在设置页直接填写端口号的入口,效果等同于修改配置文件里的对应字段,改完后同样需要重启核心或客户端才会生效。修改端口后,别忘了同步更新系统代理设置或浏览器插件里填写的端口号,否则会出现"客户端正常运行,但浏览器仍然连不上"的情况——这其实不是端口冲突本身的问题,而是端口改了之后系统代理没跟着改。

常见占用元凶与规避建议

根据反馈整理,7890 附近端口段最常见的冲突来源包括以下几类,提前了解可以省掉一轮排查:

上一个 Clash 进程未彻底退出:直接点右上角关闭窗口,核心进程可能仍在后台运行,再次启动就会自己跟自己抢端口。
同时安装了多个 Clash 系列客户端:例如电脑上既有 Clash Verge Rev 又有旧版 Clash for Windows 残留,两者若都设置了开机自启,极易冲突。
其他代理/调试工具:部分本地开发调试代理工具、抓包工具默认也会监听 7890 或相近端口。
容器或虚拟化环境的端口转发:使用 Docker 或虚拟机做端口映射时,容器内服务映射到宿主机的端口有时会恰好落在这个区间。

规避建议很简单:只保留一个正在使用的 Clash 系列客户端,卸载或彻底禁用其余的自启项;如果确实需要多个代理工具并行,提前为每个工具规划互不重叠的端口区间,而不是等报错了再临时改。

常见问题

改了端口之后,客户端还是提示端口被占用,是为什么?

先确认配置文件保存路径和客户端实际加载的配置文件是同一个文件——有些客户端支持多配置切换,改的可能不是当前生效的那份。另外要检查新填的端口是否恰好又撞上了别的服务,可以换一个更冷门的四位或五位数端口重试,并用前文的命令再查一次该端口是否空闲。

结束占用端口的进程安全吗,会不会影响系统?

如果确认占用方是残留的 Clash 进程或其他可以重新启动的普通应用,结束它是安全的。但如果 lsof/netstat 显示占用方是系统级服务或不熟悉的进程,建议先搜索该进程名确认用途,或者直接选择给 Clash 换端口,避免误杀系统服务。

手机端(Android/iOS)也会出现端口占用问题吗?

移动端沙盒机制更严格,端口冲突主要出现在同时运行多个 VPN/代理类应用时,系统通常只允许一个 VPN 配置生效。遇到连接失败,先检查是否有其他代理类 App 正在后台运行 VPN 服务,关闭其一即可,处理逻辑比桌面端简单。