Nginx Worker异常退出分析与解决

Nginx worker进程频繁异常退出通常由systemd资源限制、信号处理不匹配、模块冲突或OOM Killer干预等多层因素导致，需结合journalctl日志、systemctl show配置检查、unit文件修正及模块隔离排查。

当 Nginx 通过 systemctl 启动后，worker 进程频繁异常退出，通常不是单纯配置错误导致，而是涉及权限、资源限制、信号处理或 systemd 单元配置等多层因素。需结合日志、进程状态和 unit 文件综合判断。

检查 systemd 日志定位直接原因

worker 异常退出时，systemd 通常会记录退出码和信号信息，这是最直接的线索：

• 运行 journalctl -u nginx -n 100 -f 实时查看最新日志，重点关注含 exited、killed、signal 或 core dumped 的行
• 若出现 exit code=exited, status=139，大概率是段错误（SIGSEGV），可能由模块冲突、内存损坏或第三方模块 bug 引起
• 若显示 killed by signal SIGKILL (9)，说明被外部强制终止，常见于 OOM Killer 干预或 systemctl kill 操作

验证 worker 是否受 systemd 资源限制影响

systemd 默认对服务施加隐式资源约束，可能触发 worker 主动退出或被系统终止：

• 检查是否启用了 MemoryLimit、TasksMax 或 LimitNOFILE 等限制：运行 systemctl show nginx | grep -E "(Memory|Tasks|NOFILE|OOM)"
• Nginx worker 大量连接时易触达 LimitNOFILE 上限，导致 accept() 失败并可能引发 worker 崩溃；建议在 /etc/systemd/system/nginx.service.d/override.conf 中显式调高：
  [Service]
LimitNOFILE=65536
• 若服务器内存紧张且未禁用 OOM Killer，可临时添加 OOMScoreAdjust=-1000 降低被杀优先级（仅调试用）

确认 master/worker 信号处理与 systemd 生命周期匹配

Nginx 默认依赖 SIGHUP 重载、SIGQUIT 优雅退出，但 systemd 的 stop 流程可能发送不兼容信号：

• 默认 unit 文件中若未设置 Type=forking 或未正确定义 PIDFile，systemd 可能误判主进程状态，导致反复启动/终止 worker
• 检查 /usr/lib/systemd/system/nginx.service 或自定义 unit 文件：确保 Type=forking 且 PIDFile=/run/nginx.pid 存在且路径一致
• 避免在 ExecStartPre 中执行阻塞操作（如长时脚本），否则 systemd 可能超时后发送 SIGTERM 终止尚未完成 fork 的 master 进程

排查常见诱因：模块、配置与运行时环境

排除 systemd 层面问题后，聚焦 Nginx 自身运行上下文：

• 禁用所有第三方模块（如 lua-nginx-module、headers-more），仅保留核心功能，观察是否仍异常退出；逐步启用定位问题模块
• 检查 worker_rlimit_core 和 working_directory 配置：若 core dump 被启用但目标目录不可写或磁盘满，可能导致 worker 启动失败或崩溃
• 运行 nginx -t 验证语法，再用 nginx -T 输出完整生效配置，确认无重复 pid、error_log 权限冲突（如日志目录属主非 nginx 用户）
• 检查系统时间是否突变（如 NTP 调整），部分旧版 Nginx 在 time warp 场景下可能触发 timer 相关 crash