worker_processes不支持热加载，reload仅触发新旧worker进程整体滚动替换；主进程PID不变，worker数量按新配置重建并全部刷新PID，旧worker需优雅退出后新配置才完全生效。
worker_processes 本身不支持热加载，所谓“reload 后配置生效”只是主进程拉起新 worker、逐步淘汰旧 worker 的滚动替换过程。热加载失效若表现为服务行为未更新（如路由规则、SSL 配置、限流策略等没变），问题往往不在 worker_processes 数量变化本身，而在于这个“替换过程”是否真正完成、或新旧 worker 是否混用旧逻辑。定位需聚焦进程状态、生命周期与资源交接。
查进程数量与 PID 变更
执行 ps -ef | grep nginx，重点对比 reload 前后：
- 主进程（master）PID 应保持不变；若变化，说明是 restart 而非 reload
- worker 进程数量应等于新配置中 worker_processes 值（如从 auto 改为 4，则最终稳定为 4 个 worker）
- 所有 worker PID 必须全部刷新——若仍有旧 PID 存在且持续运行超 30 秒，说明优雅退出卡住，新配置未完全接管
看日志确认 reload 流程是否走完
检查 error_log（如 /var/log/nginx/error.log）中 reload 相关记录：
- 成功 reload 会出现类似 "signal 1 (SIGHUP) received, reconfiguring" 和 "reopening logs"
- 若出现 "gracefully shutting down" 但无后续 "exiting" 或 "exit"，说明旧 worker 挂起在处理长连接（如 WebSocket、keepalive 请求），尚未退出
- 报错如 "bind() to 0.0.0.0:80 failed (98: Address already in use)"，表明旧 worker 未释放端口，新 worker 启动失败，实际仍由旧进程响应请求
验配置是否真正被新 worker 加载
不要只信配置文件内容，要验证运行时生效的配置：
- 用 nginx -T 输出当前主进程加载的完整配置（含 include 展开），确认 events、http 块内关键指令（如 worker_connections、upstream 定义）与预期一致
- 对关键功能做灰度验证：例如修改某 location 的 return 语句后，curl 对应路径，观察响应是否更新；若未变，说明请求仍被旧 worker 处理
- 配合 ss -tlnp | grep :80 查看监听进程 PID，再比对 ps 中对应 PID 的启动时间，确认当前处理请求的是新 worker 还是残留旧进程
排除系统级资源阻塞
worker 替换失败常因底层资源不足导致新进程无法启动或旧进程无法退出：
- 检查 ulimit -n 和 worker_rlimit_nofile 是否足够：新 worker 启动需分配文件描述符，若系统限制太低，会静默失败
- 运行 cat /proc/$(cat /run/nginx.pid)/limits | grep "Max open files"，确认主进程软硬限制已生效
- 查看 dmesg | tail -20，是否有 OOM killer 杀掉新 worker 或 “epoll_create failed” 类内核报错（常见于容器中 RLIMIT_NOFILE 不足）
