最可靠线索是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 文件），基本可锁定问题来源
