连接排障 · Clash 技术博客

Clash Verge Rev 端口被占用怎么修？

Clash Verge Rev 报 address already in use 或 mixed-port 启动失败时，先查监听者，再区分残留内核、其他程序或保留端口；给出检查、修复、回退与验证步骤。

阅读正文返回博客
  • Clash Verge Rev
  • address already in use
  • mixed-port
  • 端口占用
  • 服务模式
本文目录
文章作者
Clash官网
发布日期
预计阅读
约 10 分钟

先确认日志是不是端口绑定冲突

本文只处理日志明确出现 address already in use、Bind failed 或 Start Mixed(http+socks) server error 的情况。问题报告中的 7890 和 1053 只是实例，排查时必须使用自己日志中的 mixed-port、DNS 或 external-controller 端口。

Mihomo 文档说明，mixed-port 是同时接受 HTTP(S) 与 SOCKS 请求的本地入口。新内核无法绑定它时，系统代理即使仍指向这个端口，也不会得到可用的新连接。

Clash Verge Rev issue #7861 记录了 macOS 服务模式下 GUI 异常结束后，root 用户运行的 verge-mihomo 继续占用 mixed-port 与 DNS 端口。Issue #6741 则记录了 Linux 重新登录时新旧内核争用 mixed-port。

两项目前仍是 open issue，根因分析来自报告者，不能写成维护者已经确认的普遍结论。

先从第一条 bind 错误记下实际端口
Start Mixed(http+socks) server error: listen tcp :7890: bind: address already in use
Start DNS server(TCP) error: listen tcp 0.0.0.0:1053: bind: address already in use
Start DNS server(UDP) error: listen udp 0.0.0.0:1053: bind: address already in use

按第一条错误分流

日志或现象更可能的方向下一步
只有 mixed-port 报 address already in use旧客户端、其他程序、残留内核或 Windows 保留端口查实际监听者
mixed-port 与 DNS 端口同时失败另一份内核同时持有整组端口的可能性较高查进程属主与启动时间
只有 external-controller 端口冲突控制接口或 Dashboard 使用相同端口单独检查控制端口
日志只有 connection refused，没有 bind 错误目标端口未监听，不是端口已被占用排查内核启动与配置
只有一个网站打不开规则、DNS 或节点问题不要按本文结束进程

检查前先让系统能够直连

先关闭 TUN 和系统代理，确认设备不依赖 Clash Verge Rev 也能联网，再从托盘完整退出客户端。保存当前 Profile、端口设置和故障日志，不要在定位过程中同步订阅或改规则。

退出后等待几秒并重新检查端口。若监听已经消失，先只启动一次客户端观察；只有端口仍被占用，才继续查占用者。

开始排查前

  1. 记录实际端口

    从第一条 bind 错误记下 mixed-port、DNS 或 external-controller 的具体端口。

  2. 恢复基础网络

    关闭 TUN 与系统代理，确认客户端停止时设备仍能直连。

  3. 正常退出客户端

    先从托盘完整退出，等待几秒，不要直接强制结束进程。

  4. 保存配置与日志

    保留当前 Profile、端口值和第一条错误，公开反馈前隐藏订阅 URL、密码与 secret。

按系统查清是谁在监听

端口占用不是进程名称猜谜。先找到 PID，再核对进程名、属主、启动时间和程序路径，才能区分正在工作的当前内核、退出后残留的旧内核与无关程序。

下面的 7890、1053 和 12345 都是示例。执行前替换为日志中的端口和刚查到的 PID；只读查询没有结果时，不要为了得到结果而随意结束进程。

Windows PowerShell：查询 TCP 与 UDP 监听者
$Port = 7890
$Tcp = Get-NetTCPConnection -LocalPort $Port -State Listen -ErrorAction SilentlyContinue
$Tcp | Select-Object LocalAddress, LocalPort, OwningProcess
$Tcp | ForEach-Object {
  Get-Process -Id $_.OwningProcess | Select-Object Id, ProcessName, Path
}
Get-NetUDPEndpoint -LocalPort 1053 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess
macOS：查询监听者并核对进程
PORT=7890
sudo lsof -nP -iTCP:${PORT} -sTCP:LISTEN
sudo lsof -nP -iUDP:1053
ps -o user,pid,ppid,lstart,command -p 12345
Linux：查询监听者并核对进程
sudo ss -ltnp 'sport = :7890'
sudo ss -lunp 'sport = :1053'
ps -o user,pid,ppid,lstart,cmd -p 12345

根据监听者选择最小修复

端口属于另一款 Clash、VPN、开发服务器或本地代理

从该程序自己的界面正常退出，或让两款程序使用不同端口；不要结束未知系统进程。

Clash Verge Rev 已退出，端口仍属于 verge-mihomo

这才符合残留内核特征。保存 PID 与属主后，只向这一 PID 发送正常终止请求。

进程属于 root 或管理员，结束后马上再次出现

不要反复强杀，转到客户端的服务模式修复或重装流程。

