Nginx主进程（Master）不处理请求，仅负责配置校验、监听套接字创建、Worker进程派生与监管、信号响应及日志统一写入；其以root权限运行，通过共享内存、信号和文件锁与Worker协作，实现“以静制动、以少控多”的事件驱动管理。
Nginx 主进程（Master Process）不直接处理客户端请求，而是负责全局管理、信号响应、工作进程（Worker）调度与生命周期控制，其核心是“以静制动、以少控多”的事件驱动管理模式。
Master 进程的核心职责
Master 是 Nginx 启动后首个进程，以 root 权限运行（便于绑定 80/443 等特权端口），主要做以下几件事：
-
读取并校验配置文件：启动时解析 nginx.conf，检查语法和逻辑有效性；热重载（
nginx -s reload）时也由 Master 完成新配置加载与验证 - 创建监听套接字（listen sockets）：在 fork Worker 前，Master 就已完成 socket 创建、bind 和 listen，所有 Worker 进程后续通过继承或共享方式获取这些套接字
-
派生并监管 Worker 进程：按
worker_processes指令数量 fork 子进程；通过信号（如 SIGCHLD）监听 Worker 异常退出，并自动拉起新进程保持数量稳定 - 接收外部信号并协调全局行为：如 SIGHUP（重载配置）、SIGUSR2（平滑升级二进制）、SIGQUIT（优雅退出）、SIGTERM（快速退出）等，均由 Master 解析后统一决策并通知 Worker
Master 与 Worker 的协作机制
Worker 进程以非特权用户（如 nobody 或 www-data）运行，真正处理网络 I/O 和 HTTP 请求。Master 不参与具体业务，只维持“管理者”角色：
- Worker 启动后，通过 共享内存 + 信号 + 文件锁 与 Master 保持轻量通信，避免频繁系统调用
- 连接分发采用 惊群（Thundering Herd）规避策略：默认开启
accept_mutex on，由 Master 协调各 Worker 轮流获取新连接，防止多个 Worker 同时被唤醒争抢 accept - 日志写入由 Master 统一接管：Worker 将日志内容写入 pipe 或共享内存，由 Master 进程落地到磁盘，降低 I/O 竞争和磁盘刷写压力
Master 的运行状态与可观测性
可通过系统命令和 Nginx 自身指令观察 Master 行为：
- 查看进程树：
ps -ef | grep nginx，通常可见一个 master 进程 + 多个 worker 进程（可能还有 cache manager / loader 进程） - 确认配置加载状态：
nginx -t验证配置，kill -s USR1 `cat /var/run/nginx.pid`可触发日志 reopen（由 Master 负责重新打开 access/error 日志文件） - 热重载本质是 Master 启动新 Worker、逐步关闭旧 Worker：旧 Worker 处理完已有连接后退出，新 Worker 接管新连接，实现零中断服务
常见误区与注意事项
理解 Master 机制时需避开几个典型误解：
- Master 不处理请求，也不参与 epoll/kqueue 事件循环 —— 所有网络事件均由 Worker 独立监听和响应
- Master 不做负载均衡决策：连接分配靠内核 SO_REUSEPORT（现代内核）或 Nginx 自身 accept_mutex，而非 Master 主动分发
- 配置中
worker_processes auto是由 Master 在启动时读取 CPU 核心数并 fork 对应数量 Worker，不是运行时动态伸缩 - 若 Master 异常终止（如被 kill -9），所有 Worker 会收到 SIGTERM 并退出 —— 因此 Master 是整个 Nginx 实例的单点依赖，但本身极轻量、极少崩溃
