Clash 端口 7890 被占用怎么办：定位冲突进程与修改 mixed-port 的完整步骤

先确认冲突的是哪个监听端口

Clash、Clash Meta（mihomo）及其图形客户端启动时，需要在本机创建一个或多个监听端口。常见报错包括 address already in use、bind: Only one usage of each socket address、listen tcp 127.0.0.1:7890: bind，以及客户端界面里的“端口被占用”。这些信息说明操作系统拒绝了新的监听请求，但不代表配置文件整体损坏。

7890 是 Clash 配置中常见的代理端口，不是强制固定值。使用 mixed-port: 7890 时，同一个端口可以接受 HTTP 和 SOCKS5 代理连接。某些旧配置会分别使用 port: 7890 与 socks-port: 7891。mihomo 配置还可能包含透明代理、DNS 和控制接口所需的其他端口，因此排查前要先读完整错误行。

常见端口与用途

配置项	常见值	用途	冲突后的表现
`mixed-port`	`7890`	HTTP 与 SOCKS5 混合代理	系统代理和手动代理无法连接
`port`	`7890`	HTTP 代理	浏览器 HTTP 代理失效
`socks-port`	`7891`	SOCKS5 代理	使用 SOCKS5 的应用无法连接
`external-controller`	`127.0.0.1:9090`	面板与客户端控制接口	内核可能运行，但面板显示断开
`dns.listen`	`0.0.0.0:1053`	本地 DNS 服务	DNS 模块启动失败或解析异常

在 Windows 定位占用 7890 的进程

先完全退出当前 Clash 客户端，再重新启动一次。若错误仍然出现，说明后台可能保留了另一个内核进程，或者其他代理软件正在使用该端口。不要只关闭窗口：不少客户端的关闭按钮会把程序缩到通知区域，内核仍在后台监听。

方法一：使用 netstat 与 tasklist

以普通权限打开“终端”或“命令提示符”，执行：

netstat -ano | findstr :7890

典型结果如下：

TCP    127.0.0.1:7890    0.0.0.0:0    LISTENING    18432

最后一列 18432 是进程 PID。只有状态为 LISTENING 的记录能够直接说明端口正在被监听。大量 TIME_WAIT 连接通常不等于监听冲突，不要据此结束进程。继续查询 PID 对应的程序：

tasklist /FI "PID eq 18432"

如果结果是 mihomo.exe、clash.exe 或某个客户端附带的内核文件，通常属于残留实例。如果显示为另一款代理工具，应先在那款工具中停止服务或退出程序，再决定是否修改 Clash 端口。

方法二：使用 PowerShell

PowerShell 可以直接读取监听端点和进程名称：

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 18432

若第一条命令提示权限不足，可使用管理员身份打开 Windows 终端后重试。还可以在“任务管理器”→“详细信息”中按 PID 排序，核对进程路径和启动时间。路径位于当前客户端目录、但启动时间明显早于本次操作时，残留内核的可能性较高。

安全停止残留实例

优先通过通知区域菜单选择“退出”，让客户端同步关闭内核、系统代理和服务。界面已经无法操作时，再使用：

taskkill /PID 18432 /T

普通终止失败且确认 PID 无误后，可增加强制参数：

taskkill /PID 18432 /T /F

在 macOS 与 Linux 查询端口占用

macOS 使用 lsof

打开“终端”，查询 TCP 7890 的监听程序：

lsof -nP -iTCP:7890 -sTCP:LISTEN

输出中的 COMMAND 是进程名，PID 是进程编号，NAME 会显示监听地址。若没有输出，检查错误日志是否实际指向 7891、9090 或 1053。也可以去掉监听状态条件，查看与端口相关的全部连接：

lsof -nP -i :7890

确认是残留的 mihomo 或 Clash 内核后，先尝试正常终止：

kill 18432

等待约 2 秒，再次执行 lsof。进程仍存在时，检查是否有图形客户端或后台服务自动将其拉起。直接执行 kill -9 只能终止当前实例，无法解决守护进程反复启动的问题。

