Nginx Worker 进程异常退出时，Master 进程会自动 fork 新进程补足数量；它通过 waitpid() 监听子进程状态，记录错误日志并检查数量，不足则新建 Worker。Master 崩溃、Worker 被 SIGSTOP 挂起等场景不触发恢复。
Nginx 的 Worker 进程本身没有内置的自动拉起机制。当某个 Worker 异常退出（如段错误、被 kill -9、OOM Kill 等），Nginx Master 进程会感知到，并主动 fork 新的 Worker 进程补足配置中指定的数量——这是 Nginx 原生具备的健壮性设计，不是“外部监控拉起”，而是 Master 进程内部自动完成的恢复动作。
Worker 异常退出时 Master 的响应逻辑
Master 进程通过 waitpid() 监听子进程状态。一旦发现某个 Worker 以非 0 状态退出（即异常终止），它会立即执行以下操作：
- 记录 error log，例如："worker process XXX exited on signal 11 (SIGSEGV)"
- 检查当前活跃 Worker 数量是否低于 worker_processes 配置值
- 若不足，则调用 fork() 创建新 Worker，继承相同配置与监听套接字
- 新 Worker 启动后进入事件循环，服务无缝延续
哪些情况不会触发自动恢复？
自动恢复只针对 Worker 进程退出，不覆盖以下场景：
- Master 进程自身崩溃或被终止：整个 Nginx 实例停止，无任何进程能执行拉起逻辑
- Worker 被 SIGSTOP 挂起（非退出）：进程仍存在但不工作，Master 不认为其失效，也不会替换
- 配置为 worker_processes auto 且系统 CPU 数变化：仅在启动或重载时重新计算，运行中不动态调整 Worker 数量
如何确认自动恢复是否生效？
可通过组合方式验证机制是否正常工作：
- 查看 error.log 中是否有 "worker process ... exited" 及紧随其后的 "start worker processes" 或类似日志
- 使用
ps -ef | grep nginx观察 Worker PID 变化：杀掉一个 Worker 后，几秒内应出现新 PID - 配合
kill -SEGV $(pgrep -f "nginx: worker")主动触发段错误（仅测试环境），观察日志与进程行为
需要额外守护的边界情况
虽然 Worker 自恢复能力强，但生产中建议补充以下防护：
- 用 systemd 或 supervisord 管理 Master 进程本身，确保 Master 意外退出后能重启整个 Nginx
- 配置 worker_rlimit_core 和 working_directory，便于异常时生成 core dump 分析根因
- 启用 daemon off（仅调试）或确保日志实时刷盘，避免关键错误信息丢失
