段错误（signal 11）是Nginx因模块非法内存访问导致worker进程崩溃的严重问题，需通过日志确认信号类型、检查core dump、隔离第三方模块、用gdb分析堆栈定位根因，并分层缓解。
模块段错误（Segmentation Fault）是 Nginx 运行中最危险的崩溃类型之一，本质是某个模块在 C 层非法访问了内存地址，导致 worker 进程被系统强制终止（signal 11）。它不报配置错误，也不留明显痕迹，但会直接中断服务。处理核心不是“修模块”，而是“快速定位 + 隔离验证 + 现场捕获”。
确认确实是模块引发的段错误
别只看 worker process exited on signal 11 这一行日志。重点看三处：
-
error_log 中 signal 后的数字：必须是
signal 11才是段错误；signal 9是 OOM Killer 杀的，signal 6多是断言失败，和模块初始化有关但不是内存越界 -
是否带 core dumped：有括号说明系统已尝试保存崩溃现场，后续可用 gdb 分析；没有则需先开启 core dump（
ulimit -c unlimited并配置working_directory） -
前 1–3 秒的上下文日志：比如出现
open() "/etc/nginx/mod_fastdfs.conf" failed (2: No such file)，说明 fastdfs 模块因配置缺失而初始化失败，极可能触发后续段错误
快速隔离可疑第三方模块
绝大多数段错误来自第三方模块（如 ngx_lua、fastdfs-nginx-module、云锁内核过滤器），官方核心模块极少出这类问题。不要逐个删代码，用最小化验证法：
- 临时注释掉所有
load_module行，只保留 Nginx 自带模块，执行nginx -t && nginx -s reload，观察 signal 11 是否消失 - 若恢复稳定，每次只启用一个可疑模块，对相同请求路径压测（例如
ab -n 500 -c 20 http://host/api/upload），哪个模块一启用就复现，就是它 - 特别注意动态加载模块与当前 Nginx 版本、OpenSSL 版本的兼容性——例如 Nginx ≤1.16 + OpenSSL 1.0.2 组合下，SSL 握手失败（
SSL_do_handshake() failed）容易触发 OpenSSL 内部断言，表现为 signal 11
获取并分析崩溃现场
光靠日志无法定位具体哪行代码越界，必须依赖 core dump：
- 确保已开启 core dump：
ulimit -c unlimited，并在nginx.conf的 main 块中设置working_directory /var/coredump;（路径需存在且 nginx 用户可写） - 用 gdb 加载 core 文件：
gdb $(which nginx) /var/coredump/core.xxx，然后执行bt full查看完整堆栈，重点关注 third-party 模块函数调用链 - 若堆栈显示在
ngx_http_lua_*或fastdfs_*函数内崩溃，基本可锁定模块；若出现在SSL_do_handshake或CRYPTO_add_lock，大概率是 OpenSSL 层兼容问题
临时缓解与长期规避
线上不能停机等修复，要分层应对：
- 紧急时可禁用问题模块，改用纯静态响应或 upstream 直连绕过该模块逻辑
- 升级模块前务必在测试环境验证：Nginx 主版本、OpenSSL 小版本、模块自身 release note 三者都要对齐
- 避免在生产环境使用未经广泛验证的 dev 分支模块；对 Lua 模块尤其注意
lua_code_cache off在调试期易暴露内存问题，上线必须关
