signal值是判断nginx崩溃根源最可靠的线索：signal 11表示段错误（如模块不兼容、空指针），signal 9表明被系统强制杀死（如oom killer触发），signal 6多因中止信号（如waf插件冲突），需结合dmesg、ulimit及前后日志综合定位。
直接看 error_log 里的 signal 值，它是判断崩溃根源最可靠的线索。signal 后面的数字对应具体信号类型：11 是段错误（SIGSEGV），9 是被强制杀死（SIGKILL），6 是中止（SIGABRT）——不同信号指向完全不同的问题方向，不能只盯着“exited”三个字。
先确认 signal 类型再定排查路径
日志中类似这样的行：
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 已运行
Windows 下 phpEnv 场景要换思路
phpEnv 是 Windows 下的集成包，其 Nginx 编译未启用 --with-debug，且 Windows 本身不支持 Linux 风格的 core dump 机制：
- 不会生成 core 文件，ulimit -c unlimited 在 cmd/powershell 中完全无效
- 崩溃默认只产生事件查看器日志或弹窗，不会落盘 core 文件
- 真正有效的崩溃线索只来自 Windows 事件查看器（Application 日志）和 nginx.exe 日志级别
操作步骤：按下 Win + R，输入 eventvwr.msc 回车，打开事件查看器 → 导航到 Windows 日志 > 应用程序 → 筛选来源为 Application Error 或 Windows Error Reporting → 查找时间戳吻合的条目，重点看“故障模块名称”字段，例如 php7.dll、ngx_http_lua_module.dll 或 nginx.exe 本身。
