down参数是nginx最直接可控的手动故障转移方式，reload后新请求立即绕过标记节点，但已有连接不受影响；必须写在server行末尾单独使用，如server 10.0.1.100:8080 down;，可与weight共存但不可混用max_fails等参数。
用 down 参数手动下线故障节点，是 Nginx 故障转移中最直接、最可控的干预方式。它不依赖健康检查的响应延迟，改完配置 reload 就生效，新请求立刻绕过该节点，但已有连接不受影响——这正是实现“故障转移中不中断服务”的关键前提。
down 参数怎么写才有效
必须严格按语法写在 upstream 的 server 行末尾，单独成词，不能和其他参数混用：
- ✅ 正确：
server 10.0.1.100:8080 down; - ❌ 错误：
server 10.0.1.100:8080 max_fails=1 down;（校验失败） - ❌ 错误：
server 10.0.1.100:8080; down;（语法无效） - ✅ 允许共存：
server 10.0.1.100:8080 weight=2 down;（weight 仍参与计算，但 down 优先级更高）
配合 backup 实现自动接管流量
如果希望下线期间流量无缝切到备用节点，提前在 upstream 中定义 backup 即可：
server 10.0.1.101:8080;server 10.0.1.102:8080;server 10.0.1.103:8080 down;-
server 10.0.1.200:8080 backup;（平时完全静默，不建连、不探测）
一旦所有非 backup 节点被标记为 down 或实际不可用，backup 节点会立即参与负载，无需等待健康检查收敛。
reload 后要确认什么
执行 nginx -s reload 后，并不是万事大吉。需验证三件事：
- 访问日志中目标节点 IP 的请求是否停止增长
- 用
curl -s http://localhost/stub_status查看 active conn 是否持续下降 - 确认后端服务自身已进入 draining 状态（如 Spring Boot 的
/actuator/shutdown或自定义优雅关闭接口）
和健康检查的关系怎么处理
down 是主动控制，健康检查（如 max_fails）是被动兜底，二者可以并存，但逻辑上互不干扰：
- 一个 server 同时配了
down和max_fails=3 fail_timeout=30s，Nginx 会直接跳过健康检查，因为它压根不会去连这个节点 - 建议保留健康检查配置，作为未被人工标记节点的容错保障
- 若使用第三方模块（如
nginx_upstream_check_module），down同样使其对该节点失效
