signal 11 表示段错误（sigsegv），源于非法内存访问，常见于第三方模块不兼容、空指针解引用、ssl 配置触发 openssl 断言或 lua 模块 c api 调用异常；需结合前序 error/warn 日志、模块隔离测试及 core dump 的 gdb 回溯精准定位。
直接看 error_log 中的 signal 值，它是判断段错误（SIGSEGV）最核心的依据。出现 worker process exited on signal 11 就意味着 Nginx worker 在处理请求过程中发生了非法内存访问——不是配置写错，而是运行时崩溃，必须立刻响应。
从 signal 11 日志定位段错误源头
典型日志行如下：
2026/05/11 21:32:47 [alert] 12345#0: worker process 67890 exited on signal 11 (core dumped)
关键不是 “exited”，而是 signal 11。它说明进程在执行某段 C 代码时访问了非法地址，常见原因包括：
- 第三方模块（如
fastdfs-nginx-module、云锁内核过滤器）与当前 Nginx 版本 ABI 不兼容 - 模块中存在空指针解引用、数组越界、use-after-free 等底层 C 错误
- SSL 配置触发 OpenSSL 内部断言失败（尤其在 Nginx ≤ 1.16 + OpenSSL 1.0.2 组合下）
- 自定义 Lua 模块（via ngx_lua）调用 C API 时传参异常或未检查返回值
结合上下文缩小触发范围
单独一行 signal 11 信息有限，必须往前翻 1–3 秒内 的 warn/error 记录，找紧邻的线索：
- 若前有
open() "/path/to/mod_fastdfs.conf" failed (2: No such file)，说明 fastdfs 模块初始化失败，极可能引发后续段错误 - 若前有
recv() failed (104: Connection reset by peer) while reading response header from upstream，需排查是否后端返回异常二进制数据被模块误解析 - 若 signal 11 总在特定 URL（如
/upload）或特定 Header（如含超长X-Trace-ID）后出现，基本可复现并用于 gdb 调试
验证与隔离模块问题
段错误多由模块引入，需快速验证是否为“某个模块”导致：
- 临时注释掉所有
load_module行，仅保留官方核心模块，nginx -t && nginx -s reload，观察 signal 11 是否消失 - 逐个启用第三方模块（每次只开一个），每启用一次就压测相同请求路径，定位肇事模块
- 对可疑模块，检查其编译时 Nginx 版本（
nginx -v）与运行时是否一致；不一致必须重新编译 - 若使用云锁、安全狗等内核级 WAF，检查其
FilterKernel.xml是否启用了与 Nginx 内存模型冲突的过滤规则
启用 core dump 辅助根因分析
仅靠日志无法看到崩溃现场，需捕获 core 文件供 gdb 分析：
- 确保系统允许生成 core：
ulimit -c unlimited，并在 systemd service 文件中添加LimitCORE=infinity - Nginx 配置中设置
working_directory /var/tmp;，并确认该目录对 worker 用户（如www-data）可写 - 复现问题后，用
gdb $(which nginx) /var/tmp/core.*打开 core，执行bt full查看完整调用栈，重点关注最顶层非 Nginx 官方模块的函数名 - 若调用栈中出现
ngx_http_fastdfs_process_init或cloudlock_filter_handler等字样，即可 100% 锁定模块
