排查Nginx Worker崩溃须先看error_log中signal值：signal 11为段错误（非法内存访问），signal 9为OOM Killer强制终止，signal 6为主动中止（断言失败等），再结合崩溃前1–3秒日志、隔离第三方模块及启用core dump与debug日志综合定位。

排查 Nginx Worker 进程崩溃，关键不是看“进程退出了”，而是弄清“为什么退出”——信号值（signal number）才是第一线索，它直接指向崩溃类型和排查路径。

先看 error_log 里的 signal 值

打开 /var/log/nginx/error.log，找类似这样的行：

2026/06/04 15:22:18 [alert] 12345#0: worker process 78901 exited on signal 11 (core dumped)

重点是 signal 11、signal 9 或 signal 6，它们含义完全不同：

• signal 11 → SIGSEGV，段错误：非法内存访问，常见于第三方模块不兼容、空指针、SSL 断言失败或配置文件缺失
• signal 9 → SIGKILL，被强制终止：大概率是 OOM Killer 杀掉的，或 systemd 设置了过低 memory limit
• signal 6 → SIGABRT，主动中止：常因断言失败（如云锁/WAF 插件初始化异常）、模块加载失败或 OpenSSL 内部报错

往前翻日志，找紧邻上下文

单独一行 signal 日志几乎无法定位问题，必须结合崩溃前 1–3 秒的 warn/error 记录：

• 若出现 open() "/etc/nginx/mod_fastdfs.conf" failed (2: No such file)，说明 fastdfs 模块因配置缺失而初始化失败，极易引发后续段错误
• 若出现 recv() failed (104: Connection reset by peer) while reading response header from upstream，需检查后端返回了异常二进制数据，被 Lua 或其他解析模块误读
• 若 signal 11 总在特定 URL（如 /api/v2/upload）或超长 Header（如 X-Trace-ID 超过 4KB）后触发，基本可稳定复现，适合压测 + gdb 调试
• 若伴随 SSL_do_handshake() failed (SSL:) SSL alert number 40，尤其在 Nginx ≤1.16 + OpenSSL 1.0.2 组合下，可能是 SSL 配置触发 OpenSSL 断言

快速隔离第三方模块

绝大多数崩溃由第三方模块引入（如 fastdfs-nginx-module、ngx_lua、云锁内核过滤器），验证方式要最小化：

• 临时注释掉所有 load_module 行，只保留官方核心模块，执行 nginx -t && nginx -s reload，观察崩溃是否消失
• 每次只启用一个可疑模块，对相同请求路径持续压测（例如 ab -n 1000 -c 50 http://host/api/），确认哪个模块一启用就复现
• 若使用 Lua 脚本，检查是否有未释放的 shared dict、未关闭的 socket 或全局变量循环引用

开启 core dump 和调试支持

没有 core 文件，就等于失去现场证据。需提前配置才能捕获：

• 启动前执行 ulimit -c unlimited；若用 systemd，需在 service 文件中加 LimitCORE=infinity
• 设置系统 core 路径：echo '/var/log/nginx/core.%e.%p.%t' > /proc/sys/kernel/core_pattern，并确保目录可写
• Nginx 编译时建议加 --with-debug，error_log 级别设为 debug，能记录信号接收、模块初始化等细节
• 崩溃后用 gdb $(which nginx) /var/log/nginx/core.nginx.*，再执行 bt full 查看完整堆栈