排查Nginx worker异常退出需先确认core dump是否真实生成（ulimit -c、core_pattern、目录权限/空间），再据signal值（11/9/6）定类型，结合崩溃前1–2秒日志、压测复现、gdb bt full分析堆栈锁定第三方模块或OpenSSL兼容问题。
排查高并发下 Nginx worker 进程异常退出并生成 Core Dump，关键不是等它崩了再翻日志，而是提前布防、精准捕获、分层验证。核心思路是：让崩溃“留痕”，让现场“可读”，让模块“可筛”。
确认是否真有 Core Dump 产生
别只信 error.log 里那句 (core dumped)——它只是系统“尝试”生成，并不保证文件落地。必须交叉验证：
- 执行 ulimit -c，确认返回值不是 0（应为 unlimited 或具体数值）；该命令需在 nginx 启动前生效，若用 systemd，要在 service 文件中加 LimitCORE=infinity
- 查内核配置：cat /proc/sys/kernel/core_pattern，看路径是否可写、目录是否存在（如设为 /var/log/nginx/core.%e.%p，就得确保 /var/log/nginx/ 对 nginx 用户可写）
- 检查目标目录磁盘空间和 inodes 是否充足，尤其是高并发场景下可能瞬间生成多个 core 文件
定位崩溃触发的具体信号和上下文
signal 值是诊断起点，不是终点。高并发下更需结合时间戳和请求特征：
- 在 error.log 中搜索 exited on signal，重点看数字：signal 11 是段错误（内存越界），signal 9 是被 OOM Killer 杀（查 dmesg -T | grep -i "killed process"），signal 6 多为 abort()（常与第三方 WAF 或断言失败有关）
- 往前翻 1–2 秒日志，找紧邻线索：比如 recv() failed (104: Connection reset by peer) while reading upstream，说明后端已挂，worker 在解析异常响应时崩溃；又或出现 SSL_do_handshake() failed，尤其在旧版 OpenSSL 组合下极易引发 signal 11
- 用 ab 或 wrk 模拟相同并发路径压测，观察是否稳定复现，缩小到特定 URL、Header 长度或请求体大小
用 gdb 分析 Core 文件还原现场
拿到 core 文件后，堆栈信息才是真相所在。但必须匹配“完全一致”的 nginx 二进制：
- 确认 nginx 版本、编译参数（特别是是否含 --with-debug）、OpenSSL 版本均与崩溃时完全一致；否则 bt full 可能显示 ?? 或不完整函数名
- 运行 gdb $(which nginx) /path/to/core.xxx，进入后执行 bt full，重点关注调用链中首次出现的第三方模块函数（如 ngx_http_lua_*、fastdfs_*、ngx_waf_*）
- 若堆栈落在 SSL 或 crypto 层（如 CRYPTO_add_lock、ssl3_accept），大概率是 OpenSSL 兼容问题，而非 Nginx 自身 bug
快速隔离第三方模块验证根因
高并发下崩溃十有八九来自动态模块。禁用不是目的，验证才是关键：
- 临时注释掉所有 load_module 行，仅保留官方模块，执行 nginx -t && nginx -s reload，观察是否还崩溃
- 若恢复稳定，每次只启用一个模块，对复现路径持续压测（如 ab -n 500 -c 100 http://host/api/test），哪个模块一启用就崩，就是它
- 特别注意模块与当前环境的兼容性：Nginx ≤1.16 + OpenSSL 1.0.2、LuaJIT 版本错配、云锁/WAF 内核过滤器未适配新内核等，都是高频雷区
