推荐将Nginx清理脚本置于/usr/local/bin/并用cron调度，先确认日志路径和logrotate配置，再编写仅删除60天前归档.gz文件的purge脚本，避免与系统轮转冲突，紧急时可用truncate -s 0清空活跃日志。
直接在 Nginx 日志目录下放脚本并不推荐——脚本本身不是日志，混放易误删、难维护、权限混乱。正确做法是把自动化脚本放在标准可执行路径（如 /usr/local/bin/），通过明确路径调用，并用 cron 统一调度。核心在于分离“日志存储”和“运维逻辑”，保障安全与可追溯。
确认日志真实路径和当前轮转机制
先别急着写脚本，花两分钟查清现状：
- 运行
grep access_log /etc/nginx/nginx.conf或nginx -V 2>&1 | grep conf定位实际日志路径，常见为/var/log/nginx/或/usr/local/nginx/logs/ - 检查
ls -l /etc/logrotate.d/nginx，如果存在且已启用 daily + rotate 30，说明系统级 logrotate 正在工作，此时再加自定义脚本可能重复甚至冲突 - 执行
ps aux | grep nginx看主进程是否以 root 启动，决定脚本中 kill 或 truncate 是否需要 sudo
编写清理脚本：只删归档后的过期 .gz 文件
推荐采用“归档优先、清理滞后”策略。假设你已用另一脚本每日将 access.log 压缩为 access.log-20260728.gz 并移入 /var/log/nginx/archive/，那么清理脚本只需专注删除旧包：
新建 /usr/local/bin/nginx-log-purge.sh：
#!/bin/bash ARCHIVE_DIR="/var/log/nginx/archive" # 只删 60 天前的归档日志（.log-*.gz），跳过其他文件 find "$ARCHIVE_DIR" -type f -name "access.log-*.gz" -mtime +60 -delete # 记录操作到系统日志，便于审计 logger "Nginx access log purge: removed files older than 60 days from $ARCHIVE_DIR"
赋予执行权限：chmod +x /usr/local/bin/nginx-log-purge.sh
配置定时任务：用 cron 控制执行节奏
编辑 root 的 crontab（避免权限不足）：sudo crontab -e，添加一行：
0 3 * * * /usr/local/bin/nginx-log-purge.sh这表示每天凌晨 3 点执行清理。避开业务高峰和系统 logrotate 默认时间（通常是凌晨 0–1 点），减少 I/O 冲突。
验证是否生效：等次日运行后，执行 ls -lt /var/log/nginx/archive/ | head -5 查看最新归档文件时间，再用 journalctl -u cron --since "2 days ago" | grep nginx-log-purge 确认执行日志。
补充：若需立即释放空间，慎用 truncate 清空活跃日志
当 access.log 膨胀至数 GB 且磁盘告急时，不要 rm —— nginx 仍持有句柄，空间不释放。临时应急可用：
sudo truncate -s 0 /var/log/nginx/access.log该操作零延时、不中断服务、保留文件属性。但仅作紧急手段，不能替代定期归档机制。
