排查nginx worker崩溃须先看error_log中signal值：signal 11为段错误，signal 9为oom killer终止，signal 6为主动中止；再结合崩溃前1–3秒日志、core dumped提示、dmesg系统日志及第三方模块隔离综合定位。
error_log 是排查 Nginx 子进程（worker process）异常退出最直接的线索来源，但它本身不记录“进程崩溃瞬间”，而是通过残留信号、连接中断痕迹和系统级报错间接反映问题。关键在于读懂日志中的 alert/emerg 级别信息，并结合上下文交叉验证。
看 signal 字段识别进程被强制终止
Nginx worker 进程非正常退出时，error.log 中会出现明确的 signal 记录：
- [alert] XXX#YYY: worker process ZZZZZ exited on signal 11 → 表示发生段错误（Segmentation fault），常见于模块冲突、内存越界或未启用的第三方模块误调用
- exited on signal 9 → 很可能是被系统 OOM Killer 杀掉，需立即查 dmesg | grep -i "killed process" 确认
- exited on signal 6 → abort 调用，常由内部断言失败触发，多见于配置严重错误或核心模块 bug
关注 core dumped 提示确认是否生成崩溃转储
如果日志中出现 core dumped 字样，说明系统已生成 core 文件（前提是 ulimit -c 设置非零且目录可写）：
- 检查 core 文件存放路径：通常在 nginx 启动目录或 /var/lib/cores/，可用 find / -name "core.*" -mmin -60 2>/dev/null 快速定位
- 用 gdb $(which nginx) core.xxx 加载分析，执行 bt full 查看崩溃堆栈
- 若无 core 文件但日志有 signal，说明 ulimit -c 为 0 或 kernel.sysrq=0 等限制生效
结合系统日志补全退出背景
error_log 只记录 Nginx 主动感知到的异常，真正原因往往藏在系统层：
- 查 OOM 证据：dmesg -T | grep -i "out of memory\|killed process"，确认是否有 nginx 或其 worker 被 kill
- 查 systemd 服务状态：systemctl status nginx 看是否显示 failed，再用 journalctl -u nginx -n 100 --no-pager 查启动/退出前后完整链路
- 查资源瓶颈：free -h 看内存、df -h 看磁盘、ss -s 看 socket 资源是否耗尽
排除配置与模块引发的静默崩溃
某些配置错误不会在 nginx -t 阶段暴露，却会导致 worker 启动后立即退出：
- 检查是否启用了未编译的模块（如配置了 stream 模块但编译时未加 --with-stream）
- 确认 worker_rlimit_core 和 working_directory 设置合理，避免 core 写入失败导致崩溃无痕
- 临时禁用所有第三方模块（如 echo、headers-more），仅保留 core 模块重启测试