重新登录或快速重启客户端后偶发冲突

可能是新旧内核交接竞态；先关闭重复自启动入口，并只启动一次客户端验证。

Windows 查不到监听者但仍无法绑定

检查端口是否落入 Windows excluded port range。

只有确认 PID 是客户端退出后残留的 verge-mihomo，才执行单进程终止。先使用正常终止并再次查询端口；不要从宽泛的 pkill 或强制信号开始。

macOS / Linux：仅终止刚确认的单一 PID
# 把 12345 换成刚才确认的 PID
sudo kill -TERM 12345
Windows PowerShell：确认后终止单一 PID
# 把 12345 换成刚才确认的 PID
Stop-Process -Id 12345 -Confirm

Windows 没有监听者时检查保留端口

Issue #6947 的 Windows 记录中，更换端口并重启系统代理后恢复使用；项目协作者同时建议先看 Mihomo 日志中的 Bind failed，并检查 Windows 或 Hyper-V 的保留端口。这个分支只适用于没有查到监听进程、但日志仍明确绑定失败的情况。

如果当前 mixed-port 落在保留范围内，在 Clash Verge Rev 的端口设置中选择一个没有监听、也不在保留范围内的新端口，再返回首页重新启用系统代理。只改端口而不核对占用者，不能处理仍在运行的残留内核。

只读查看 Windows TCP 与 UDP 保留端口
netsh interface ipv4 show excludedportrange protocol=tcp
netsh interface ipv4 show excludedportrange protocol=udp
netsh interface ipv6 show excludedportrange protocol=tcp
netsh interface ipv6 show excludedportrange protocol=udp
用候选端口前先确认没有监听者
# 17890 只是示例，不能保证每台电脑都可用
Get-NetTCPConnection -LocalPort 17890 -ErrorAction SilentlyContinue
Get-NetUDPEndpoint -LocalPort 17890 -ErrorAction SilentlyContinue

残留内核反复出现时修复服务模式

Clash Verge Rev v2.5.2 源码提供服务安装、卸载、重装和 repair 命令；repair 路径会执行强制重装并等待服务 IPC 恢复。不同系统和构建的按钮名称可能不同，应使用当前客户端设置中的服务模式入口，不要手动删除服务文件。

v2.5.2 发布说明提到更健壮的服务生命周期管理，但这不能证明后续报告的残留内核和端口竞态已被稳定版彻底修复。本文提供的是故障恢复路径，不是版本修复公告。

服务模式恢复顺序

  1. 保持直连

    关闭系统代理与 TUN，确认客户端停止时系统仍可联网。

  2. 保存诊断结果

    记录端口、PID、进程属主、客户端版本和第一条 bind 错误。

  3. 使用客户端入口

    从服务模式设置中卸载、修复或重新安装服务，并等待权限提示与操作完成。

  4. 必要时重启系统

    若管理员内核仍持有端口，重启后先确认端口已释放，再启动客户端。

  5. 只恢复一项功能

    先启动原 Profile 和系统代理；确认正常后，再按需要恢复 TUN。

修复后验证端口、代理与退出释放

先确认启动前目标端口为空，再启动 Clash Verge Rev，检查只有一份预期内核监听。随后把示例端口替换为当前 mixed-port，通过本地代理发起一次真实 HTTPS 请求，并在 Connections 中核对记录。

只有系统代理路径验证通过后再开启 TUN。若一开 TUN 才断网且日志没有绑定错误，应转到 TUN、DNS 和路由排查，不要继续更换 mixed-port。

通过当前 mixed-port 验证真实请求
# 把 7890 换成当前 mixed-port
curl -I -x http://127.0.0.1:7890 https://example.com

完成标准

  • 启动前目标端口没有未知监听者
  • 启动后 mixed-port 只由一份预期的 verge-mihomo 监听
  • 新日志不再出现 address already in use 或 Bind failed
  • 通过 mixed-port 的 curl 请求能收到 HTTP 响应
  • 系统代理指向当前实际端口，Connections 能看到测试请求
  • 正常退出客户端后端口释放，系统代理也能恢复
  • 再次启动或重新登录后没有出现第二份残留内核

失败时回退并提交有效证据

更换端口或重装服务后若问题更严重，先关闭系统代理和 TUN，让设备保持直连。只有旧端口已经释放时才恢复原端口；服务重装失败时先保持服务模式关闭，不要继续手动删除系统文件。

向官方反馈时，把本机结论写成观察结果，而不是替维护者宣布根因。不要上传完整配置、订阅 URL、节点密码、控制器 secret 或未脱敏日志。

提交官方 issue 前保留

  • Clash Verge Rev 完整版本与安装来源
  • 操作系统版本和 CPU 架构
  • 是否启用服务模式、TUN 和开机自启
  • GUI 是正常退出、崩溃还是被强制结束
  • 第一条 address already in use 日志及实际端口
  • 监听者的 PID、属主、启动时间和程序路径
  • 退出客户端后端口是否释放，修复服务后是否复现

参考资料