看到“worker process X exited on signal 9”，基本可锁定为OOM导致的强制终止；需立即执行dmesg -T | grep -i "killed process nginx"确认内核是否触发OOM Killer，并比对时间戳与error.log中signal 9日志一致，再结合accept() failed、upstream超时、pool alloc激增等间接线索及access.log中大请求特征交叉印证。
看到 “worker process X exited on signal 9”，基本可以锁定是内存溢出（OOM）导致的强制终止——这不是 Nginx 主动报错，而是被系统内核“动手杀掉”后留下的被动痕迹。
盯住 signal 9 这个关键指纹
signal 后面的数字是诊断起点：
• signal 9 → 被 SIGKILL 终止，99% 是 OOM Killer 干的
• signal 11 → 段错误，属于代码层问题，和内存溢出无关
• signal 6 → 主动中止，多见于断言失败或模块初始化异常
只关注 signal 9 的日志行，其余信号要另走排查路径。
立刻比对 dmesg 确认 OOM 杀手出手
执行命令验证是否真被系统杀掉：
• dmesg -T | grep -i "killed process nginx"
• 或 dmesg | grep -i "out of memory"
如果输出里有类似 “Out of memory: Kill process 12345 (nginx)”，就坐实了 OOM。再把 error.log 中该 signal 9 行的时间戳，和 dmesg 输出时间对齐，确认是同一个 worker 进程。
结合 error.log 中的间接线索交叉印证
OOM 往往不是突然爆发，而是有征兆。翻看 signal 9 发生前几分钟的 error.log：
• 反复出现 “accept() failed (24: Too many open files)” → 文件句柄耗尽常与内存泄漏共存
• 大量 “upstream timed out”，但后端实际响应正常 → 内存紧张导致事件循环卡顿、超时误判
• 开启 debug 日志后，“pool alloc” 或 “http cleanup add” 日志激增 → 内存频繁分配却未及时回收
这些不是直接报内存不足，但都是内存压力正在升高的可靠信号。
联动 access.log 锁定肇事请求
单看 error.log 找不到源头，必须查 access.log：
• 在 signal 9 时间点前后 30 秒内，筛选 body_size 异常大（如 >10MB） 的请求
• 统计同一 IP 或 URI 的请求频次，确认是否存在扫描、重试或恶意构造的超大请求
• 查看 user_agent 是否异常（如空、过长、含大量不可见字符）
高频出现 “client intended to send too large body” 或 “request header or cookie too large”，说明客户端正持续发送失控请求，Nginx 缓冲区不断堆积，最终压垮内存。
