最可靠线索是error_log中signal值：11为段错误（内存非法操作），9为OOM Killer强制终止，6为中止；需结合dmesg、ulimit、配置验证及core dump定位根因。

直接看 error_log 里的 signal 值，它是判断崩溃根源最可靠的线索。signal 后面的数字对应具体信号类型，比如 11 是段错误（SIGSEGV），9 是被强制杀死（SIGKILL），6 是中止（SIGABRT）——不同信号指向完全不同的问题方向，不能只盯着“exited”三个字。

从 signal 数值反推根本原因

error_log 中类似这样的行：

2026/04/30 08:20:15 [alert] 12345#0: worker process 67890 exited on signal 11 (core dumped)

关键不是“exited”，而是 signal 11。它说明进程执行了非法内存操作，常见于：

• 第三方模块（如 fastdfs-nginx-module、云锁内核过滤器）与当前 Nginx 版本不兼容
• C 扩展传参越界、空指针解引用、use-after-free 等底层错误
• SSL 配置不当触发 OpenSSL 内部断言失败（尤其在旧版 Nginx 中）

而 signal 9 则基本可排除代码 bug，应立刻转向系统级排查：

• 运行 dmesg -T | grep -i "killed process" 查 OOM Killer 记录
• 检查 systemctl show nginx | grep MemoryLimit 是否设了过低的 memory limit
• 确认容器或 cgroup 中 /sys/fs/cgroup/memory/memory.stat 的 total_rss 是否逼近上限

结合日志上下文定位触发点

单独一行 signal 日志信息有限，必须往前翻 1–3 秒内的其他 warn/error 记录：

• 如果 signal 11 前紧跟着 open() "/path/to/file" failed (13: Permission denied)，大概率是用户权限或 SELinux 限制导致模块初始化失败
• 如果 signal 9 前出现大量 accept() failed (24: Too many open files)，说明触及了 LimitNOFILE 或 ulimit 限制，worker 主动退出或被 systemd 杀掉
• 若 signal 6 出现在安装云锁、WAF 类插件后，且伴随加载缓慢、图片缺失，重点查其内核层配置（如 FilterKernel.xml）是否与 Nginx 内存模型冲突

验证配置改动是否生效

很多崩溃源于配置未真正加载或路径错位。仅靠 error_log 不足以确认配置状态，需交叉验证：

• 用 nginx -t 检查语法，但注意：它不校验模块逻辑或路径是否存在
• 用 nginx -T 输出全部生效配置，确认 user、pid、include 路径是否如预期，特别是 fastdfs 模块依赖的 mod_fastdfs.conf 是否被正确 include
• 检查模块所需服务是否已启动：例如 signal 11 报错含 ngx_http_fastdfs_process_init，必须确保 fdfs_trackerd 和 fdfs_storaged 已运行

启用 core dump 辅助深挖（仅 signal 11/6 等）

当怀疑是段错误或中止时，开启 core dump 能拿到调用栈，比日志更直接：

• 临时设置：ulimit -c unlimited，并写入 echo '/tmp/core.%e.%p' > /proc/sys/kernel/core_pattern
• 复现崩溃后，用 gdb $(which nginx) /tmp/core.nginx.PID 进入调试，执行 bt 查看崩溃位置
• 若栈帧落在某个第三方模块（如 ngx_http_fastdfs_module 或云锁 so 文件），基本可锁定问题来源