nginx -s reload 是主进程驱动的五步优雅重载机制：校验配置、开新端口、启新worker、发QUIT信号、旧worker处理完请求后退出，期间新旧worker并存且内存双副本。
直接用 nginx -s reload 就能实现不停服重载配置，但必须配合配置检查和权限控制，否则可能失败甚至中断服务。
先验证配置语法是否正确
重载前不检查配置，等于埋雷。Nginx 会加载新配置并尝试应用，一旦出错，旧配置可能失效，导致 502 或服务不可用。
- 运行
nginx -t：默认检测/etc/nginx/nginx.conf及其include的所有文件 - 若使用自定义路径（如
/opt/my-nginx/conf/nginx.conf），加-c参数：nginx -t -c /opt/my-nginx/conf/nginx.conf - 常见报错示例：
bind() to 0.0.0.0:80 failed (98: Address already in use)，说明端口被占，需用ss -tuln | grep :80排查
执行平滑重载操作
reload 的本质是向 master 进程发送 USR2 信号，触发新旧 worker 进程共存与优雅切换——已有连接继续由旧 worker 处理，新连接由新 worker 接管。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 推荐命令：
sudo nginx -s reload（要求当前用户有权限向 master 进程通信） - 手动发信号（适合权限受限环境）：
sudo kill -USR2 $(cat /var/run/nginx.pid)，注意 pid 文件路径需与配置中pid指令一致 - 不建议用
systemctl restart nginx或killall nginx，这些会强制终止旧进程，造成请求中断
确认重载是否真正生效
命令没报错 ≠ 配置已生效。要从进程、日志、行为三方面交叉验证。
- 查进程启动时间：
ps -eo pid,comm,lstart | grep nginx，worker 进程的启动时间应接近 reload 时间点 - 看 error 日志：
tail -f /var/log/nginx/error.log，成功 reload 会出现reopening logs或signal 10 (SIGUSR2) received - 测实际效果：比如改了
server_name example.com，用curl -H "Host: example.com" http://127.0.0.1确认路由是否命中新规则
几个容易踩的坑
看似一步到位的操作，常因细节疏忽导致失败或短暂中断。
- SELinux 或 AppArmor 启用时，可能阻止 Nginx 重开日志或绑定端口，查审计日志：
sudo ausearch -m avc -ts recent - 修改了
worker_processes后 reload，master 会按新值 fork 新 worker，但旧 worker 不会立刻退出——这是正常现象，不是卡死 - 如果用了
systemctl reload nginx，需确认 unit 文件中定义了ExecReload=，否则会退化为 restart；可查：systemctl cat nginx | grep ExecReload
