如何使用 down 参数在不删除配置的前提下，手动将后端故障节点维护下线？

本文共计564个文字，预计阅读时间需要3分钟。

使用 `down` 参数手动线下。

down 参数的核心作用

它是一个静态标记，告诉 Nginx：“这台服务器当前不可用”，Nginx 在初始化 upstream 时就读取该状态，后续所有请求调度都会跳过它：

• 不参与负载均衡转发
• 不被健康检查探测（哪怕启用了 health_check）
• 不参与故障转移逻辑
• 不影响其他 server 的权重分配和容错行为

正确配置 down 参数的方法

直接在 upstream 块中对应 server 行末尾添加 down，注意格式细节：

• 必须写在 server 地址和端口之后、分号之前，例如：server 192.168.1.11:8080 down;
• 不能换行写，也不能加在分号后面
• 可与其他参数共存（如 weight），但 max_fails、fail_timeout 等在此场景下无效
• 配置修改后执行 nginx -s reload 即刻生效，无需重启主进程

配合 backup 实现自动接管

如果希望主节点下线后流量自动切到备用机，可把备用节点标为 backup：

• 正常情况下，只有非 backup 的节点参与轮询
• 当所有非 backup 节点都被设为 down 或实际宕机时，backup 才会被启用
• 例如：server 192.168.1.100:8080 backup; —— 平时完全静默，只在需要时顶上

恢复上线的操作流程

维护完成后，三步还原即可让流量回归：

• 确认后端服务已就绪（比如用 curl http://192.168.1.11:8080/health 验证响应）
• 从配置中删除对应 server 行末尾的 down 关键字
• 执行 nginx -s reload，流量立即恢复，无请求丢失

整个过程对线上业务无感，且 down 状态不会持久化——Nginx 重启后自动清空，需重新配置。