nginx -s reload 是主进程驱动的五步优雅重载机制：校验配置、开新端口、启新worker、发quit信号、旧worker处理完请求后退出，期间新旧worker并存且内存双副本。
nginx -s reload 不是简单地“重启配置”，而是一套有严格时序的进程协作机制。它靠主从进程分工、信号控制和资源继承来实现服务不中断，但背后存在内存、端口、连接状态等多层状态切换。
主进程主导五步动作
reload 的实际执行由 master 进程全程驱动，不是 worker 自行更新：
- 收到 HUP 信号后，先完整解析新配置文件（含所有 include），语法错误则中止，旧配置继续运行；
- 若语法通过，master 尝试打开新配置中新增的监听端口（如新加了 8443 或 IPv6 地址），失败则 reload 回滚；
- 用新配置 fork 出一批新 worker 进程，它们继承 master 已打开的所有监听 socket（包括旧端口和新端口）；
- 向全部旧 worker 进程发送 QUIT 信号，要求其停止 accept 新连接，但继续处理已建立的连接；
- 旧 worker 在完成所有活跃请求后，释放内存、关闭句柄、自行退出；master 最终清理旧配置结构体。
新旧 worker 并存是常态
在 reload 完成前，系统中必然同时存在两组 worker：一组按旧配置运行，一组按新配置运行。这种并存带来几个关键现象：
- worker 进程数临时翻倍，高并发下可能引发 CPU 缓存抖动或调度争抢；
- 新旧 worker 共享同一组监听 socket，内核通过 EPOLL 或 kqueue 负载分发新连接，因此新连接自动落到新 worker；
- 旧连接（如长连接、WebSocket、未完成上传）仍由旧 worker 处理，直到自然结束或超时；
- 若旧 worker 长时间不退出（例如大文件传输未完成），会延迟内存释放和配置完全切换。
内存波动不是故障，而是设计使然
reload 过程中内存占用上升是正常行为，根源在于配置结构体的双副本机制：
- 新配置解析完成后，master 会为它分配一整套独立结构体（含缓存区、模块上下文、server/location 树等）；
- 此时旧结构体仍在旧 worker 进程中驻留，新旧两套结构并存，内存使用量接近翻倍；
- 当旧 worker 全部退出后，master 才释放旧结构体，但 glibc 堆内存未必立即归还操作系统，表现为 top 中 RES 值回落慢；
- 启用 proxy_cache、增大 client_max_body_size 或引入大型第三方模块，会让该波动更显著、持续更久。
哪些变更会导致 reload 行为异常
并非所有配置修改都适合 reload，部分变更会绕过优雅流程或引发兼容问题：
- 监听地址/端口被完全移除：旧端口上的存量连接仍可处理，但新连接无法再建立，需确认业务是否依赖该端口；
- SSL 证书路径变更：新 worker 加载新证书，但旧 worker 仍用旧证书服务现存 HTTPS 连接，证书更新本身无需中断；
- worker_processes 数量调整：仅对新 worker 生效，旧 worker 不会缩容，需等待其自然退出；
- 涉及共享内存段（如 limit_req_zone、ssl_session_cache）的变更：部分场景需 restart 才能生效，reload 可能忽略或复用旧段。
