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
注意:结束进程前先确认 PID 对应的程序不是系统服务或正在使用中的其他工具,误杀会导致相关程序的数据未保存就退出。

如果占用进程就是 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-portport/socks-port 通常只需要保留一种写法,同时存在容易混淆到底哪个端口在生效,建议统一用 mixed-port

改完端口后还要同步检查的地方

端口改完不是保存配置就结束了,还有几个联动的地方容易漏掉,导致代理看起来"开了但没生效":

  • 系统代理设置:如果客户端开启了"设置为系统代理"这类开关,系统层面记录的端口号是旧值,需要关闭再重新打开这个开关,让系统代理设置刷新成新端口。
  • 浏览器插件:部分浏览器扩展(比如 SwitchyOmega 一类的代理切换插件)会单独保存一份端口配置,和客户端配置是两套独立数据,需要进入插件设置手动改成新端口。
  • 命令行工具的代理环境变量:如果习惯用 export https_proxy=http://127.0.0.1:7890 这类命令给终端设代理,记得把端口号一起改掉,否则终端里的请求还是指向旧端口,会连接失败。
  • 局域网内其他设备:如果有别的设备通过这台电脑的局域网代理上网,对方保存的地址里端口号也需要更新。

常见的端口占用源头

除了 Clash 自身残留进程,7890 端口冲突还经常来自这几类程序,排查时可以优先怀疑:

  1. 同时装了两个 Clash 系列客户端:比如电脑上同时装了 Clash Verge 和 ClashX Meta,两者默认端口都是 7890,只要有一个先启动,另一个必然冲突。建议只保留一个常驻使用的客户端。
  2. 命令行直接跑过内核**未正确退出:通过终端手动执行内核程序调试时,如果用 Ctrl+C 之外的方式强制关闭终端窗口,内核进程可能变成孤儿进程继续占用端口,需要按前文命令手动找到并结束。
  3. 其他代理或抓包工具:一些网络调试工具、下载管理器内置的代理模块偶尔会用到 7890 这个常见端口号,和 Clash 冲突的概率不算低。
  4. 虚拟机或容器端口映射:如果本机跑了虚拟机或 Docker 容器,并把容器内某个服务映射到了宿主机的 7890 端口,同样会造成占用,这种情况下建议改容器的映射端口,而不是改 Clash。

定位到冲突源之后,选择结束占用进程还是修改 Clash 端口,取决于哪个程序更需要固定在默认端口上。对大多数日常使用场景,把 Clash 的 mixed-port 改成一个不常用的高位端口是最省心的一次性方案,改完之后基本不会再遇到同类冲突。

获取全平台 Clash 客户端

Windows、macOS、Android、iOS、Linux 安装包与配置说明。

下载客户端