Nginx集群节点平滑下线需做到不丢请求、不断连接、不扰动其他节点；核心是用down指令静态摘流、backup自动接管、健康检查+proxy_next_upstream容错，并闭环验证恢复。
在 Nginx 集群架构中实现节点平滑下线，核心目标是：不丢请求、不断连接、不扰动其他节点。这不是简单删配置或停服务，而是让 Nginx 主动“放手”，同时给后端留出处理余量。关键在于控制流量入口、保障连接善后、闭环验证恢复。
用 down 指令做静态摘流，秒级生效
这是最轻量、最可控的下线方式。它不依赖探测延迟，reload 后立刻生效：
- 语法必须严格：写在 server 行末尾，单独使用，不能混参数，例如
server 10.0.1.5:8080 down; - 生效后该节点彻底退出负载均衡——不收新请求、不发健康检查、不参与故障转移
- 已建立的连接不受影响，可继续完成处理（需后端配合 graceful shutdown）
- 适合 CI/CD 流水线自动注入：用模板渲染或 sed 脚本标记目标节点，再执行
nginx -s reload
搭配 backup 实现自动流量接管
若需下线期间无缝承接流量，提前定义备用节点即可：
- 在 upstream 中声明
server 10.0.1.6:8080 backup;，它平时完全静默，不轮询、不探测、不建连 - 当所有非 backup 节点被标记为 down 或实际不可用时，backup 自动激活参与分发
- 无需修改策略、无需等待健康检查收敛，真正“先接后切”
结合健康检查与 proxy_next_upstream 提升容错
down 是主动控制，健康检查是被动兜底，二者互补：
- 启用
nginx_upstream_check_module（需编译支持），配置 HTTP 探活：check interval=3 rise=2 fall=3 type=http; - 后端下线前主动返回
503 Service Unavailable，触发 Nginx 自动标记为 down - 必须配合
proxy_next_upstream error timeout http_502 http_503 http_504，确保失败请求能重试到其他健康节点 - 注意：upstream 块中不能同时启用
keepalive和check，二者冲突会导致启动失败
下线后验证与闭环管理
下线动作不是终点，而是流程一环：
- 调用
curl http://nginx-status/upstream_show（需开启 stub_status）确认目标节点已从活跃列表消失 - 监控 access_log 最后一条时间戳，确认 30 秒内无新增请求进入该节点
- 待后端确认连接归零后，由流水线自动删除 down 标记并 reload，或保留为灰度开关供手动启用
- 整个过程零主进程重启、零连接中断、零人工干预，可版本化、可审计、可回滚
