nginx 本身不支持在配置中用 $year 等变量动态生成带日期的日志文件名实现按天滚动，因启动时仅解析一次路径；真正落地需依赖 logrotate 配合 dateext 与 dateyesterday 成对使用，并通过 kill -usr1 安全重开日志文件，且必须经 -d 和 -vf 两级测试验证。
Nginx 本身不支持在 nginx.conf 里用变量（如 $year、$month）动态生成带日期的日志文件名来实现按天滚动——这种写法看似可行，但实际会失败：Nginx 启动时只解析一次日志路径，不会每天自动更新文件名，最终所有日志仍会持续写入同一个文件，或因路径不存在直接报错丢日志。
真正能落地的按天滚动，必须靠外部工具配合信号控制。以下是关键实操点：
logrotate 配置中 dateext 和 dateyesterday 必须同时启用
只写 dateext，生成的归档名是 access.log-20260908（轮转当天），但你真正想存的是“昨天的日志内容”。加 dateyesterday 才能让文件名变成 access.log-20260907，语义准确、排查时不易混淆。
常见错误：
- 忘了 dateyesterday，导致日志名和内容日期对不上
- 没配 sharedscripts，access.log 和 error.log 被分别发两次 USR1，可能触发竞态
-
dateext和dateyesterday必须成对出现，否则后者无效 - 若要自定义格式（如
access.log_20260907），加dateformat _%Y%m%d - 确认你的 Nginx 日志路径与配置中完全一致，比如是
/var/log/nginx/*.log还是/usr/local/nginx/logs/*.log
postrotate 中 kill -USR1 必须安全读取 PID 文件
Nginx 收到 USR1 信号后，会原子性地关闭旧句柄、打开新日志文件，不中断请求。但直接硬编码 /var/run/nginx.pid 很危险——容器环境可能没这个路径，OpenRC 系统 PID 文件可能在 /run/nginx.pid，甚至有些编译安装的 Nginx 根本不生成 PID 文件。
更健壮的写法：
postrotate
pidfile=$(nginx -t 2>&1 | grep "pid" | awk '{print $NF}')
[ -f "$pidfile" ] && kill -USR1 $(cat "$pidfile")
endscript
- 避免用
systemctl reload或nginx -s reload替代USR1：前者会平滑重启 worker，有极小概率丢请求；后者依赖 systemd，不可移植 - 务必加
[ -f "$pidfile" ] &&判断，防止cat报错中断脚本 - 如果 Nginx 是非 root 用户启动（如 docker 容器内），确保 logrotate 运行时有权限读取该 PID 文件
测试阶段必须用 logrotate -d 和 -vf 两级验证
很多人跳过测试，等 cron 自动跑才发现日志没切、旧文件没压缩、甚至新日志写不进去了。根本原因是权限、路径、PID 三者中任一出错，logrotate 就静默跳过。
- 先跑
logrotate -d /etc/logrotate.d/nginx：看输出里是否识别到你的日志文件、是否找到 PID、是否计划执行postrotate - 再跑
logrotate -vf /etc/logrotate.d/nginx：强制执行一次，立刻检查/var/log/nginx/下是否出现access.log-20260907（注意日期是否为昨天）、新access.log是否可写、文件属主是否正确 - 别信“cron.daily 会自动跑”——手动验证完再等系统调度，否则问题暴露滞后
真正的难点不在写配置，而在路径一致性、PID 可达性、以及测试时是否真的观察到了文件状态变化。漏掉任意一个环节，日志就可能无声无息地堆积或中断。