Linux 使用 ss 或 lsof

多数现代发行版预装 ss：

sudo ss -ltnp 'sport = :7890'

也可以使用：

sudo lsof -nP -iTCP:7890 -sTCP:LISTEN

如果 mihomo 通过 systemd 运行，不要只杀死内核进程。systemd 会按服务配置重新启动它。先查询服务状态，再停止对应单元：

sudo systemctl status mihomo
sudo systemctl stop mihomo

服务名称可能由安装方式决定，不一定固定为 mihomo。可以执行 systemctl list-units --type=service | grep -Ei 'clash|mihomo' 查找。容器部署还要检查 Docker 的端口映射；宿主机上的 127.0.0.1:7890 可能由容器代理进程持有，而不是由容器内的内核直接显示。

判断该结束进程还是修改 mixed-port

找到占用程序后，不要立即改端口。先判断两个程序是否都需要长期运行。若占用者只是同一客户端上次异常退出留下的内核，结束残留实例并重新启动即可。若两套代理工具需要并行运行，或者 7890 已由本地开发服务固定使用，则应为其中一套程序分配新端口。

适合结束旧进程的情况

占用者与当前客户端使用相同的内核文件和配置目录。
任务管理器或活动监视器中出现两个 mihomo、Clash 内核实例。
旧客户端已卸载，但开机启动项、服务或计划任务仍然存在。
端口释放后只需要运行一个代理客户端。

适合更换端口的情况

7890 被另一个必须持续运行的代理或调试工具占用。
需要同时运行稳定配置与测试配置，两套内核必须隔离。
集中管理环境已经为应用分配了固定端口范围。
当前配置还与其他设备共享，直接停止占用程序会影响现有工作流。

新端口应选择未被监听的本地端口，例如 7893、17890 或 27890。修改前用同一套查询命令检查候选值。端口范围是 1 到 65535；普通桌面配置宜避开 1 到 1023 的常见系统服务端口，也不要与配置中的控制接口、DNS 监听和透明代理端口重复。

修改配置文件中的 mixed-port

直接编辑 YAML 时，找到顶层的 mixed-port。以下配置把混合代理从 7890 改到 7893：

mixed-port: 7893
allow-lan: false
mode: rule
log-level: info

mixed-port 必须位于配置顶层，不能缩进到 proxies、proxy-groups 或 dns 下面。冒号后保留一个空格，端口写成整数。保存后需要让内核完整重载配置；仅切换策略组不会重新创建监听端口。

不要同时保留重复监听

如果配置已经使用混合端口，通常不需要再为 HTTP 和 SOCKS 分别设置同一个数值。下面的写法会让多个监听器争用 7893：

mixed-port: 7893
port: 7893
socks-port: 7893

应当选择一种方案。需要一个入口时只保留：

mixed-port: 7893

确实要分开提供 HTTP 与 SOCKS5 时，则使用不同端口，并移除 mixed-port：

port: 7893
socks-port: 7894

在图形客户端里修改端口

不同客户端的菜单名称存在差异，常见入口是“设置”→“参数设置”→“端口”，或“设置”→“内核设置”→“混合端口”。把 7890 改为已确认空闲的 7893，保存后执行“重启内核”或完整退出并重新打开客户端。

有些界面同时显示 HTTP、SOCKS 和 Mixed 三项。启用 Mixed 后，应以混合端口为主要入口；如果客户端允许关闭单独的 HTTP、SOCKS 监听，可以关闭未使用的入口，减少重复配置。若界面把端口锁定为只读，通常表示数值由当前配置文件或覆写规则控制，需要回到配置管理页面修改。

同步更新系统代理

端口修改后，系统代理仍可能指向旧的 127.0.0.1:7890。这时内核已经正常启动，但浏览器会表现为无法连接。重新关闭并开启客户端的“系统代理”开关，通常会写入新端口。也可以在操作系统中手动核对：

