故障排查

Clash 提示代理端口被占用？先找到监听进程

mixed-port 启动失败或提示 address already in use，说明本机已有程序占用该地址端口。本文说明如何确认进程，而不是盲目换一串端口。

发布于 2026/8/8 · 更新于 2026/8/8 · 4 项可核验来源

先看重点先完全退出其他代理客户端并重启当前内核；仍冲突时，用 netstat 或 Get-NetTCPConnection 找到监听端口的 PID，确认进程身份。只有端口确被合法程序使用，才把 Clash 改到一个明确空闲的端口。

Clash 启动时报 address already in use、端口占用，含义很直接：当前地址和端口已经有监听者。它可能是另一款代理、旧客户端后台服务，也可能是你确实需要的开发程序。

不要先把端口从 7890 改成 7891、7892 一路试。 端口变化还会让 Windows 系统代理、浏览器扩展和命令行环境变量继续指向旧地址，最后产生“客户端运行了但所有程序都连错端口”的第二个问题。

先排除重复运行

检查任务栏托盘和任务管理器，完全退出旧版 Clash、v2rayN、抓包代理、开发服务器与重复启动的当前客户端。关窗口不一定退出托盘进程，服务模式也可能继续运行。

然后只启动一款客户端，重启内核。若冲突消失，不需要修改端口；问题是两个实例同时运行。

在 Windows 找到端口对应的 PID

把下面的 7897 换成客户端报错的实际端口：

netstat -ano | findstr :7897

或在 PowerShell 使用：

Get-NetTCPConnection -LocalPort 7897 -ErrorAction SilentlyContinue

找到 Listen/LISTENING 对应的 OwningProcess 或 PID，再到任务管理器“详细信息”核对进程。Microsoft 的端口排障文档也把 netstat 和 Get-NetTCPConnection 作为定位端口与进程的工具。

不要看到 PID 就强制结束。先确认它是谁、是否保存了工作、是否由系统或单位策略管理。未知系统服务应先查清，不要用管理员脚本批量杀进程。

TCP 空闲不代表所有协议都空闲

有些监听会使用 UDP，TUN 或透明代理还可能涉及多个端口。TCP 查询无结果但客户端仍报冲突时，再查：

Get-NetUDPEndpoint -LocalPort 7897 -ErrorAction SilentlyContinue

同时核对错误文本里是 mixed-port、controller、DNS 端口还是其他监听。不同字段不能都靠改 mixed-port 解决。

确实要改端口时，一次同步完成

选择客户端允许的空闲高位端口并保存，随后同步检查：

Windows 手动系统代理；
浏览器代理扩展；
http_proxy、HTTPS_PROXY、ALL_PROXY；
Git、npm、Docker 等工具自己的代理；
局域网设备上手写的主机与端口。

Clash Verge Rev 较新的发布记录提到代理端口冲突自动回退，但不能假设每个版本、每种监听都已自动处理。界面显示的最终运行端口和系统实际监听应一致。

什么时候不是端口占用

connection refused 表示当下端口没有接受连接，可能是内核没启动；timeout 表示请求未及时完成；权限错误则可能来自服务或防火墙。这些错误不能都用换端口处理。

修复后做两个验证：端口只有预期进程监听；使用实际端口执行一次显式代理请求成功。然后重启客户端再测，避免只是旧进程暂时退出、下次开机又抢回来。

端口已经正常监听、浏览器能用但终端仍失败时，转去检查Git 与命令行自己的代理配置，不要继续更换端口。

监听地址也会影响“是否冲突”

127.0.0.1:7897、0.0.0.0:7897 和某个局域网地址使用同一端口时，监听范围可能重叠。一个程序绑定所有接口后，另一个即使只想绑定本机，也可能失败。

查看 netstat 输出时同时看 Local Address，不要只看端口数字。只需本机使用时，避免为了方便绑定所有地址；需要 Allow LAN 时，再按可信网卡和来源范围设计。

控制端口和代理端口不要混为一谈

Mihomo 可能同时有 mixed-port、HTTP/SOCKS 端口、DNS 监听和 external-controller。控制端口用于 API 或界面通信，不是给浏览器填写的代理地址。

错误信息指向 9090 一类 controller 时，应查对应字段和占用进程；只修改 mixed-port 不会释放它。反过来，把浏览器指向 controller 也不会得到正常代理连接。

端口自动回退后要看最终运行值

新版客户端可能检测冲突后选择其他可用端口。此时设置文件里的初始值、界面最终值与 Windows 系统代理必须一致。最简单的证据仍是系统监听和一次显式 curl --proxy。

如果每次启动随机变化，查清是谁先占用原端口。让所有工具追着动态端口改配置，不如解决重复启动或给两个合法程序各自固定不冲突的端口。

自启动是常见复发来源

旧客户端可能已从应用列表卸载，服务或计划任务仍在开机启动。冲突只在重启后出现、手动结束进程后消失时，检查该进程的文件路径和启动项。

删除服务或文件属于有风险操作；先确认它确属已废弃客户端，并使用项目官方卸载方式。不要根据进程名相似就删除系统服务。

最终记录哪一个进程、哪个地址和哪个协议占用了端口。下次复发时能直接验证，而不用再次从换端口猜起。

资料来源

以下来源于 2026/8/8 复核。版本、支持平台和发布状态以后续官方页面为准。

持续更新

收到新教程，也欢迎纠错

想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。

关注 TG 频道 Telegram 纠错邮件纠错

读者互动

这篇内容对你有帮助吗？

— 次访问— 累计日独立访问— 条评论

直接说出你的问题