Nginx Master进程通过waitpid()轮询检测Worker非零退出码（如SIGSEGV=11）判定异常，随即记录日志、比对worker_processes配置值，不足则fork新Worker继承监听套接字；若1秒内异常退出≥10次，Master主动退出需人工干预；Master崩溃、Worker被SIGSTOP挂起或资源不足时均不触发拉起。
Nginx 的 Master 进程会自动感知并响应 Worker 异常退出，整个过程无需人工干预，但依赖于几个关键前提和机制。
Master 如何发现 Worker 异常退出
Master 不靠信号通知，而是通过 waitpid() 系统调用轮询子进程状态。它定期检查每个 Worker 的退出码：只有非零退出码（如 SIGSEGV=11、SIGKILL=9）才被判定为异常；而正常 reload 或优雅关闭时 Worker 返回 0，Master 会忽略拉起动作。
异常后的标准恢复动作
一旦确认异常，Master 立即执行以下操作：
- 在 error.log 中记录日志，例如："worker process 12345 exited on signal 11"
- 比对当前活跃 Worker 数量与配置中 worker_processes 的值
- 若数量不足，立刻 fork 新进程，新 Worker 继承原有监听 socket 和全部配置
- 新 Worker 启动后直接进入事件循环，服务无中断
内置保护机制：防止雪崩式崩溃
为避免因严重缺陷导致无限重启，Nginx 设有硬编码熔断策略：
- Master 会统计最近 1 秒内 Worker 异常退出次数
- 若 ≥ 10 次，Master 主动退出，并在日志中留下提示："exit after too many worker processes exit unexpectedly"
- 此时整个 Nginx 停止，必须人工介入排查（常见原因包括配置语法错误、模块冲突、内存越界）
哪些情况 Master 不会拉起新 Worker
自动恢复只覆盖特定场景，以下情况不触发拉起逻辑：
- Master 自身崩溃或被 kill -9 终止——整个实例消失，无进程可执行恢复
- Worker 被 SIGSTOP 挂起（仍存活但不工作），Master 不认为其已退出
- 系统资源不足（如 PID 耗尽、内存不足、文件描述符超限），导致 fork 失败
- nginx.conf 存在语法错误或关键路径不可读（如 ssl_certificate 文件缺失），新 Worker 启动失败
