Clash Verge Rev 日志文件过大清理与日志级别调整
C 盘空间以肉眼可见的速度在掉，用空间分析工具一扫，发现 Clash Verge Rev 的日志目录占了几十 GB。这不是罕见情况：有用户的 service 日志目录里躺着 35 GB、5.85 GB、2.91 GB 的单个 .log 文件，合计超过 47 GB。Clash Verge Rev 的日志体系分两层——GUI 应用日志和 Mihomo 内核日志，内核日志在服务模式下由 clash-verge-service 写入，路径独立，出问题时往往比界面日志更容易失控。日志文件过大清理与日志级别调整的核心，是先找到真正占空间的那一层，再把它的写入量降下来。
01. 先定位：占空间的是 GUI 日志还是内核服务日志
不要凭感觉删文件。Clash Verge Rev 的日志分布在几个不同的子目录里，体积最大的通常不是界面日志。
从“设置 → Verge 高级设置 → 日志目录”打开的是应用日志根目录。v2.5.2 当前日志使用 latest 命名，同时保留轮转文件，不要因为没找到日期序号就以为日志丢失了。这个目录下的 latest.log 对应 GUI 应用层，sidecar/sidecar_latest.log 对应 sidecar 模式下的内核日志。
真正的大头在 service 子目录。 这个目录和站点统一规定的配置文件目录（C:\Users\用户名\.config\clash-verge\）不是同一个位置，它是日志专用路径，Windows 下位于：
C:\Users\用户名\AppData\Roaming\io.github.clash-verge-rev.clash-verge-rev\logs\service服务模式运行时，内核日志由 clash-verge-service.exe 写入这个目录，与 GUI 的日志轮转逻辑是分开的。有用户在这个目录里发现单个 .log 文件达到 35 GB，说明服务侧日志在特定版本或特定触发条件下缺少有效的体积上限。先打开这个目录，按文件大小排序，确认是不是它占了大头。
| 目录/文件 | 对应层 | 典型失控原因 |
|---|---|---|
latest.log |
GUI 应用日志 | app_log_level 长期为 debug |
sidecar/sidecar_latest.log |
sidecar 内核日志 | log-level 为 debug，sidecar 模式下轮转有限 |
service/service_latest.log |
服务模式内核日志 | 服务侧轮转/清理策略未生效 |
service/ 下的大体积 .log |
服务模式历史日志 | 旧版轮转缺失或清理周期过长 |
02. 安全清理：哪些能删，哪些不能碰
确认 service 目录下存在超大 .log 文件后，清理本身很简单，但前提是先彻底退出 Clash Verge Rev。服务日志由后台服务进程持有，不退出客户端直接删可能被句柄锁定，或者删除后服务继续写入同一个文件，起不到释放空间的效果。
可以删除：logs\service 目录下所有 .log 文件，包括 service_latest.log 和体积异常的旧日志。关闭 Clash Verge Rev 后直接删除即可，不需要额外工具。
不要删除：配置文件目录 C:\Users\用户名\.config\clash-verge\ 下的 profiles、config.yaml、verge.yaml。这些是订阅和配置，和日志是两回事。日志目录和配置目录是两套独立路径，清理日志时手滑删到配置目录，恢复成本远高于释放几十 GB 空间。
清理后先不要急着重新打开客户端。如果日志级别没有改动，服务重新启动后会继续按原来的级别往 service 目录写，用不了多久又会长回来。清理只是止血，降低写入量才是治本。
03. 内核层：Mihomo 的 log-level 怎么改
Mihomo 的日志级别由顶层 YAML 键 log-level 控制，可选值为 silent、error、warning、info、debug。它没有嵌套的 log 块，也不支持 log-file 字段，日志写入目标由客户端（Clash Verge Rev）决定，内核只负责按级别产出内容。
把内核 log-level 调回 info 或更高级别，是缓解 Clash Verge Rev 日志文件过大的第一步。
日常设置：info 是默认值，记录一般操作和警告/错误，适合大多数场景。如果只关心明确的失败事件，warning 或 error 能进一步减少输出。silent 几乎完全关闭内核日志，只有在确定不需要任何排查依据时才使用。
排障时：临时改为 debug，定位完立刻改回 info 或 warning。debug 级别下内核会输出每条连接的规则匹配和 DNS 解析细节，流量大时日志量是 info 级别的数倍甚至更多，长时间开启是服务日志迅速膨胀的最常见原因。
修改位置在 Clash Verge Rev 的“设置 → 内核设置（或 Clash 设置）→ 日志等级”，或者在配置文件的 config.yaml 顶层直接编辑：
log-level: warning改完后重启内核或重新载入配置，确认日志第一屏显示的是新级别，而不是旧级别继续输出。
04. 界面层：app_log_level 与自动清理
GUI 应用日志由 verge.yaml 中的 app_log_level 控制，可选值为 trace、debug、info、warn、error、silent。它和内核的 log-level 是两套独立设置，改一个不会同步另一个。如果 GUI 日志也在涨，把 app_log_level 从 debug 或 trace 调到 info 或 warn 即可。
自动清理是更省心的手段。 verge.yaml 中的 auto_log_clean 字段支持按周期清理日志，对应关系如下：
| 值 | 周期 |
|---|---|
| 0 | 不自动清理 |
| 1 | 1 天 |
| 2 | 7 天 |
| 3 | 30 天 |
| 4 | 90 天 |
在“杂项设置”中设置自动清理间隔，和直接改 verge.yaml 效果一致。对于长期挂机、不常手动检查日志的用户，设为 7 天或 30 天是合理的平衡：既能保留足够的历史用于回溯，又不会让日志无限累积。
05. 轮转参数：app_log_max_size 与 app_log_max_count
如果希望日志在单个文件体积上也有硬上限，而不只是靠定期清理，可以调整轮转参数。app_log_max_size 控制单个日志文件的最大体积，单位是 KiB；app_log_max_count 控制保留的轮转文件数量。
这两个字段在 verge.yaml 中：
app_log_max_size: 10240
app_log_max_count: 3上面的示例把单文件上限设为 10 MB，最多保留 3 个轮转文件，加上当前文件，GUI 日志目录的理论上限大约在 40 MB 量级。具体数值按磁盘空间和排查需求调整，但思路是明确的：不要让任何一个日志文件没有上限。
服务模式日志的轮转由服务侧逻辑管理，app_log_max_* 主要作用于 GUI 日志。如果 service 目录下的文件仍然不受这两个参数约束而无限增长，说明问题出在服务日志的轮转环节，而非 GUI 配置。这种情况下，定期检查 service 目录并结合自动清理周期，比单纯调大或调小轮转参数更实际。
06. 日志暴涨的根因排查：不是所有“大”都是正常的
日志文件过大通常是两个因素叠加的结果：级别太细 + 流量太大。把 log-level 从 debug 降到 info 或 warning 能解决大多数情况。
如果 Clash Verge Rev 日志文件过大在 warning 级别下仍然复现，服务日志在短时间内快速膨胀，需要看日志内容里反复出现的是什么。大量重复的 dial DIRECT 超时、连接重试或 DNS 失败记录，可能指向规则配置或节点稳定性问题，而不是日志级别本身。这类情况下单纯调高日志级别只是把症状盖住，连接重试和失败会话的根源仍然存在。日志管理在这里的作用是帮你定位问题，而不是代替排错。
排查期间需要临时开 debug 时，记得同时把 auto_log_clean 设为一个短周期（比如 1 天），或者手动盯着 service 目录的体积，避免排障本身变成下一次磁盘告急的原因。日志导出与脱敏的具体操作可以参考 FAQ 页面 中的日志相关条目，覆写配置的位置和合并逻辑见 Merge 与 Script 指南。