nginx master进程不处理请求，仅通过信号、预分配监听套接字和轻量共享内存协调worker：启动时校验配置与端口，fork worker后由其独立处理连接；sighup触发双轨热更新，sigchld自动拉起崩溃worker，零共享、无锁、高隔离。
Nginx 的 Master 进程本身不处理请求，而是通过轻量、确定性的机制协调多个 Worker 进程——核心在于“不共享、少通信、靠信号、预分配”。它不介入具体连接处理，只确保 Worker 启动正确、运行稳定、配置更新平滑、故障快速恢复。
配置解析与监听端口预检
Master 在启动阶段完整读取 nginx.conf，提取所有 listen 指令（如 listen 80、listen 443 ssl、listen [::]:8000），生成统一的监听地址列表。它会提前验证：端口是否被占用、当前用户是否有权绑定（尤其对 80/443 等低端口）、IP 地址是否合法、SO_REUSEPORT 是否可用。若任一校验失败，Master 直接报错退出，避免 Worker 启动后分散失败。
进程创建与配置分发
Master 根据 worker_processes 指令 fork 出指定数量的 Worker 进程。它不传递复杂数据，而是通过以下方式同步关键信息：
- 将监听地址列表、socket 选项（如 SO_REUSEADDR、SO_REUSEPORT）等元数据写入共享内存区域
- 向每个 Worker 发送初始化信号（如 SIGUSR1），触发其读取共享配置并执行 socket/bind/listen
- Worker 启动后即脱离 Master 环境，各自持有独立的监听套接字副本
运行期信号驱动协同
Master 与 Worker 之间几乎不持续通信，全部依赖标准 Unix 信号实现异步控制：
-
SIGHUP：收到重载命令（
nginx -s reload）时，Master 解析新配置，fork 新 Worker，并向旧 Worker 发送 SIGQUIT - SIGQUIT：旧 Worker 收到后停止接受新连接，处理完已有请求后自行退出
- SIGCHLD：Worker 异常退出时，Master 捕获该信号，立即 fork 新进程补位
- SIGTERM/SIGINT：通知所有 Worker 优雅终止
惊群控制与负载均衡保障
多个 Worker 共享同一端口时，Master 不参与 accept 决策，但通过默认启用的 accept_mutex on 配合内核机制（如 SO_REUSEPORT）实现协作：
- accept_mutex 确保任意时刻最多一个 Worker 尝试 accept 新连接，避免“惊群”浪费 CPU
- 启用 multi_accept on 后，单次事件循环中 Worker 可批量 accept 多个就绪连接，提升吞吐
- CPU 亲和性（worker_cpu_affinity）由 Master 在 fork 前设置，让每个 Worker 绑定专属核心，减少调度抖动
整个过程没有锁、不传大数据、不依赖复杂 IPC，靠操作系统信号和简单共享内存完成解耦协作。这种设计让 Master 极轻量（内存几十 KB，CPU 几乎为零），Worker 完全独立高并发，故障彼此隔离，是 Nginx 高可靠与高性能的底层基础。
