Nginx 的 -s 参数用于向主进程发送信号实现平滑操作；reload 重载配置不中断连接，restart 非官方命令需手动发 HUP 信号，操作前须校验语法、检查权限并验证生效。

Nginx 的 -s 参数用于向运行中的主进程发送信号，实现配置重载（reload）或平滑重启（restart），无需中断现有连接，是线上服务维持高可用的关键操作。

重载配置：不中断服务更新配置

当修改了 nginx.conf 或其他 include 的配置文件后，执行以下命令让 Nginx 重新加载配置，同时保持旧 worker 进程继续处理已有请求：

• nginx -s reload —— 要求主进程已运行且 pid 文件路径正确（默认 /usr/local/nginx/logs/nginx.pid）
• 若自定义了 pid 文件位置，需在配置中指定：pid /var/run/nginx.pid;，并确保 -s 操作时能读取到该路径
• 执行后，主进程会验证新配置语法（nginx -t 实际被隐式调用），失败则报错且不生效；成功则 fork 新 worker 进程，逐步关闭旧 worker

平滑重启：等效于 reload + 主进程重启

严格来说，Nginx 官方并未提供 -s restart 选项。所谓“平滑重启”实际是通过 kill 发送信号完成的组合动作：

• 先用 nginx -s reload 实现配置热更新（推荐首选）
• 如确需重启主进程（例如升级二进制、修复主进程状态异常），可手动发送信号：kill -s HUP `cat /var/run/nginx.pid`
• 注意：nginx -s stop 或 nginx -s quit 是终止操作，不属于“平滑”，慎用

常见问题与验证要点

执行 -s 操作后，建议快速确认是否真正生效：

• 检查错误日志：tail -f logs/error.log，观察是否有 reloading 或配置语法错误提示
• 查看进程变化：ps aux | grep nginx，应看到新旧 worker 进程共存一段时间，随后旧进程自然退出
• 验证配置有效性：执行 nginx -t 再操作，避免因语法错误导致 reload 失败却无感知
• 权限问题：确保执行用户对 pid 文件、日志目录、配置文件均有读写权限，否则 -s 会报 failed (13: Permission denied)

自动化脚本中安全使用 -s

在部署脚本或 CI/CD 流程中调用 -s reload 时，应加入防护逻辑：

• 始终前置 nginx -t && nginx -s reload，用 && 保证仅当语法校验通过才触发 reload
• 添加超时等待和状态检查，例如：timeout 10s bash -c 'while ! nginx -s reload 2>/dev/null; do sleep 0.5; done'
• 避免在无主进程时误执行：kill -0 $(cat /var/run/nginx.pid) 2>/dev/null && nginx -s reload