Mihomo怎么查看日志？按运行方式找到实时与历史日志
简答：Mihomo 查看日志要先看它是通过图形客户端、普通进程、systemd 还是 Docker 启动的。最快方法是：图形客户端打开日志页；systemd 执行 journalctl -u mihomo -f；Docker 执行 docker logs -f 容器名；启用了控制器 API 时访问 /logs。看到时间、错误级别和对应域名后，再判断是 DNS、规则、节点还是本地网络问题。
定义：Mihomo 日志是内核输出的运行信息，通常包括启动配置、DNS、规则匹配、连接建立和错误提示；实时日志用于复现问题，历史日志用于回看已经发生的故障。
先按运行方式选择查看方法
不要先到处寻找一个固定的“日志文件”。Mihomo 的日志输出位置取决于启动方式：图形客户端可能把内核输出放在控制页面，命令行启动通常输出到终端，systemd 服务会进入系统日志，Docker 则通常从容器的标准输出和标准错误读取。Mihomo 文档还说明，log-level 主要控制控制台和控制页面输出，因此“没有日志”不一定代表没有发生连接请求，也可能是日志级别过低或当前流量没有经过该内核。
| 运行方式 | 优先查看位置 | 最短操作 | 适合判断 |
|---|---|---|---|
| 图形客户端 | 客户端的日志、控制页或内核输出页 | 打开日志页后复现一次问题 | 节点、规则、DNS、连接失败 |
| 普通进程 | 启动终端或重定向后的文件 | 回到启动窗口，或对日志文件执行 tail -f | 启动报错、配置解析、实时连接 |
| systemd | systemd journal | journalctl -u mihomo -o cat -f | 服务启动、重启、权限和配置错误 |
| Docker | 容器标准输出和标准错误 | docker logs -f mihomo | 容器启动、挂载、端口和运行时错误 |
| 控制器 API | /logs 实时接口 | 使用带鉴权的 GET 或 WebSocket 请求 | 按日志级别和结构化字段筛选 |
图形客户端的具体按钮名称会因客户端和版本不同而变化。如果页面里没有“日志”字样，可在内核、控制器、运行状态或诊断区域查找；无法确认具体菜单时，不要把某个客户端的路径套用到所有 Mihomo 客户端。
Linux systemd：查看历史日志和实时日志
如果 Mihomo 是按 systemd 服务运行，先确认服务名。常见服务名是 mihomo，但如果你创建过自定义单元，实际名称可能不同。Mihomo 文档给出的服务检查和日志命令包括 systemctl status mihomo、journalctl -u mihomo -o cat -e 和 journalctl -u mihomo -o cat -f，可参考Mihomo systemd 服务文档。
- 先查看服务是否存在并确认是否正在运行：
systemctl status mihomo。 - 查看已经产生的日志，并跳到末尾：
journalctl -u mihomo -o cat -e。 - 打开实时跟随模式：
journalctl -u mihomo -o cat -f。 - 保持窗口运行，另开一个终端复现一次连接失败、DNS 失败或网页打不开的问题。
- 按时间点查看输出；如果日志窗口完全没有新内容，先检查应用流量是否真的经过 Mihomo，再检查
log-level是否为silent。
如果服务名不是 mihomo，可先运行 systemctl list-units --type=service | grep -i mihomo 查找实际名称。journalctl 的 -u 用于筛选指定服务单元，-f 用于持续显示新追加的日志；这些选项可参阅systemd journalctl 文档。排查完成后按 Ctrl+C 退出跟随模式，不会停止 Mihomo 服务。
Docker：实时跟随、截取历史和按时间筛选
Docker 方式不要优先猜容器内的日志文件路径。Docker 官方文档说明，docker logs 用于读取容器日志，--follow 会持续输出容器的标准输出和标准错误，--tail、--since 和 --timestamps 可用于限制范围和显示时间。
- 先列出容器名称和运行状态：
docker ps -a。 - 实时查看名为
mihomo的容器：docker logs --follow --timestamps mihomo。 - 只看最近 200 行并继续跟随：
docker logs --tail 200 --follow --timestamps mihomo。 - 只看最近 10 分钟：
docker logs --since 10m --timestamps mihomo。 - 复现问题后按时间戳截取日志，避免把整段运行记录直接发给别人。
如果容器名不是 mihomo，将命令中的名称替换为 docker ps -a 显示的实际名称。若命令几乎没有输出，可能是容器启动命令没有把 Mihomo 输出到标准输出，也可能是 log-level 设置过低；此时应先查看容器启动参数、配置挂载路径和容器状态，而不是直接删除容器。参考Docker container logs 文档。
普通进程或脚本：从终端和重定向文件查看
如果你直接在终端运行 Mihomo，日志通常会随着进程输出到当前终端。启动窗口仍在时，先回到该窗口，再复现一次问题；如果启动脚本把输出重定向到了文件，则需要查看脚本中的重定向位置。
常见的标准输出重定向形式是：
./mihomo -d ./data > mihomo.log 2>&1
实时查看该文件可以使用：
tail -f mihomo.log
如果只想先查看末尾内容：
tail -n 200 mihomo.log
上面的文件名和目录只是命令示例，不代表所有安装方式都会自动生成同名文件。只有当启动脚本确实把标准输出写入该路径时，tail 才能看到内容。Windows、macOS 图形客户端或其他启动器可能采用不同的日志保存方式，应以启动参数和客户端页面当前显示为准。
使用控制器 API 查看 /logs 实时日志
如果配置中启用了 external-controller，可以通过控制器 API 获取实时日志。Mihomo API 文档列出 /logs 的 GET 和 WebSocket 用法，支持通过 level 参数筛选 info、warning、error、debug，也支持 format=structured 返回时间、级别、消息和字段。API 通常还需要配置中的 secret 作为 Bearer 鉴权信息，具体字段可查看Mihomo API 文档。
下面是本机控制器监听在 127.0.0.1:9090、密钥为占位符时的最小示例：
curl -H "Authorization: Bearer YOUR_SECRET" "http://127.0.0.1:9090/logs?level=error&format=structured"
把 YOUR_SECRET 换成实际密钥，把地址和端口换成配置中的控制器地址。若只想查看普通运行日志，可将 level=error 改为 info；如果要捕获更详细的调试信息，再考虑 debug。不要把包含真实密钥的命令、完整订阅地址或 API 地址直接发布到公开论坛。
控制器 API 只能访问当前运行内核的实时日志，不等同于自动保存的历史日志。需要回看服务重启前的内容时，应使用 systemd journal、Docker 日志或启动时配置的文件输出。
log-level 怎么选：先用 info，复现时临时提高
Mihomo 配置中的 log-level 可选 silent、error、warning、info 和 debug。公开配置文档将它定义为内核日志输出等级：silent 不输出，error 只输出错误，warning 包含警告和错误，info 输出一般运行信息以及警告和错误，debug 尽可能输出运行细节，详见Mihomo 全局配置中的日志级别说明。
| 目标 | 建议级别 | 处理方式 |
|---|---|---|
| 日常运行 | info | 保留基本运行、警告和错误信息 |
| 只看明显错误 | error | 适合快速确认是否有失败事件 |
| 复现一次连接问题 | debug | 短时间开启，复现后立即恢复 |
| 不想输出日志 | silent | 排障时不建议使用 |
修改配置前先备份当前配置。将 log-level 临时改为 debug 后，重新加载或重启 Mihomo，再只复现一个问题。确认信息后把它恢复到原来的级别，通常可改回 info，但如果原配置不是 info，应恢复原值。不要把 debug 长期开启作为默认方案，因为输出会更密集，也可能暴露更多域名、地址或本地路径。
看懂日志：按现象、时间和关键词定位
日志排查的关键不是收集越多越好，而是让一次复现对应一段可读记录。建议先清空或关闭旧日志窗口，记录当前时间，访问一个明确的域名或执行一次明确的连接操作，再按时间顺序查看。
| 关键词或现象 | 优先检查 | 下一步 |
|---|---|---|
DNS failed、解析超时、无法获取地址 | DNS 配置、上游 DNS、网络可达性 | 先确认是否只有某个域名失败，再单独测试 DNS |
timeout、dial timeout | 目标地址、节点可达性、路由和丢包 | 更换一个节点或测试直连，比较同一时间的结果 |
connection refused | 目标端口、监听状态、端口映射 | 确认服务是否监听，检查 Docker 端口或本机端口 |
| 出现规则类型和策略组名称 | 请求是否进入 Mihomo、规则是否命中 | 结合规则模式和当前策略组检查是否走错出口 |
| 完全没有对应请求 | 系统代理、TUN、应用绕过和端口 | 确认应用流量是否进入 Mihomo，而不是只看节点是否在线 |
单条日志不能独立证明某个节点一定故障，也不能单凭一次 timeout 判断线路质量。更稳妥的流程是“现象—检查—判断—处理—回滚”：先记录错误和时间，再只改一个变量，例如节点、DNS 或规则模式，复测同一请求，最后恢复原配置并比较结果。
分享日志前先脱敏，排查后保留回滚路径
日志可能包含订阅地址、节点域名或 IP、UUID、用户名、认证令牌、API 密钥、局域网地址和本地文件路径。对外求助前，至少删除或替换这些内容；如果日志中出现完整 URL，不能只遮住域名而保留可用的查询参数或密钥。
- 保留：时间、错误级别、错误类型、是否超时、规则类型和非敏感的处理结果。
- 删除：订阅 URL、UUID、密码、Bearer 密钥、节点认证信息和可定位个人设备的路径。
- 避免：直接上传完整配置、完整 debug 日志或带密钥的 curl 命令。
- 回滚：修改
log-level、DNS、节点或规则前先备份，复测后一次只恢复一个改动。
成功判据是：你能在日志中找到本次复现的时间点，确认请求是否进入 Mihomo，看到对应的 DNS、规则或连接错误，并能通过一次可重复的复测判断修改是否产生影响。
常见问题
Mihomo 日志在哪里看？
先确认启动方式。图形客户端通常在日志或控制页面查看；systemd 使用 journalctl；Docker 使用 docker logs；普通进程查看启动终端或输出文件；启用了控制器 API 时可以请求 /logs。不同客户端的菜单名称可能不同，以当前页面为准。
为什么 Mihomo 没有日志输出？
先检查 log-level 是否为 silent 或 error，再确认产生流量的应用是否真的经过 Mihomo。如果使用 systemd 或 Docker，还要确认服务名、容器名和输出方式是否正确。只打开日志页面但没有复现请求，也可能暂时没有新日志。
Mihomo 怎么查看实时日志？
systemd 可执行 journalctl -u mihomo -o cat -f；Docker 可执行 docker logs --follow --timestamps 容器名；普通进程可回到启动终端或执行 tail -f 日志文件；控制器 API 可请求 /logs，并按 level 筛选。
Mihomo 的 debug 日志要一直开着吗？
不建议。排障时临时改为 debug，复现一个明确问题后立即恢复原来的 log-level，通常可恢复为 info。debug 输出可能更密集，也可能包含更多域名、地址和本地路径。
分享 Mihomo 日志会泄露什么？
可能泄露订阅地址、UUID、节点地址、用户名、API 密钥、本机路径和局域网信息。公开前应删除密钥和认证信息，只保留时间、错误级别、错误类型及必要的规则或连接结果。
相关阅读
参考资料
- Mihomo API 文档：/logs、鉴权与结构化日志，访问日期 2026-11-11
- Mihomo 全局配置：log-level 与 external-controller，访问日期 2026-11-11
- Mihomo systemd 服务与 journalctl 日志命令，访问日期 2026-11-11
- Docker 官方文档：docker container logs，访问日期 2026-11-11
- systemd 官方 journalctl 文档，访问日期 2026-11-11（freedesktop.org）