TrustedAccessPath - 全球网络加速服务

Mihomo 代理端口被占用怎么解决？

更新于 2026-11-10 · tapcloud.shop

简答：看到“bind: address already in use”时，先从日志确认被占用的 IP 和端口，再用系统命令查出 PID。确认是重复启动或无关程序后，优先停止多余进程；不能停止时再修改当前生效配置中的 mixed-port 或对应监听端口，重启 Mihomo 后用监听命令和代理请求复测。

定义：Mihomo 代理端口被占用，是指 Mihomo 试图监听某个本地 IP:端口时，该监听地址已经被另一个进程或同一配置中的其他监听项使用。

先做这一步：确认到底是哪一个端口冲突

不要看到 7890、7891 或 9090 就直接改配置。先打开 Mihomo 或图形客户端的内核日志，找到包含 bind: address already in use、listen tcp、listen udp 或 External controller listen error 的完整行，记录协议、监听地址和端口，例如 127.0.0.1:7890 或 127.0.0.1:9090。

Mihomo 文档将代理入口分为 HTTP、SOCKS、Mixed、透明代理和 Listeners；port、socks-port、mixed-port、redir-port、tproxy-port 并不是同一个字段。官方入站配置说明还指出，Listeners 可以创建多个不同类型和端口的入口，因此配置里也可能是两个监听项重复使用了同一地址和端口。

日志中出现的字段或服务含义排查重点
mixed-port同一端口同时支持 HTTP(S) 和 SOCKS5查是否有旧的 Mihomo、其他代理客户端或第二个内核正在监听
portHTTP(S) 代理端口不要只改 mixed-port 后忽略仍启用的 HTTP 端口
socks-portSOCKS4、SOCKS4a、SOCKS5 代理端口检查系统或应用是否仍指向旧的 SOCKS 端口
external-controller控制接口监听地址和端口它不是给浏览器使用的代理端口，不能当作代理端口填写
DNS listenDNS 服务监听端口注意日志可能是 UDP 冲突，而不是 TCP 代理冲突

成功判据：你已经得到完整的监听地址、端口和协议，而不是只知道“端口被占用”。

Windows：用 netstat 查 PID，再决定结束进程还是改端口

  1. 打开“终端”或“命令提示符”。假设日志显示冲突端口为 7890，执行：
    netstat -ano | findstr :7890
    Microsoft 的 netstat 文档说明，-o 会显示连接对应的进程 ID；输出末列通常就是 PID。
  2. 记下占用该端口的 PID。可以进一步执行：
    tasklist /FI "PID eq 1234"
    把 1234 换成实际 PID，确认它属于 Mihomo、图形客户端、其他代理内核，还是你正在使用的其他软件。
  3. 如果确认是重复启动的旧进程，先正常退出对应客户端；只有在进程无法正常退出时，再执行：
    taskkill /PID 1234 /T
    如仍无法结束，可在确认 PID 无误后使用 /F 强制结束。Microsoft taskkill 文档说明，该命令可按 PID 或映像名结束进程，/T 会同时处理子进程。
  4. 重新启动 Mihomo，并再次执行 netstat -ano | findstr :7890。如果监听者已经变成新启动的 Mihomo PID，说明端口冲突已解除。

如果 PID 属于正在使用的程序，不要直接结束它。转到下一节修改 Mihomo 当前生效配置；结束错误进程可能导致其他应用退出或未保存的数据丢失。

macOS 和 Linux：用 lsof 或 ss 定位监听进程

在 macOS 或 Linux 终端中，先按日志里的端口查询。lsof 可以列出打开网络套接字的进程，lsof 手册提供了按网络地址筛选的用法。

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

如果冲突是 UDP，例如 DNS 监听，可以改用：

sudo lsof -nP -iUDP:5335

Linux 也可以使用 ss：

sudo ss -ltnp | grep ':7890'
sudo ss -lunp | grep ':5335'

ss 手册说明，-l 显示监听套接字，-t 和 -u 分别筛选 TCP、UDP，-p 用于显示关联进程信息。

  1. 查看输出中的进程名和 PID，确认是否为第二个 Mihomo、旧客户端或其他服务。
  2. 先在对应客户端中正常退出；命令行进程可先尝试发送普通终止信号：
    kill 1234
  3. 再次运行 lsof 或 ss 验证端口是否释放。只有进程确认无法退出时，才考虑使用更强制的终止方式。

macOS 与 Linux 的客户端封装方式不同，配置文件位置也可能不同。本文不假定某个固定路径；应从当前客户端的配置页面、启动参数或日志中确认正在使用的配置文件。

结束进程后仍冲突：检查重复配置和第二个内核

如果你已经停止了一个占用进程，但启动后仍然报同一个端口冲突，按下面顺序检查：

  1. 是否启动了两个 Mihomo 实例：同时检查图形客户端、命令行窗口、系统服务、容器或开机启动项。一个实例退出后，另一个实例可能仍在占用端口。
  2. 是否混淆了端口字段：例如只修改了 mixed-port，但日志实际报错的是 external-controller 或 DNS listen。
  3. 是否有两个 Listeners 使用同一端口：查看 listeners 下每个入口的监听地址和端口，不要让多个入口绑定同一个 IP:端口。
  4. 是否编辑了错误配置：订阅配置、覆写配置、Mixin、临时运行配置和本地配置可能不是同一个文件。以启动日志显示的配置来源或客户端当前配置页面为准。
  5. 是否修改后没有重载：仅保存文件不一定会改变正在运行的内核。根据客户端提供的功能执行重载，或者完全退出并重新启动内核。

