连接排障 · 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：哪个实际端口无法绑定？

先保留日志中的 address already in use、Bind failed 或 Start Mixed(http+socks) server error，并记下它们指向的本地端口。出现这些错误时，新程序没有完成端口绑定。

端口是程序接收请求的入口编号；使用自己日志中的 mixed-port、DNS 或 external-controller 数值，报告里的 7890 和 1053 只是示例。

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、端口设置和首条故障日志，期间不更新订阅或改规则；公开反馈前隐藏订阅 URL、密码与 secret。

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

根据 PID、运行账户和路径确认占用端口的程序

不能只凭进程名称判断谁占用了端口。先找到 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，才终止该进程并复查端口。macOS/Linux 先发送 TERM；Windows 的 Stop-Process 会直接终止，-Confirm 只增加确认提示。不要使用宽泛的 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. 使用客户端入口

    可从当前客户端的服务模式设置中停用或卸载旧服务。Windows 上只有确认所用服务组件符合官方安全公告的修复要求，才可修复、重装或启用；未确认时保持停用。其他系统沿用客户端的卸载、修复或重装入口，等待权限提示与操作完成。

  4. 必要时重启系统

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

  5. 只恢复一项功能

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

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

通过当前 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 能看到测试请求
  • 正常退出客户端后端口释放，系统代理也能恢复
  • 再次启动或重新登录后没有出现第二份残留内核

系统代理的真实 HTTPS 请求通过后才按需启用 TUN。若只在 TUN 开启后断网、日志又没有绑定错误，转查 DNS 与路由，不继续换 mixed-port。

改端口或重装服务无效时，恢复直连并保留证据

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

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

提交官方 issue 前保留

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

参考资料