核心思路是“捕获现场 + 定位肇事代码”：先确认error_log中signal 11和(core dumped)，再查ulimit -c与core_pattern定位core文件，用gdb bt分析调用栈，结合崩溃前1–3秒日志（如mod_fastdfs.conf缺失）及模块隔离验证根因。
遇到 Nginx worker 进程因 SIGSEGV（信号 11）异常退出，核心思路是“捕获现场 + 定位肇事代码”，不能只看日志里那句 exited on signal 11。真正有用的线索藏在 core dump 文件和它前后几秒的日志中。
确认确实是段错误，并检查 core 是否已生成
先翻 error.log，找到类似这行：
2026/09/16 08:42:11 [alert] 12345#0: worker process 67890 exited on signal 11 (core dumped)重点看两点：
- signal 11：确认是段错误，不是 signal 9（OOM 杀死）或 signal 6（主动 abort）
- (core dumped)：说明系统尝试保存了内存快照——但不等于你一定能拿到文件，得验证是否真写进磁盘了
Linux 下定位 core 文件并用 gdb 分析
默认 core 可能被禁用或存到奇怪位置，分三步走：
- 查限制：
ulimit -c，若为 0，需提前设成unlimited（加到 systemd service 的LimitCORE=infinity或启动脚本里） - 查路径：
cat /proc/sys/kernel/core_pattern，常见值有：
•core→ 在 worker 启动目录（通常是/usr/local/nginx或/etc/nginx）
•|/usr/lib/systemd/systemd-coredump %P...→ 实际文件在/var/lib/systemd/coredump/，后缀带 .xz - 用 gdb 打开：
gdb $(which nginx) /path/to/core.xxx，进 gdb 后输bt看完整调用栈，重点关注最上面几层函数名（比如ngx_http_lua_module、fastdfs_、SSL_do_handshake）
Windows 下别找 core，盯紧事件查看器
Windows 不生成传统 core 文件，崩溃线索全在系统日志里：
- 按
Win + R，输入eventvwr.msc打开事件查看器 - 左侧导航到 Windows 日志 → 应用程序
- 筛选来源为
Application Error或Windows Error Reporting，时间点要和 nginx.log 中的退出时间一致 - 重点看字段：
• 故障模块名称（如php7.dll、ngx_http_lua_module.dll、nginx.exe）
• 异常代码（如0xc0000005就是访问违规，等价于 SIGSEGV）
结合上下文缩小范围，快速隔离问题模块
单靠 core 或栈帧还不够，必须往前翻 error.log 的 1–3 秒日志：
- 如果 signal 11 前有
open() "/etc/nginx/mod_fastdfs.conf" failed (2: No such file)，八成是 fastdfs 模块初始化失败引发后续崩溃 - 如果总在特定请求路径（如
/api/upload）或超长 header 后出现，可复现压测，再用gdb --pid附加运行中 worker 捕获实时状态 - 临时注释掉所有
load_module行，只留官方模块，reload 测试；再逐个启用可疑模块，确认哪个一上就崩
