nginx master进程不直接共享配置，而是通过启动时加载、校验并固化配置，再由worker进程fork继承内存映像（含配置与监听socket）来保证一致性；配置变更必须经master重载触发新worker启动与旧worker优雅退出。
Nginx 的 Master Process 本身不直接“共享配置”给 Worker 进程，而是通过启动前加载、验证并固化配置，再由 Worker 进程继承执行上下文的方式实现配置的一致性与隔离。它不靠运行时动态同步，而靠“一次加载、多进程继承”的设计保证所有 Worker 行为统一。
Master 在启动阶段完成配置加载与分发
Master 进程在启动或热重载（nginx -s reload）时，会完整读取、解析并校验 nginx.conf 及所有 include 文件。只有全部通过语法和逻辑检查后，才进入后续流程：
- 将最终生效的配置结构体（如
ngx_conf_t）固化到内存中 - 创建监听套接字（bind + listen），此时已应用
listen 80 ssl http2;等配置项 - 调用
fork()派生 Worker 进程 —— 子进程自动继承父进程的内存映像，包括已解析的配置数据和监听 socket
Worker 进程继承配置但不修改
每个 Worker 启动后，直接使用从 Master 继承来的配置副本，不再重新读文件或请求 Master 同步：
- 配置参数（如
worker_connections、keepalive_timeout）在初始化时被读取并设为只读变量 - HTTP 模块的指令（如
location块匹配逻辑、proxy_pass 路由规则）编译为状态机或哈希表，固化在 Worker 地址空间内 - Worker 无法自行修改配置；任何变更必须经 Master 重载，触发新 Worker 启动+旧 Worker 退出
共享内存用于运行时状态，不是配置同步通道
Master 和 Worker 之间确实使用共享内存（shm），但它承载的是**运行时状态数据**，而非配置本身：
- 例如：
limit_req_zone使用的计数器、ssl_session_cache缓存、连接统计（active、reading、writing 数值） - 这些区域由 Master 分配，Worker 通过原子操作读写，实现跨进程状态可见性
- 配置中的
zone名称（如limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;）仅在 Master 初始化阶段注册，Worker 按名称查找对应共享内存段
配置变更必须走 Master 主导的重载流程
没有运行时 API 或 IPC 接口让 Worker 主动拉取新配置。安全且可靠的做法始终是：
- 修改 nginx.conf 或 conf.d 下某文件
- 执行 nginx -t 验证语法
- 发送 SIGHUP（或 nginx -s reload）通知 Master
- Master 校验新配置 → 启动新 Worker → 逐步关闭旧 Worker（处理完已有连接后退出）
这种设计避免了多进程间配置不一致、竞态更新或权限绕过风险，也契合 Nginx “以静制动、以少控多”的轻量管理哲学。
