down参数是Nginx upstream中用于永久标记服务器为不可用的静态标记，加载配置时即固化状态，不参与请求转发、健康检查及故障转移，修改后reload立即生效且重启失效。

down 参数不是“让节点变慢”或“等它自己掉线”，而是直接从 Nginx 的 upstream 调度决策树里把它整行剔除——不转发、不探测、不兜底，一步到位切断所有流入流量。

它怎么做到“零参与”的？

down 是 server 指令的静态标记，在 Nginx 加载 upstream 配置时就被解析并固化为“不可用”状态。后续所有请求调度（包括 round-robin、least_conn、ip_hash）都跳过该条目；健康检查模块（如 health_check）也完全忽略它——哪怕你启用了主动探测，Nginx 也不会朝带 down 的地址发一个包。

这不是靠失败计数触发的动态下线，也不依赖 max_fails 或 fail_timeout 设置，所以不会出现“先打几次再下线”的试探过程，更不会有误判或延迟。

配置写法与生效边界

必须严格按格式书写，否则 nginx -t 会报错：

• down 只能出现在 server 行末尾，紧贴分号前，例如：server 10.0.1.5:8080 down;
• 不能换行写，不能加在分号后，也不能和 weight、backup 等参数混在同一行后半段（如 server ... weight=2 down max_fails=1 是非法的）
• 修改后执行 nginx -s reload 即刻生效，不中断其他节点服务，也不触发连接重置
• 注意：down 状态不持久化，Nginx 进程重启后自动失效，需重新配置

和 backup 的关键区别

backup 是“备用岗”，只在所有非 backup 节点都不可用时才上岗；而 down 是“注销状态”，哪怕集群只剩它一台，也不会被选中。

典型组合用法：

• 主节点出问题 → 加 down，立刻退出调度
• 同时有一台 backup 机器 → 它会在主节点 down 后自动承接流量
• 维护完成 → 删掉 down，reload，主节点回归，backup 回归静默

为什么适合计划内维护？

因为整个过程可控、可预期、无副作用：

• 不产生任何探测流量，避免对故障节点造成额外压力
• 不改变 upstream 结构，不影响权重分配与容错逻辑
• 操作粒度细到单台服务器，不影响同组其他实例
• 恢复只需删参数 + reload，无需等待健康检查周期或超时回滚