使用 nginx -s reload 实现平滑重载配置，核心在于向 nginx 主进程发送 hup 信号。该操作会触发主进程重新读取配置文件并验证语法，若验证通过，则启动新的工作进程（worker）加载新配置，同时通知旧的工作进程停止接收新连接并优雅退出，从而实现零停机更新。
执行命令后主进程与子进程的交互流程是怎样的
当你在终端执行 nginx -s reload 时，客户端程序会定位到存储主进程 ID（PID）的文件（通常位于 /var/run/nginx.pid），并向该 PID 发送 HUP 信号。主进程收到信号后，不会立即重启，而是先解析新的 nginx.conf。如果配置语法正确，主进程会 fork 出新的工作进程，这些新进程开始监听端口并处理请求；与此同时，主进程向所有旧的工作进程发送 QUIT 信号，旧进程在处理完当前已建立的连接后关闭 socket 并退出。整个过程由主进程协调，确保服务不中断。
#!/bin/bash
# 1. 检查配置文件语法是否正确
nginx -t
# 2. 如果语法检查通过，执行平滑重载
if [ $? -eq 0 ]; then
nginx -s reload
echo "Nginx configuration reloaded successfully."
else
echo "Configuration test failed, no reload performed."
fi如何验证重载是否成功且服务未中断
验证平滑重载的成功与否，主要观察两个指标：一是进程列表中新旧 Worker 进程的共存状态，二是业务请求的连续性。在重载瞬间，你可以通过 ps aux | grep nginx 看到新旧两组 Worker 进程同时存在，这是正常现象。旧进程会逐渐减少活跃连接数直至归零退出，新进程则迅速增加。为了证明服务未中断，可以在重载前后持续发送 HTTP 请求（例如使用 curl 或 wget），只要没有返回 502 Bad Gateway 或连接超时错误，即说明平滑重载生效。此外，查看 Nginx 的错误日志（error.log），应能看到类似 “signal 1 (HUP) received” 和 “gracefully shutting down” 的记录，而无报错信息。
# 模拟并发请求以验证平滑性
for i in {1..100}; do
curl -s -o /dev/null -w "%{http_code}\n" http://localhost/
done如果新配置文件存在语法错误会发生什么
如果在执行 nginx -s reload 时，新的 nginx.conf 文件包含语法错误或引用了不存在的模块，Nginx 的主进程在解析阶段就会失败。此时，主进程**不会**启动新的工作进程，也**不会**终止旧的工作进程。系统会保持原状，继续使用旧的配置运行服务，并在错误日志中明确记录导致解析失败的具体行号和错误原因。这种设计确保了“安全优先”，防止因配置错误导致服务宕机。因此，在生产环境执行重载前，强烈建议先手动运行 nginx -t 进行预检。
