error_log是验证nginx平滑重启是否成功的最直接窗口，记录reload全过程关键状态：如“reloading configuration”“using inherited sockets”“exit”“start worker processes”，异常时则明确提示语法错误、端口冲突、权限不足或强制退出等根因。
error_log 是观察 Nginx 平滑重启是否成功最直接、最可靠的窗口。它不只记录错误，更忠实反映 reload 全过程的关键状态变化。
reload 触发时的典型日志痕迹
执行 nginx -s reload 或发送 SIGHUP 后，error.log 会立即输出几条关键 notice 级日志：
- "reloading configuration" —— 表明 Master 已收到信号，开始加载新配置；
- "using inherited sockets from ..." —— 表明新 Worker 成功继承了监听 socket（端口复用成功）；
- "exit" 或 "exiting" + 进程 PID —— 标志旧 Worker 正在优雅退出；
- "start worker processes" 或类似提示（取决于编译选项）—— 表示新 Worker 已启动并就绪。
异常情况在 error_log 中的明确体现
一旦 reload 失败或行为异常，error.log 几乎总是第一时间暴露根因：
- 配置语法错误：出现 "syntax error in ..." 或 "unknown directive"，且 reload 中止，旧 Worker 继续运行；
- 端口绑定失败：报 "bind() to 0.0.0.0:80 failed"，通常因旧 Worker 未及时释放 socket 或存在外部进程抢占；
- 权限不足：如 "open() "/var/log/nginx/access.log" failed (13: Permission denied)"，说明新 Worker 无法打开日志文件；
- worker_shutdown_timeout 触发强制退出：若看到 "gracefully shutting down" 后紧跟 "force exit"，说明有长连接超时未结束。
如何高效利用 error_log 辅助验证
不要等出问题才翻日志。日常 reload 操作建议配合以下方式实时观察：
- 执行 tail -f /var/log/nginx/error.log 后再运行 nginx -s reload，全程盯住输出；
- 关注时间戳是否连续、notice 是否成对出现（如 reload 开始 + socket 继承 + exit + start）；
- 确认没有 emerg 或 error 级别日志混入，尤其注意 reload 前后是否有新增的报错行；
- 若使用 logrotate 或自定义切割脚本（如 cutting_nginx_log.sh），确保 nginx -s reload 在 mv 日志后执行，否则新 Worker 可能因找不到 access.log 而报错。
与其他验证手段交叉印证
error.log 提供的是“发生了什么”，还需结合其他信息判断“是否生效”：
- 查 ps aux | grep nginx：应短暂出现新旧 Worker 共存（状态含 exiting 和 running）；
- 看 curl -I http://localhost 响应头：验证新配置项（如新增的
add_header）是否已生效； - 核对 nginx -t 输出：必须为 "syntax is ok"，否则 reload 必然失败，error.log 会明确提示。