Windows：“设置”→“网络和 Internet”→“代理”，检查地址是否为 127.0.0.1，端口是否为 7893。
macOS：“系统设置”→“网络”→当前网络→“详细信息”→“代理”，检查网页代理与安全网页代理端口。
浏览器扩展、开发工具和命令行程序若单独写了代理地址，也要把 7890 改为 7893。

命令行环境变量同样可能保留旧值。以新的混合端口为例：

http_proxy=http://127.0.0.1:7893
https_proxy=http://127.0.0.1:7893
all_proxy=socks5://127.0.0.1:7893

环境变量的设置语法取决于操作系统和终端。重点是核对所有调用方，而不是只确认客户端界面中的端口数字。

TUN 模式下仍然需要处理监听冲突

TUN 模式通过虚拟网络接口接收系统流量，但这不意味着 mixed-port 可以随意冲突。配置中只要声明了 mixed-port: 7890，内核通常仍会尝试创建该监听器。端口绑定失败可能导致内核启动中止，或者让部分显式代理功能不可用。

如果只依赖 TUN，也可以根据客户端和内核配置移除不需要的显式代理监听；但图形客户端、浏览器扩展和局域网设备可能仍依赖 mixed-port。修改前先检查是否存在手动代理调用。TUN 相关的自动路由、严格路由和 DNS 劫持是另一组配置，不应通过更换 7890 来代替正确的 TUN 设置。

启用 allow-lan: true 时，客户端可能监听 0.0.0.0:7893，让局域网设备访问。只供本机使用时应保持 allow-lan: false，或将监听地址限制在回环接口。无论是否允许局域网访问，同一地址族上的端口都必须保持唯一。

验证新端口是否真正生效

第一步：确认监听状态

重启内核后，再次查询新端口。Windows 使用：

netstat -ano | findstr :7893

macOS 使用：

lsof -nP -iTCP:7893 -sTCP:LISTEN

Linux 使用：

ss -ltnp 'sport = :7893'

预期结果是 mihomo 或 Clash 内核处于 LISTEN 状态，同时旧端口 7890 不再由该实例占用。

第二步：直接测试代理入口

安装了 curl 时，可以绕过系统代理设置，直接指定新端口：

curl -I -x http://127.0.0.1:7893 https://example.com

返回 HTTP 响应头说明本地代理入口能够接收请求。若提示 Connection refused，说明新端口没有监听或地址写错；若已经连接但请求超时，应继续检查节点可用性、策略组选择、DNS 和规则，而不是继续修改端口。

第三步：检查客户端日志

在“日志”页面筛选 error、listen、bind 等关键词。正常启动后不应再出现 7890 或 7893 的绑定错误。若错误改为 127.0.0.1:9090，说明 mixed-port 已修复，但控制接口仍与其他实例冲突，需要用同样方法检查 external-controller。

反复出现 7890 冲突时的检查清单

关闭客户端窗口后，检查通知区域、菜单栏和任务管理器中是否仍有内核进程。
检查是否同时安装了两款 Clash 或 mihomo 图形客户端，并且都设置为开机启动。
Windows 检查“任务管理器”→“启动应用”和服务列表；Linux 检查 systemd；macOS 检查登录项与后台项目。
确认订阅更新后，运行配置中的 mixed-port 没有从 7893 恢复为 7890。
确认系统代理、浏览器扩展、终端环境变量和局域网设备使用的是当前端口。
检查 9090、1053、7891 等其他监听端口，避免修复一个端口后又被下一处冲突阻断。
保留一个明确的端口规划，例如 mixed 使用 7893、控制接口使用 9093、DNS 使用 1053，避免多个实例复用。

端口占用问题的处理顺序应保持固定：先从日志读取准确端口，再用系统工具定位 PID，判断占用者是否需要保留，最后决定结束残留进程或修改配置。修改 mixed-port 后，还要同步系统代理和所有手动代理调用方。只改 YAML 而不更新调用端口，会把“启动失败”变成“内核正常但应用无法联网”，增加后续排查成本。