从最早发生的错误开始

Mihomo启动失败时，先确认可执行文件是否真正运行。系统提示格式错误或无法执行，通常应核对系统、架构、权限及文件完整性；此时还没必要排查远端节点。若已经出现配置解析信息，再关注文件路径与内容。检查顺序可以减少一次改动过多造成的混乱。

保留从启动开始到退出的日志，注明发生时间、程序路径与启动方式。手动进程和服务的日志位置可能不同：前台看终端输出，systemd环境则结合服务状态与journal。若由服务管理器启动，可先阅读Linux服务状态与日志检查，确认查询的是正确单元。

进程存在，只是一个中间事实

排查Mihomo进程时，Windows可在任务管理器中查看进程路径，也可在PowerShell查询已知名称；Linux可结合进程列表与服务主进程。下面的名称是示例，重命名后的程序需要按实际情况调整。不要因为看见两个相似名称就立即强制结束，先确认它们属于哪个客户端或服务。

# Windows PowerShell：仅查询匹配的进程
Get-Process -Name mihomo -ErrorAction SilentlyContinue

# Linux：观察命令及其参数
ps -ef | grep '[m]ihomo'

查询不到进程，可能是程序已退出，也可能是名称不同或查询权限有限。进程存在，则继续确认其配置文件与监听行为。配置文件中写有某个端口，只表示启动意图；只有操作系统实际建立监听，才进入下一阶段。

监听冲突先找所有者，再处理

Mihomo日志出现address already in use之类提示时，用系统工具查询端口。下列7890只是示例数字，应替换成实际配置的端口。Windows可先查看连接条目的OwningProcess，再查询对应进程；Linux的进程详情可能需要相应权限。这里展示查询，不建议直接结束未知进程。

# Windows PowerShell：将7890替换为实际端口
Get-NetTCPConnection -LocalPort 7890 -State Listen

# Linux：查看TCP监听，进程信息可能受权限限制
ss -ltnp

同时核对监听地址。127.0.0.1是IPv4本地回环，绑定它通常只接受本机访问；局域网设备不能据此推断服务已开放。0.0.0.0表示所有IPv4接口，暴露范围不同。TCP与UDP也要分别检查，不能只看到一种协议的条目就认为全部正常。不要通过关闭全部防火墙来替代定位。

把配置错误与连接错误分开记录

如果日志指向文件解析或资源加载，优先回到配置有效性检查流程。若Mihomo本地监听已成功，而实际请求仍失败，再核对应用是否使用了正确代理地址、远端服务是否可达以及日志对应哪一次请求。监听成功不等于远端连接成功，本地端口失败也不能直接归咎于远端节点。

分享日志前移除凭据、订阅地址、控制密钥及个人网络信息，保留时间顺序与错误上下文。每轮只更改一个已定位的因素，并记录更改前后的观察。涉及重启或替换程序时，遵循运行维护指南中的检查次序，先保存可恢复的配置。

一次可复现的诊断，应能说明程序有没有启动、读的是哪份配置、端口是否监听、失败发生在哪个请求阶段。证据完整时，下一步通常是一个小范围修正，而不是重装所有组件。