Nginx 的稳定性源于故障隔离与自动恢复而非零崩溃。主进程仅校验配置、绑定端口、fork/监控 worker，不处理请求；worker 进程相互独立，崩溃互不影响；主进程秒级重启异常 worker；热重载失败不传播；支持 core dump 快速定位根因。
Nginx 的多进程架构不是靠“不出错”来保障稳定性，而是靠“出错了也不影响整体服务”来实现真正的稳定。它的核心逻辑是职责分离、故障隔离和自动恢复，而不是追求单个进程永不崩溃。
主进程只管调度，不碰请求
主进程以 root 权限运行，但只做三件事：校验配置语法、绑定监听端口、fork 和监控工作进程。它不接收连接、不解析 HTTP、不读文件、不处理 SSL。代码路径极短，几乎不会崩溃；即使异常退出，重启开销也极小，且正在运行的 worker 进程不受影响。
工作进程彼此独立，互不拖累
每个 worker 是一个完整的 OS 进程，拥有自己的内存空间、文件描述符、连接队列和定时器。这意味着：
- 某个 worker 因正则回溯、Lua 脚本错误或 upstream 响应超时而卡死或崩溃，其他 worker 仍正常响应新请求和已有连接
- 一个 worker 处理慢请求或大文件下载，不会阻塞其他 worker 接收新连接
- 内存泄漏、CPU 打满、OOM 被杀，都只局限在单个进程内，不会污染全局状态
崩溃后秒级自愈，用户无感
主进程持续监听 worker 的退出信号（如 SIGCHLD）。一旦发现 worker 异常终止（比如 exit code 非 0 或收到 SIGSEGV），会立即 fork 一个新 worker 替代。旧 worker 仍在处理的连接不受影响，新连接由新 worker 或其他存活 worker 接收。整个过程毫秒级完成，客户端通常感知不到。
热重载不中断服务，配置错误也不滚雪球
执行 nginx -s reload 时，主进程先校验新配置——若语法错误，直接拒绝加载，旧 worker 继续运行；若校验通过，则启动新 worker，再通知旧 worker 优雅退出（不再接受新连接，处理完已有请求后自行结束）。整个过程零连接中断，且失败不传播。
可配置崩溃诊断，便于快速定位根因
通过 worker_rlimit_core 启用 core dump，并配合 working_directory 指定转储路径，能让每次 worker 崩溃生成独立的 core 文件。结合调试符号，可精准定位是哪个模块、哪类请求触发了问题，而不是靠猜或日志大海捞针。
