Mihomo 日志不是越多越好。日志太少看不出问题，日志太多又会淹没关键行，还可能暴露敏感信息。正确做法是按故障类型选级别，短时间复现，再截取最小样本。
四个常用级别怎么选
| 级别 | 适合场景 | 不适合场景 |
|---|---|---|
debug | DNS、规则命中、连接路径、provider 细节 | 长期开启、公开粘贴 |
info | 日常运行、启动状态、常规错误 | 深挖单个连接 |
warn | 只想看异常趋势 | 首次排障，信息太少 |
error | 监控服务是否崩掉 | 分析慢、分流错误、DNS 抖动 |
如果不确定，从 info 开始。能稳定复现后，再切 debug。
配置位置
常见写法：
log-level: info需要详细取样时改成：
log-level: debug图形客户端通常也提供日志级别开关。改完后重启内核或重新载入配置，确认日志第一屏显示的是新级别。
按问题筛关键行
DNS 问题看：
[dns] query example.com A
[dns] exchange failed
[dns] cache hit连接问题看：
[TCP] dial Proxy -> example.com:443
connect error
context deadline exceededprovider 问题看：
[Provider] update provider-a
fetch failed
parse proxy provider failed规则问题看：
match RuleSet(github) using Proxy
match GeoIP(private) using DIRECT不要只截最后一行 error。很多错误的真正原因在前 20 行，例如 DNS 先失败，后面连接才超时。
取样步骤
- 记录客户端、内核版本、系统和时间。
- 清空当前日志视图或记下当前行号。
- 切到
debug。 - 执行一个明确动作：更新订阅、访问一个域名、切换一个策略组。
- 复现后立刻切回
info。 - 截取动作前后 30 到 60 秒。
如果是间歇问题，不要开着 debug 放一整天。可以用 info 观察发生时间，再围绕可疑时间段取更细日志。
脱敏清单
提交 issue 或求助前，至少替换这些内容：
- 订阅 URL 和查询参数。
- 节点地址、端口、密码、UUID、private key。
external-controller的secret。- 家庭或公司内网网段、设备名称。
- 真实公网 IP。
- provider URL 中的 token。
可以保留字段形状，例如 https://sub.example.com/api?token=REDACTED，这样别人仍能判断是不是 URL、YAML 或 provider 格式问题。
不同故障的最小样本
| 故障 | 样本要包含 | 常见缺失 |
|---|---|---|
| 订阅更新失败 | provider URL 拉取、HTTP 状态、parse 行 | 只给 UI 截图 |
| 域名打不开 | DNS query、规则命中、dial 行 | 只给浏览器报错 |
| 分流不对 | 目标域名、命中规则、策略组 | 没说明访问目标 |
| 启动失败 | 配置加载、端口绑定、权限错误 | 只给最后一行 |
| 面板连不上 | controller 地址、secret 验证结果 | 把代理端口当 controller |
如果你使用配套订阅线路，求助时也不要贴完整订阅链接。只说明导出格式、客户端和错误行即可。
什么时候不需要 debug
以下情况先不用 debug：
- 客户端根本没启动，看配置解析和权限。
- 端口被占，
info或warn通常已经够。 - 只是要确认 provider 是否能访问，直接 curl 更快。
- 面板 401，检查 secret。
debug 是放大镜，不是清洁剂。配置结构错、URL 返回错误页、系统代理残留，这些问题不会因为日志更详细而自动解决。