机场客户端提示端口被占用怎么办？Windows 本地监听排查

机场客户端启动时提示端口被占用，先核对报错里的本地地址、端口和占用进程，再决定正常退出重复程序还是更换入口。此类问题发生在本机监听阶段，刷新机场订阅、切换远端节点，通常不是对应的处理步骤。

本文面向 Windows 用户，以 HTTP、SOCKS 或混合代理入口为例。示例命令只读取状态，端口和进程编号都需要换成自己核对过的值。

作者：小六｜资料核对日期：2026年10月6日

先确认被占用的是哪个端口

客户端可能同时有代理入口和控制接口。报错涉及哪一个，就检查哪一个，不要把远端节点端口、本地代理端口和面板端口混在一起。

Mihomo 文档分别说明 HTTP、SOCKS 与混合端口，其中混合入口支持 HTTP 和 SOCKS 代理连接。见官方代理端口说明。

先保留错误原文，记录类似“监听地址加端口”的信息。例如，报错中的 127.0.0.1:7890 指向本机入口，7890 只是这里的演示数字，不是所有客户端必须使用的端口。

再查看客户端是否已经在托盘运行，是否同时启动了两个实例，或是否有另一个网络工具正在提供同一入口。关闭窗口不一定等于退出程序。

第一步：查本地监听记录

可以在 PowerShell 或命令提示符中使用：

netstat -ano

微软说明，-a 展示连接和监听端口，-n 用数字显示地址，-o 附带进程 ID，也就是 PID。见 netstat 官方说明。

重点看报错端口对应的本地地址，并结合协议和状态。不要仅用一个数字在整段输出里搜索，远端地址也可能出现同样端口。

TCP 监听项与已经建立的连接、正在关闭的连接，含义不同。UDP 项的呈现方式也不同，不能要求它一定具有与 TCP 相同的监听状态文字。

还要同时记下地址范围：本机回环地址、全部接口地址或 IPv6 地址，都可能出现在输出里。只看到一行名称相似的连接，还不足以确认它与这次报错对应。

第二步：把 PID 对应到程序

假设已经确认相关监听项的 PID 是 1234，可以继续查询：

tasklist /fi "PID eq 1234"

1234 是占位示例，不代表这台电脑上实际存在的进程。微软的 tasklist 文档支持按 PID 筛选；也可以在任务管理器的详细信息中核对。

查询结果能帮助识别程序，但不自动授权结束它。若属于自己重复启动的客户端，优先使用程序的正常退出方式，再重新检查监听记录。

如果是其他应用或后台服务，先确认用途。不要根据一段网上命令批量结束进程，也不要只凭进程名称就认定它是可以删除的残留文件。

找到占用后，退出程序还是改端口？

已确认的情况	可考虑的处理
同一客户端启动了两个实例	正常退出多余实例，保留一个入口
两个程序都确实需要运行	通过各自支持的设置分配不同入口
占用者是自己不再使用的程序	保存任务后正常退出，再复查
占用者或报错含义不清楚	先查程序说明与错误，不贸然终止

如果改的是本地代理入口，还要同步核对使用它的系统设置和应用配置。内核已经监听新端口，浏览器却仍连接旧端口，也会造成无法使用。

关于应用自己的入口配置，可参考本站的curl 命令行代理排查。修改前记下原值，避免测试结束后留下两套不一致的设置。

没查到监听项，为什么仍可能报错？

查询是某一时刻的状态。另一个进程可能刚退出，客户端也可能在不断重试，所以要把查询时间与错误时间对应起来。

此外，绑定失败不都等于“普通程序占用了端口”。Windows 的错误文档区分地址已使用、权限拒绝和地址不可用等情况。见微软套接字错误说明。

例如，10048 对应地址已使用，10013 对应权限拒绝。仍需结合完整信息定位，不能在没有监听项时就关闭防火墙或反复提升权限。

也不要先修改远端节点的端口。它描述另一端的连接参数，不能替代修复本地入口的绑定问题。

最后确认：启动成功还不够

完成调整后，确认客户端正常启动、本地入口与应用设置一致，再发起一个新的常用请求，观察是否进入预期客户端和节点。

如果程序退出后才断网，应转到本站的Windows 代理残留排查，不要把退出后的入口不可用与启动时的端口占用当成同一个问题。

想交流端口冲突，可以提供客户端版本、错误原文和脱敏后的本地监听项，不需要贴出全部网络连接记录：Telegram 联系我