down参数是nginx upstream中用于静态标记节点彻底下线的指令，reload后立即生效：不参与负载均衡、不触发健康检查、不参与故障转移，且必须置于server行末尾单独使用。
直接在 upstream 的 server 行末尾加 down，配合自动化发布平台的 reload 触发机制，就能实现节点级的滚动平滑下线——不依赖健康检查、不中断其他节点、无需重启进程，是目前最轻量可控的手动隔离方式。
down 指令的核心定位与适用场景
它不是动态探测结果，而是静态标记：Nginx 在初始化 upstream 时就读取该状态，后续所有请求调度、健康探测、故障转移逻辑都会彻底跳过带 down 的节点。
- 新请求零流量进入，已建立连接不受影响（需配合 graceful shutdown 机制）
- 即使启用了
health_check，也不会发送任何探测请求 - 不会因集群剩余节点少而被“自动启用”，和
backup有本质区别 - 适合发布平台按批次调用脚本修改配置 + reload 的自动化流程
自动化平台中 down 的标准写法与校验要点
必须严格遵循语法规范，否则 nginx -t 会报错，导致发布失败。
- ✅ 正确写法：
server 192.168.1.10:8080 down;（down 必须单独置于行尾，分号前无空格或其它参数） - ❌ 错误示例：
server 192.168.1.10:8080 max_fails=1 down;（混合动态参数，校验失败） - ❌ 错误示例：
server 192.168.1.10:8080; down;（语法无效，down 不是独立指令） - ✅ 可组合 backup：
server 192.168.1.11:8080 backup;，用于主节点 down 后自动接管
与发布平台联动的滚动下线流程
整个过程由平台驱动，无需人工干预，关键动作由脚本或 API 完成：
- 平台选定待下线节点 IP，生成 patch 配置（如 sed 替换或模板渲染），在对应 server 行追加 down
- 执行
nginx -t && nginx -s reload，流量实时切出，旧连接仍可完成处理 - 平台监听 access_log 或 Prometheus 指标，确认该节点请求量归零后，触发后端服务停机
- 维护完成后，平台自动删掉 down 标记并再次 reload，节点回归轮询队列
搭配 backup 实现“先接后切”的自动兜底
若希望下线期间流量无缝转移到备用节点，需提前在 upstream 中定义 backup 节点：
- 非 backup 节点全部被设为 down 或宕机时，backup 才会被激活参与负载均衡
- backup 节点平时完全静默：不轮询、不探测、不建连、不消耗资源
- 例如：
server 192.168.1.20:8080 backup;可作为灰度/灾备通道，与 down 配合形成双保险
