Nginx worker进程崩溃需靠core dump精准定位根因，必须同时配置worker_rlimit_core（启用dump）和working_directory（指定可写路径），缺一不可；否则无法生成含PID的core文件，导致故障归因失败。
当 Nginx 出现 worker 进程意外退出、频繁重启或直接崩溃时，仅靠 error.log 往往只能看到 worker process exited on signal 11 或 segmentation fault 这类模糊提示。真正定位根因，需要让崩溃“留下痕迹”——worker_processes 和 worker_rlimit_core 配合使用，是实现精准故障归因的关键组合。
为什么必须配对设置？
单独设 worker_processes auto 只是让进程数适配 CPU 核心，但不解决“崩了怎么查”的问题；而 worker_rlimit_core 控制是否生成 core dump 文件。若没启用，或路径不可写、权限不足、系统 ulimit -c 为 0，那再稳定的多进程架构也留不下线索。
-
worker_rlimit_core必须配合working_directory（非 root 下的可写目录）显式指定 dump 路径，否则默认写入 worker 启动目录（常为 /var/log/nginx/，但该目录通常无写权限） - 每个 worker 进程崩溃时会生成独立 core 文件，文件名含 PID，结合
ps -ef | grep nginx: worker输出，能立刻锁定是哪个进程、在处理哪类请求时出的问题 - 若未设
worker_rlimit_core，即使配置了working_directory，也不会生成 core；反之，只设worker_rlimit_core但没配working_directory，dump 会失败并报failed to open core dump file
如何验证配置已生效？
不能只靠 nginx -t 通过就认为 OK。需分三步确认：
- 检查系统级限制：
ulimit -c应大于 0（推荐设为unlimited），且/proc/sys/kernel/core_pattern指向合理路径（如/var/crash/core.%e.%p） - 确认 Nginx 配置中同时存在：
worker_rlimit_core 2G;（单位可为 k/m/g）和working_directory /var/crash;（目录需chown nginx:nginx /var/crash && chmod 755 /var/crash） - 手动触发一次崩溃测试（仅限测试环境）：
kill -SEGV $(pgrep -f "nginx: worker")，然后检查/var/crash/是否生成core.nginx.PID文件
崩溃后怎么快速分析？
拿到 core 文件后，用 gdb 结合 Nginx 二进制即可回溯调用栈：
gdb $(which nginx) /var/crash/core.nginx.12345- 进入 gdb 后执行：
bt full查看完整堆栈，重点关注最上层函数（如ngx_http_upstream_process_header或第三方模块函数名） - 若堆栈指向 Lua、GeoIP、upload 模块等第三方代码，基本可判定为模块兼容性或内存越界问题；若停在
ngx_regex_exec，则大概率是 location 正则表达式有缺陷（如回溯爆炸）
常见误配与修复建议
很多团队开了 worker_rlimit_core 却始终没抓到 core，问题往往出在细节：
- 忘记设
working_directory，或设了但目录属主不是运行用户（nginx 用户无法写入） - core 文件被 SELinux 或 AppArmor 拦截（CentOS/RHEL 上检查
ausearch -m avc -ts recent） -
worker_processes设得过高（如 32 核机器设 64），导致单个 core 文件过大、磁盘瞬间写满，后续崩溃被静默丢弃 - 生产环境误用
worker_rlimit_core unlimited，应限制大小（如2G），避免单次崩溃拖垮整机磁盘
