nginx日志平滑切割通过master进程响应usr1信号实现，不中断服务且不丢失日志；核心步骤为重命名旧日志、发送usr1信号触发reopen、验证后归档；推荐用logrotate自动化管理并注意权限、pid路径及执行顺序。

通过 Nginx Master 进程实现日志平滑切割与物理归档，核心是利用 USR1 信号触发日志文件句柄的重新打开，整个过程不中断服务、不丢失请求日志。这不是 Nginx 自身的轮转功能，而是靠外部操作配合 Master 进程的信号响应机制完成的。

理解 USR1 信号的作用

Master 进程收到 SIGUSR1（即 nginx -s reopen 或 kill -USR1 <pid></pid>）后会：

• 从当前配置文件中读取 access_log 和 error_log 的路径定义
• 以 worker 进程用户身份，重新打开这些日志文件（创建新文件或覆盖已存在文件）
• 通知所有 worker 进程关闭旧文件句柄，切换到新打开的文件写入
• 旧日志文件此时已无进程持有句柄，可安全移动、压缩或删除

标准操作流程（手动/脚本化）

按顺序执行以下三步，确保原子性与安全性：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 备份旧日志：将当前正在写的日志重命名，例如：
  mv /var/log/nginx/access.log /var/log/nginx/access.log.$(date +\%F-\%H)
• 触发 reopen：向 Master 进程发送 USR1 信号，方式任选其一：
  nginx -s reopen，或
  kill -USR1 $(cat /var/run/nginx.pid)，或
  kill -USR1 $(pgrep -f "nginx: master")
• 验证与清理：检查新 access.log 是否已生成且有新写入（如 curl 访问后查看文件大小变化），再对归档文件做压缩、同步或上传等后续处理

生产环境推荐：用 logrotate 自动化管理

手动操作适合调试或低频场景；高可用系统应交由 logrotate 托管，它能精准控制周期、保留策略和权限。典型配置（/etc/logrotate.d/nginx）如下：

• /var/log/nginx/*.log {
•   daily —— 每天凌晨触发
•   missingok —— 日志不存在也不报错
•   rotate 30 —— 最多保留 30 份
•   compress —— 压缩旧文件（.gz）
•   delaycompress —— 延迟压缩，确保当日日志不被立即压缩
•   create 0644 www-data adm —— 新日志权限与属主
•   sharedscripts —— 所有匹配文件共用一次 postrotate
•   postrotate
    if [ -f /var/run/nginx.pid ]; then
      kill -USR1 $(cat /var/run/nginx.pid)
    fi
  endscript
• }

关键注意事项

避免常见失误，保障切割可靠：

• 确保 nginx.pid 路径与配置中 pid 指令一致（默认 /var/run/nginx.pid），否则 kill 找不到进程
• 重命名旧日志必须在 reopen 之前完成；若先 reopen，Nginx 会继续往原名文件写，导致归档内容不全
• worker 进程用户（如 www-data）需对日志目录有写权限，否则 reopen 后无法创建新文件
• 若使用容器部署，注意 logrotate 需运行在宿主机或特权容器中，并能访问 Nginx 进程与 pid 文件