Nginx不支持自动日志切割，Linux用logrotate（配USR1信号）实现稳定轮转，Windows只能停服归档或改用WSL2；切勿直接删除日志文件，需确认pid路径与运行权限。
Nginx 本身不支持自动日志切割，无论 Windows 还是 Linux，都需借助外部机制实现。但两者生态差异大，实现方式和稳定性有本质区别：Linux 下有成熟、可靠、生产级的方案；Windows 下则受限于系统能力，只能退而求其次做近似处理。
Linux 环境：用 logrotate 实现稳定可靠的日志轮转
这是生产环境唯一推荐的方式。logrotate 是系统级工具，能精准控制切割时机、压缩、保留策略，并通过 USR1 信号通知 Nginx 重新打开日志文件，确保不丢日志、不占磁盘。
- 编辑配置文件：/etc/logrotate.d/nginx
- 内容示例（按天切割、保留30天、gzip压缩）：
/var/log/nginx/*.log {
daily
missingok
rotate 30
compress
delaycompress
notifempty
sharedscripts
postrotate
[ -f /var/run/nginx.pid ] && kill -USR1 $(cat /var/run/nginx.pid)
endscript
}
- 关键点：必须用 postrotate 调用 USR1 信号，否则 Nginx 仍会往旧文件描述符写入，导致切割失效
- logrotate 默认每天凌晨触发，无需额外配 crontab
- 支持 dateext（如 access.log-20260820）、olddir（归档目录）、create（自动建新日志）等实用特性
Linux 环境：手动脚本 + crontab（适合调试或特殊逻辑）
当需要自定义命名规则、多级归档、或集成其他运维流程时，可写 Shell 脚本替代 logrotate。
- 脚本核心三步：重命名旧日志 → 发送 USR1 → 清理过期文件
- 示例片段：
LOG_DIR="/var/log/nginx"
YESTERDAY=$(date -d "yesterday" +%Y-%m-%d)
mv ${LOG_DIR}/access.log ${LOG_DIR}/access_${YESTERDAY}.log
kill -USR1 $(cat /var/run/nginx.pid)
- 加入 crontab（每天凌晨0点执行）：0 0 * * * /path/to/cut-nginx-log.sh
- 注意：脚本需有执行权限（chmod +x），且路径、pid 文件位置要与实际一致
Windows 环境：无法真正“切割”，只能定时归档+重启模拟
Windows 缺乏类似 USR1 的进程间信号机制，Nginx for Windows 也不支持 reopen 操作。因此无法在不中断服务的前提下完成安全切割。
- 常见做法是：用 PowerShell 或批处理脚本，在低峰期执行以下操作
- 停止 Nginx：nginx -s stop
- 重命名日志：ren logs\access.log access_%date:~0,4%%date:~5,2%%date:~8,2%.log
- 启动 Nginx：start nginx.exe
- 该方式会导致短暂服务中断（通常几百毫秒），不适合高可用场景
- 若必须零中断，只能改用 WSL2 运行 Linux 版 Nginx，再走 logrotate 方案
通用注意事项（跨平台都适用）
- 切勿直接删除日志文件：Nginx 仍持有文件句柄，磁盘空间不会释放，直到进程重启
- 确认 pid 文件路径：不同安装方式（源码编译、包管理器、Docker）中 nginx.pid 位置可能不同，务必核对 nginx.conf 中 pid 指令配置
- 权限问题：logrotate 脚本或自定义脚本需以 root 或 Nginx 工作用户权限运行，否则无法读取 pid 或写入日志目录
- 验证是否生效：切割后检查新日志是否持续写入、旧文件是否不再增长、文件大小是否归零
