Clash 提示端口被占用怎么办:定位 7890 端口冲突进程并修改混合端口
启动报 bind: address already in use 说明默认端口被其他程序占用。本文给出 Windows、macOS、Linux 三平台查找占用进程的命令,以及在客户端里修改 mixed-port 的完整步骤。
报错信息说明什么问题
Clash 内核启动时会按配置文件里的端口设置监听本地端口,默认的混合端口 mixed-port 是 7890,同时兼容 HTTP 与 SOCKS5 两种协议。启动日志里如果出现类似下面这行,说明内核尝试绑定 7890 端口时失败:
level=fatal msg="Start Http Server error: listen tcp 127.0.0.1:7890: bind: address already in use"
这条报错和网络是否连通没有关系,纯粹是操作系统层面的端口占用冲突:某个进程已经在监听 7890 端口,新启动的 Clash 内核抢不到这个端口,于是直接退出或者代理页面显示"未运行"。常见触发场景包括:上一次 Clash 进程没有完全退出、同一台机器上装了两个 Clash 系列客户端、或者其他代理软件(比如某些下载工具、开发调试代理)恰好也把默认端口设成了 7890。
排查思路很直接:先确认到底是谁占着这个端口,再决定是关掉那个进程,还是把 Clash 的端口改成别的数字。下面按平台给出具体命令。
Windows:用 netstat 定位占用进程
打开命令提示符或 PowerShell,执行:
netstat -ano | findstr 7890
输出的最后一列是进程 PID,例如:
TCP 127.0.0.1:7890 0.0.0.0:0 LISTENING 8824
拿到 PID 之后,用任务管理器搜索这个 PID 对应的进程名,或者继续用命令行查看:
tasklist /FI "PID eq 8824"
确认是残留的旧 Clash 进程或者其他不需要保留的程序后,可以直接结束它:
taskkill /PID 8824 /F
如果占用进程就是 Clash 自己的另一个残留实例(常见于强制关机后进程没清干净),结束后重新启动客户端即可恢复正常。如果占用方是另一个长期需要运行的程序,建议走后文的改端口方案,而不是每次都手动杀进程。
macOS 与 Linux:用 lsof 或 ss 定位占用进程
macOS 和大多数 Linux 发行版都自带 lsof 命令,可以直接按端口号查询:
lsof -i:7890
输出里 COMMAND 列是进程名,PID 列是进程号,例如:
COMMAND PID USER FD TYPE NODE NAME
clash-core 3021 dev 3u IPv4 TCP *:7890 (LISTEN)
确认后用 kill 结束该进程:
kill -9 3021
部分精简版 Linux 系统(比如某些容器镜像或路由器 OpenWrt)可能没有预装 lsof,这种情况下改用 ss 命令,效果相同:
ss -tulnp | grep 7890
ss 的输出会在最后一列直接给出进程名和 PID,格式类似 users:(("clash",pid=3021,fd=3)),同样可以用 kill -9 结束。老版本系统如果连 ss 也没有,可以退回用 netstat -tulnp | grep 7890,原理一致。
在客户端里修改 mixed-port
如果占用 7890 端口的程序不方便关闭,或者这种冲突反复出现,更省心的做法是把 Clash 的监听端口改成别的数字,彻底避开冲突。修改方式因客户端而异,但底层改的都是同一个配置项。
方式一:客户端设置面板直接改
Clash Verge、Clash Nyanpasu、FlClash 等主流客户端都在"设置"或"通用"页面提供端口输入框,找到"混合端口""Mixed Port"或"本地端口"字段,直接改成一个未被占用的数字,推荐范围是 10000 以上的高位端口,例如 17890 或 27890,避开系统常用端口段。保存后客户端会自动重启内核生效。
方式二:直接编辑配置文件
如果客户端没有对应设置项,或者使用命令行方式运行内核,可以在配置文件里手动修改:
mixed-port: 17890
allow-lan: false
mode: rule
log-level: info
如果配置文件里用的是旧式的分离端口写法(port 对应 HTTP、socks-port 对应 SOCKS5),而不是合并后的 mixed-port,同样需要把冲突的那个端口号改掉:
port: 17891
socks-port: 17892
mixed-port 与 port/socks-port 通常只需要保留一种写法,同时存在容易混淆到底哪个端口在生效,建议统一用 mixed-port。改完端口后还要同步检查的地方
端口改完不是保存配置就结束了,还有几个联动的地方容易漏掉,导致代理看起来"开了但没生效":
- 系统代理设置:如果客户端开启了"设置为系统代理"这类开关,系统层面记录的端口号是旧值,需要关闭再重新打开这个开关,让系统代理设置刷新成新端口。
- 浏览器插件:部分浏览器扩展(比如 SwitchyOmega 一类的代理切换插件)会单独保存一份端口配置,和客户端配置是两套独立数据,需要进入插件设置手动改成新端口。
- 命令行工具的代理环境变量:如果习惯用
export https_proxy=http://127.0.0.1:7890这类命令给终端设代理,记得把端口号一起改掉,否则终端里的请求还是指向旧端口,会连接失败。 - 局域网内其他设备:如果有别的设备通过这台电脑的局域网代理上网,对方保存的地址里端口号也需要更新。
常见的端口占用源头
除了 Clash 自身残留进程,7890 端口冲突还经常来自这几类程序,排查时可以优先怀疑:
- 同时装了两个 Clash 系列客户端:比如电脑上同时装了 Clash Verge 和 ClashX Meta,两者默认端口都是 7890,只要有一个先启动,另一个必然冲突。建议只保留一个常驻使用的客户端。
- 命令行直接跑过内核**未正确退出:通过终端手动执行内核程序调试时,如果用
Ctrl+C之外的方式强制关闭终端窗口,内核进程可能变成孤儿进程继续占用端口,需要按前文命令手动找到并结束。 - 其他代理或抓包工具:一些网络调试工具、下载管理器内置的代理模块偶尔会用到 7890 这个常见端口号,和 Clash 冲突的概率不算低。
- 虚拟机或容器端口映射:如果本机跑了虚拟机或 Docker 容器,并把容器内某个服务映射到了宿主机的 7890 端口,同样会造成占用,这种情况下建议改容器的映射端口,而不是改 Clash。
定位到冲突源之后,选择结束占用进程还是修改 Clash 端口,取决于哪个程序更需要固定在默认端口上。对大多数日常使用场景,把 Clash 的 mixed-port 改成一个不常用的高位端口是最省心的一次性方案,改完之后基本不会再遇到同类冲突。