Nginx 多进程模型的稳定性源于主从分工明确、故障边界清晰、恢复动作迅速三重机制：主进程仅调度不处理请求，worker 进程彼此隔离独立运行，崩溃后毫秒级自动拉起，热重载支持语法校验与错误回退。
Nginx 多进程模型不是靠“不出错”来维持稳定，而是靠“出错了也不影响服务”来保障可用性。它的稳定性不来自单个组件的完美，而来自主从分工明确、故障边界清晰、恢复动作迅速这三重机制。
主进程只管调度，不碰请求
主进程以 root 权限启动，但只做极少量关键操作：校验配置语法、绑定监听端口、fork 工作进程、响应信号（如 HUP、USR2、QUIT）。它不处理任何网络连接、不解析 HTTP、不读磁盘文件、不执行 Lua 脚本。代码路径短、逻辑简单、几乎不会崩溃。即使异常退出，重启开销极小，且正在运行的工作进程完全不受干扰。
工作进程彼此独立，内存不共享
每个 worker 进程是操作系统级独立进程，拥有专属的虚拟内存空间、文件描述符、连接队列、定时器和缓存索引。这意味着：
- 一个 worker 因正则回溯、后端超时或第三方模块 bug 崩溃，仅终止自身，其他 worker 继续正常服务
- 连接一旦被某个 worker 接收，后续整个生命周期都在该进程内闭环完成，不跨进程传递 socket
- 限流（limit_req）、缓存淘汰、连接超时等逻辑全部在单进程内自治，无需加锁协调
崩溃后毫秒级自动拉起
主进程持续通过 waitpid 监听 SIGCHLD 信号，一旦发现 worker 异常退出（如段错误、OOM 被杀），立即 fork 新进程补位。整个过程通常在几毫秒内完成，用户请求基本无感知。日志中仅记录类似 “worker process 12345 exited on signal 11”，不触发全局中断。
热重载与错误回退机制提供双重容错
执行 nginx -s reload 时：
- 主进程先校验新配置语法是否合法，非法则拒绝加载，旧 worker 继续运行
- 校验通过后，启动新 worker，并通知旧 worker 优雅退出（不再接受新连接，但处理完已有请求）
- 若新 worker 启动失败或新配置引发问题，主进程可随时中止加载，系统保持原状
这种设计让配置变更本身也成为一次受控、可逆、零中断的操作。