Mihomo 官方端口说明明确区分了 HTTP、SOCKS 和 Mixed 端口。排查时应先对应日志中的字段，再修改同名字段，避免为了处理一个控制端口冲突而误改代理入口。

无法释放端口时：修改 mixed-port，并同步所有使用入口

如果占用端口的程序不能停止，或者你确实需要同时运行多个本地代理内核，可以修改 Mihomo 配置。对于只需要一个统一代理入口的场景，mixed-port 可同时承载 HTTP(S) 和 SOCKS5，具体端口以当前配置和客户端界面为准。

示例：

mixed-port: 17890

如果原配置同时启用了以下字段，也要分别确认它们是否冲突：

port: 17891
socks-port: 17892
external-controller: 127.0.0.1:19090

不要为了“让局域网设备能用”而顺手把 allow-lan 打开，或把监听地址扩大到 0.0.0.0。端口冲突本身不要求扩大监听范围；如果确实需要局域网访问，应单独评估监听地址、防火墙和访问控制。

改完后同步检查：

  • 客户端的系统代理设置是否仍指向旧端口；
  • 浏览器扩展或单独应用是否配置了旧端口；
  • 终端环境变量 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 是否仍指向旧端口；
  • 脚本、开发工具或容器配置是否写死了旧端口；
  • 如果使用 TUN，先确认内核已经正常启动，再判断是否还有 DNS、路由或权限问题。

若修改后仍报旧端口，优先回到“当前生效配置”检查，而不是继续换端口。常见原因是修改了未被加载的文件、订阅更新覆盖了本地改动，或实际冲突字段并不是 mixed-port。

改端口后的验收、回滚与最小验证

  1. 验证监听：Windows 使用 netstat -ano，macOS 使用 lsof，Linux 使用 ss，确认新端口由 Mihomo 进程监听。
  2. 验证代理入口：如果使用 Mixed 端口，可用支持 HTTP 代理的 curl 测试：
    curl -x http://127.0.0.1:17890 https://example.com
    curl 官方手册说明，-x 或 --proxy 用于指定代理；把示例端口替换为你的实际端口。
  3. 验证应用设置：打开一个需要代理的应用或浏览器，确认它使用的是新端口，而不是旧端口。若监听正常但应用仍无法访问，问题已经从“端口占用”转为系统代理、规则、DNS 或节点连接问题。
  4. 验证控制接口：不要把 external-controller 当作浏览器代理端口。Mihomo 的 API 文档将运行配置和控制接口单独列出；如需使用控制面板，应按当前控制器地址和认证设置连接。
  5. 回滚：保留修改前的配置副本，记录原端口。若新端口导致应用无法连接，先停止 Mihomo，恢复原配置，再确认原端口确实已释放，最后重新启动。

完成标准：日志不再出现对应的 bind 错误；新端口只有预期的 Mihomo 实例监听；应用指向新端口；代理请求能够返回结果。若只满足前两项，说明端口问题已解决，但代理链路未必已经正常。

什么时候不要继续改端口

如果日志报的是配置解析错误、权限错误、证书错误、DNS 解析失败或 TUN 网卡问题，盲目修改端口通常无效。尤其是端口已经由 Mihomo 正常监听，但浏览器仍打不开网页时，应转向检查系统代理是否开启、规则模式是否正确、DNS 是否可用以及节点连接状态。

如果日志同时出现多个监听错误，应逐项处理：先处理代理入口，再处理控制接口，最后处理 DNS 或透明代理端口。每次只改一组字段并重启验证，便于判断是哪一步产生变化。

常见问题

Mihomo 报 address already in use 是什么意思？

它表示 Mihomo 要监听的本地 IP 和端口已经被其他进程或另一个监听项使用。先从完整日志确认是 TCP 还是 UDP、具体端口和字段，再查询占用进程。

只改 mixed-port 就能解决所有端口冲突吗？

不能。如果日志冲突的是 port、socks-port、external-controller、DNS listen、redir-port、tproxy-port 或 listeners，就应处理对应字段。mixed-port 只代表 HTTP(S) 与 SOCKS 混合代理入口。

Windows 查到 PID 后可以直接 taskkill 吗？

先确认 PID 对应的程序。若是重复启动的 Mihomo，可以先正常退出；确认无误且无法退出时再使用 taskkill。不要结束正在运行的其他软件或系统进程。

修改端口后为什么仍然提示旧端口被占用？

常见原因包括编辑了未生效的配置、没有重载或重启内核、订阅更新覆盖本地修改、同时运行了第二个实例，或者实际报错字段不是 mixed-port。应以启动日志和当前生效配置为准。

端口已经监听，但系统代理还是打不开网页怎么办？

这说明端口占用问题可能已经解决。继续检查系统代理是否指向新端口、浏览器或应用是否使用旧端口，再单独检查 DNS、规则、TUN 权限和节点连接。

相关阅读

参考资料

  1. Mihomo 官方文档：入站配置
  2. Mihomo 官方文档：代理端口
  3. Mihomo 官方文档：API 与运行配置
  4. Microsoft Learn：netstat 命令
  5. Microsoft Learn：taskkill 命令
  6. Linux man-pages：lsof（man7.org）
  7. Linux man-pages：ss（man7.org）
  8. curl 官方手册：--proxy（curl.se）