排查 Clash 故障时，日志级别决定内核会往外吐哪些信息。官方全局配置用 log-level 控制等级，并写明这些日志仅在控制台和控制页面输出。选择级别前，先分清当前是“已经无法使用”，还是“仍能运行但行为异常”，再对照五个取值的收录范围；不要在看不清输出位置时改配置，也不要在尚未观察前就使用静默。
适用条件与判断依据
只有在你确实需要观察内核输出，并且能够查看控制台或控制页面时，调整 log-level 才有操作意义。官方说明该配置只影响这两处，因此若当前环境既看不到控制台、也打不开控制页面，改级别不会产生可核验的新信息。适用情况包括：代理或入站已经中断、出现不影响运行的错误、需要对照一般运行过程，以及需要尽可能完整的运行信息。若目标只是停止输出，才考虑 silent，它不适合用来找原因。
判断依据必须回到官方定义，而不是自行推测“级别越高越好”。silent 表示静默、不输出；error 仅输出发生错误至无法使用的日志；warning 输出发生错误但不影响运行的日志，以及 error 级别内容；info 输出一般运行的内容，以及 error 和 warning 级别的日志；debug 尽可能输出运行中所有的信息。文档给出的配置写法是 log-level : info。若你无法把现象归入“无法使用”或“不影响运行”，应优先选 info，而不是直接跳到 debug 或长期留在 error。
按故障形态选择级别
当现象是内核或代理已经无法使用，例如核心能力中断、连接完全失败，且你怀疑属于“错误至无法使用”，先把 log-level 设为 error。这一级只收录该类日志，输出最少，便于确认是否存在致命错误。若 error 下没有任何记录，不能据此认定没有问题：不影响运行的错误本来就不会出现在这一级，需要改用 warning 或更高。
当内核仍在运行，但出现异常、非致命失败或行为与预期不符，应使用 warning。官方定义明确它会包含“发生错误但不影响运行”的内容，并同时带上 error 级别内容。这样可以在服务尚未完全停摆时看到错误类信息。若 warning 仍只有孤立错误、缺少一般运行过程，再升到 info，以便把正常路径和错误、警告放在一起对照。
当需要解释规则是否走过、连接是否按一般流程发生，使用 info。文档示例即为此值，适合作为排查中的常规观察级别。仅当 info 仍无法说明原因、必须看到尽可能完整的运行信息时，才使用 debug。debug 的官方描述是尽可能输出运行中所有的信息，信息量最大，只应在需要完整线索的短时间内使用。排查过程中不要使用 silent：它被定义为不输出，无法提供判断依据。
写入配置、核验生效与失败时下一步
在全局配置中设置 log-level，取值只能是 silent、error、warning、info、debug 之一，写法与文档示例一致。保存后使该配置对当前内核生效。是否生效，不以口头描述为准，而以控制台或控制页面的实际输出为准：silent 应不再出现日志；error 应只在“错误至无法使用”时出现记录；warning 应能看到不影响运行的错误并覆盖 error；info 应出现一般运行内容并覆盖前两级；debug 的信息应明显多于 info。
若修改后输出没有按上述规律变化，下一步按顺序检查：取值拼写是否属于五个合法等级；你是否正在查看官方写明的控制台或控制页面，而不是其他无关文件；当前进程是否加载了你刚修改的那一份配置。若确认已是 error 且为空，升到 warning 或 info，而不是反复只盯 error。若 info 仍看不出路径，再升 debug。一旦已经能复现并记录到对应级别的内容，应停止继续升高，避免把“尽可能所有信息”长期留在生产配置里。