nginx优雅关闭核心是worker进程在不中断现有请求下退出：主进程收sigquit后通知worker，worker设ngx_exiting=1、关监听、清空闲连接、处理完活跃请求后退出；超时由worker_shutdown_timeout兜底，http场景最有效。
利用 Nginx 进程的优雅关闭机制，核心是让 worker 进程在不中断现有请求的前提下完成自身退出。它不是简单发个信号就完事，而是一套主从协同、状态驱动、带超时保障的流程。
明确触发方式与对应信号
优雅关闭必须使用 QUIT 信号，不能用 TERM 或 INT：
-
推荐命令：执行
nginx -s quit（自动读取 pid 文件并发送 SIGQUIT 给主进程） -
手动方式：
kill -QUIT $(cat /var/run/nginx.pid)（确保路径准确） -
避免误用：
nginx -s stop或kill -TERM属于快速终止，会立即丢弃未完成请求
理解 worker 进程的退出行为
收到 QUIT 指令后，worker 不会立刻退出，而是按序执行以下动作：
- 设置内部标志
ngx_exiting = 1，进入退出流程 - 关闭监听套接字——不再 accept 新连接，但已建立的连接仍可收发数据
- 主动关闭空闲 keepalive 连接（如 HTTP/1.1 长连接池中的闲置连接）
- 继续处理已入队的请求、定时器、读写事件，直到每个活跃连接自然关闭或超时
合理配置超时防止卡死
若某些连接长期未关闭（如慢后端、WebSocket 空闲帧、TCP 代理未断连），worker 可能迟迟不退出。此时需依赖 worker_shutdown_timeout：
- 在
nginx.conf的http或stream块中配置，例如：worker_shutdown_timeout 30s; - 该值表示：从进入退出流程起，最多等待 30 秒；超时后，仍在处理的连接会被强制关闭，worker 随即退出
- 注意：对纯 HTTP 请求效果最佳；对 WebSocket、gRPC、TCP 代理等无法识别“请求边界”的场景，该超时是必要兜底
验证是否真正优雅完成
退出是否成功，不能只看进程是否消失，要结合日志和状态判断：
- 检查
error.log，应看到类似日志：2026/06/05 19:45:22 [notice] 1234#1234: signal 3 (SIGQUIT) received, exiting和2026/06/05 19:45:22 [notice] 1234#1234: exit - 用
ps aux | grep nginx观察：主进程仍在，旧 worker 逐个消失，新 worker（如 reload 场景）应已就位 - 监控活跃连接数变化：可通过
stub_status或nginx -T | grep worker_connections辅助观察连接回落趋势
