排查nginx worker崩溃须先看error_log中signal值：signal 11为段错误，signal 9为oom killer终止，signal 6为主动中止；再结合崩溃前1–3秒日志、access.log中高耗时/大请求路径、上下文错误及轻量验证精准定位根因。
直接看 error_log 中“worker process exited on signal”行末的 signal 数值，再往前翻 1–3 秒内出现频次高、响应时间长（>5s）或 body_size 异常大的 access.log 请求条目，就能快速圈定引发崩溃的高耗时路径。
抓准 signal 值对应的问题类型
signal 后面的数字是诊断起点，不同数值指向完全不同的根因方向：
- signal 11：段错误，大概率由该路径触发了非法内存操作（如空指针解引用、模块越界读写），尤其常见于上传接口、大文件解析、Lua 脚本处理长 URL 或超长 Header
- signal 9：被 OOM Killer 杀掉，说明该路径持续占用大量内存未释放（如缓存未清理、连接池堆积、SSL session cache 配置过大），需重点查其响应体大小和并发频率
- signal 6：主动中止，多见于断言失败，常发生在 WAF 插件或云锁对特定请求头/内容做深度校验时触发内部保护机制
联动 access.log 锁定可疑请求模式
单靠 error_log 无法定位具体路径，必须用 access.log 的时间戳与字段交叉比对：
- 在 signal 日志时间点前后 ±2 秒内，筛选 $request_time > 5 且 $body_bytes_sent > 10485760（即 >10MB）的请求
- 统计同一 $uri 出现次数——若某 /api/v3/report 导致 80% 的 signal 11，基本可复现
- 检查 $http_user_agent 是否集中为爬虫、扫描器或异常客户端（如含超长 X-Trace-ID、重复 Cookie）
结合崩溃前日志上下文缩小范围
error_log 中紧邻 signal 行的 warn/error 记录，往往暴露路径执行到哪一步出问题：
- 出现 open() "/path/to/cache" failed (13: Permission denied) → 路径权限错，常见于 fastdfs 模块读取 mod_fastdfs.conf 失败后崩溃
- 出现 SSL_do_handshake() failed (SSL:) SSL alert number 40 → 该 HTTPS 路径触发 OpenSSL 断言，多见于旧版 Nginx + 自签名证书组合
- 出现 recv() failed (104: Connection reset by peer) while reading response → 上游返回非法数据，被 Lua 或 proxy_pass 解析时 crash
验证路径是否真凶的轻量方法
不重启服务、不改配置，也能快速验证怀疑是否准确：
- 用 curl 对疑似路径发起单次请求：
curl -v "https://host/api/suspect?debug=1"，观察是否立即触发相同 signal - 临时在 nginx.conf 对该 location 加
return 444;，再压测，若 signal 消失，基本确认路径是诱因 - 启用 debug 日志后 grep
pool alloc.*uri=/api/suspect，看内存分配是否在该路径下激增
