Nginx worker崩溃时默认不生成core dump或堆栈，需配置ulimit、core_pattern、--with-debug及error_log debug，并配合gdb或systemd-coredump分析。
Nginx 的 worker 进程在接收到某些异常信号（如 SIGSEGV、SIGABRT、SIGFPE 等）时，默认不会自动打印堆栈信息，也不会生成 core dump，因此排查崩溃类问题往往缺乏直接线索。要获取崩溃时的调用栈，需主动配置系统与 Nginx 本身的行为。
启用 core dump 并确保可捕获
worker 进程崩溃时，只有生成有效的 core 文件，才能用 gdb 分析堆栈。但默认情况下，Linux 对非 root 进程、或受限制的容器环境会禁用 core dump。
- 检查并提升 core 文件大小限制：
ulimit -c unlimited（需在启动 Nginx 前执行，或写入 systemd service 的LimitCORE=infinity） - 设置 core 文件保存路径和命名格式，例如在
/etc/sysctl.conf中添加：kernel.core_pattern = /var/log/nginx/core.%e.%p.%t - 确保目标目录存在、有写权限，且文件系统未挂载为
noexec或nosuid
让 Nginx 在信号处理中触发堆栈输出
Nginx 自身不内置崩溃时的堆栈打印功能，但可通过以下方式增强可观测性：
CodiumAI
AI代码测试工具，在IDE中获得重要的测试建议
下载
- 编译时开启调试支持：
--with-debug，并确保链接了libbacktrace（较新版本 GCC 自带），部分定制 build 可在SIGSEGV处理器中插入简易 backtrace 输出（需修改源码src/os/unix/ngx_process.c中的ngx_signal_handler） - 使用
gdb --pid $(pgrep nginx)附加运行中 worker，在复现问题前设断点或捕获信号：handle SIGSEGV stop print - 配合
systemd-coredump（若使用 systemd）：启用后，崩溃时自动收集 core + 元数据，运行coredumpctl info nginx即可查看简要堆栈
通过日志与信号调试辅助定位
即使没有 core，Nginx error log 仍可能提供关键上下文：
- 确保
error_log /var/log/nginx/error.log debug;已开启（debug 级别会记录进程信号接收、模块初始化、事件循环状态等） - 注意日志中类似
signal 11 (SIGSEGV) received或abort() called的行，结合时间戳与 worker PID 定位对应 core 文件 - 若使用第三方模块（如 Lua、njs、动态共享库），优先检查其是否触发非法内存访问；可临时禁用模块验证是否为根本原因
验证与快速复现技巧
为确认配置生效并稳定捕获堆栈，建议做最小闭环验证：
- 写一个故意崩溃的 location（仅测试环境！）：
location /crash { return 500; add_header X-Crash "yes"; # 然后用 Lua 模块调用 ngx.exit(0) 后再访问非法指针 } - 用
kill -SEGV $(pgrep -f "nginx: worker")主动发送信号，观察是否生成 core 并被正确捕获 - 用
gdb /usr/sbin/nginx /var/log/nginx/core.nginx.* -ex "bt full" -ex quit批量提取堆栈