Nginx采用Master-Worker多进程模型：Master统一接收信号、预创建监听套接字、管理Worker生命周期及共享内存；Worker继承socket、独立处理连接、通过socketpair与信号同Master通信，不直接响应外部操作。
Worker 进程不直接响应外部操作，所有管理动作都由 Master 统一接收、解析并分发——这是 Nginx 多进程协作的核心逻辑。
Master 是唯一信号入口，Worker 不处理信号
管理员执行 nginx -s reload 或 kill -HUP $(cat /var/run/nginx.pid)，信号只发送给 Master 进程。Worker 进程对这些信号无响应能力，也不会自行加载新配置或关闭日志。Master 收到 HUP 后，才启动新 Worker 并逐步关停旧 Worker；收到 USR1 后，才通知所有 Worker 重新打开日志文件。
监听套接字由 Master 预创建，Worker 继承复用
Master 在 fork 前已调用 bind() 和 listen() 完成端口绑定（如 80/443），并将监听 socket 文件描述符传递给每个 Worker。Worker 启动后无需重复绑定，直接在该 fd 上调用 accept()。这种设计避免了端口冲突，也支撑了多 Worker 共享同一地址的可行性。
- 默认启用
accept_mutex on，防止多个 Worker 同时阻塞在同一个accept()调用上（即“惊群”） - 内核级支持（如 Linux 的
SO_REUSEPORT）可进一步分担连接分发压力 - Worker 之间不共享连接状态，每个连接完全由单个 Worker 独立处理到底
进程间通信靠 socketpair + 信号组合实现
Master 与 Worker 之间建立一对 Unix 域套接字（socketpair()），用于可靠、低开销的指令下发（如重载配置参数、更新限流阈值）。而 Worker 的状态上报则依赖操作系统信号：
- Worker 异常退出时，内核自动向 Master 发送
SIGCHLD - Master 在主循环中捕获该信号，调用
ngx_reap_children()清理僵尸进程，并立即 fork 新 Worker 补位 - Worker 正常退出（如 QUIT 指令）时，也会触发 SIGCHLD，但 Master 会跳过重启逻辑
共享内存用于跨进程状态协同，而非数据传输
Worker 之间不直接通信，但可通过 Master 创建的共享内存段（如 zone 指令定义的区域）读写公共状态：
- 限流模块使用原子计数器统计请求频次，各 Worker 并发更新无需加锁
- 缓存索引、SSL 会话复用信息等也存放于共享内存，由 cache loader 初始化、cache manager 维护
- Master 不参与具体业务逻辑，但负责分配、映射和保护这块内存区域
