宝塔Nginx日志清理与Logrotate配置教程

宝塔面板清理Nginx日志的正确姿势不是点击“清空”按钮——那只会截断当日数据、丢失归档、无法追溯且易引发写入失败；真正高效可靠的方案是启用Logrotate实现自动化按天轮转：通过勾选站点日志切割、配置带--keep-days参数的定时任务、校准权限与pid路径，让日志自动归档压缩、按需保留、闭环管理，既保障运维可追溯性，又彻底解决磁盘爆满顽疾。

宝塔面板清理 Nginx 日志，核心不是“删”，而是“轮转+归档+自动清理”——直接清空日志会丢失当天数据，且不解决根本问题；Logrotate 按天轮询才是标准运维做法。

为什么不能直接用宝塔“清空日志”按钮？

点击网站设置 → 日志选项卡 → 清空网站日志，确实能立刻释放空间，但：
• access.log 和 error.log 会被截断为 0 字节，当天新请求日志仍写入该文件，无法追溯切割前行为
• 不生成带日期后缀的归档（如 access.log-20260402），无法做时间维度分析
• 下次再爆满还得手动点，没形成闭环
• 宝塔的“清空”不触发 Nginx 重开日志文件，可能导致部分日志写入失败（尤其高并发时）

如何在宝塔中启用 Logrotate 按天轮询？

宝塔已内置 logrotate 集成，无需手写全局配置，但需确认三项关键开关：

• 站点设置中必须勾选 启用日志切割（路径：网站 → 设置 → 日志选项卡）
• 计划任务里要存在名为 Nginx 日志切割 的定时任务（路径：计划任务 → 查找该名称）
• 该任务的执行命令中必须含 --keep-days= 参数，例如 --keep-days=30，它决定保留多少个归档版本

如果任务不存在，或参数缺失，说明日志切割未真正激活。此时应手动添加任务，类型选 Shell 脚本，内容填：
/usr/sbin/logrotate -f /etc/logrotate.d/bt_nginx

自定义轮询规则：修改 rotate 天数与压缩行为

宝塔默认保留 30 天日志，但多数生产环境只需 7–15 天。修改方式有三层，优先级从高到低：

• 最直接：编辑站点专属配置文件，路径是 /www/server/panel/vhost/logrotate/nginx/example.com（example.com 替换为你的域名），找到 rotate 30 行，改成 rotate 7
• 批量控制：进计划任务 → 编辑 Nginx 日志切割 任务 → 把命令中的 --keep-days=30 改为 --keep-days=7
• 底层验证：执行 logrotate -d -f /etc/logrotate.d/bt_nginx，看 debug 输出是否识别到你改的天数（-d 是安全调试模式，不真实切割）

注意：compress 和 delaycompress 默认开启，意味着第二天才会压缩前一天的日志，方便紧急排查；若关掉 delaycompress，当日切割后立即压缩，但会失去快速查看昨日原始日志的能力。

常见失败现象与定位方法

配置完却看不到 access.log-20260402.gz 文件？先检查这三处：

• 日志目录权限不对：Nginx 进程属主是 www，但 /www/wwwroot/example.com/logs/ 目录属主可能是 root，导致 logrotate 无法重命名或创建新文件 —— 执行 chown -R www:www /www/wwwroot/example.com/logs
• pid 文件路径错误：postrotate 脚本里写的 /www/server/nginx/logs/nginx.pid 必须真实存在，且可读；若 Nginx 是 Docker 启动，路径和信号方式完全不同
• logrotate 本身没运行：查 cat /etc/cron.daily/logrotate 是否存在，再看 ls -l /var/spool/anacron/cron.daily 时间戳是否更新 —— 若 cron 停了，手动跑一次 /usr/sbin/logrotate -f /etc/logrotate.d/bt_nginx 就能立刻验证效果

真正的难点不在配置语法，而在于权限链和信号链是否完整贯通：logrotate → 重命名日志 → Nginx 接收到 USR1 → 重新打开 access.log 写入新内容。任一环断裂，日志就卡在原地不动。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~