down参数是Nginx upstream中用于永久标记服务器为不可用的轻量级手动隔离方式，不参与请求转发与健康检查，需配置后reload生效，重启失效，适合故障应急、灰度发布等场景。

当后端某台服务器出现故障但又不能立即下线时，Nginx 的 down 参数是最轻量、最可控的手动隔离方式——它不依赖健康检查机制，也不影响 upstream 配置结构，只需一行标记即可让该节点彻底退出调度。

down 参数的作用与本质

down 是 Nginx upstream 模块中 server 指令的内置参数，用于**永久性标记某台服务器为不可用状态**。被标记的节点不会参与任何请求转发，也不会被健康检查探测（即使启用了 health_check），相当于逻辑下线。

它和 backup 不同：backup 是备用角色，仅在其他非 backup 节点全挂时才启用；而 down 是彻底剔除，无论集群是否正常都永不参与负载。

如何正确使用 down 参数

在 upstream 块中，直接在对应 server 行末尾添加 down 即可：

upstream backend {
  server 192.168.1.10:8080;
  server 192.168.1.11:8080 down;
  server 192.168.1.12:8080;
}

注意以下几点：

• 无需 reload 或 restart Nginx，修改配置后执行 nginx -s reload 生效
• down 状态不会写入磁盘或持久化，重启后失效，需重新配置
• 可与其他参数共存，如 server 192.168.1.11:8080 down max_fails=3 fail_timeout=30s;，但后两者在此场景下无实际作用
• 不支持运行时动态开关（如通过 API），必须改配置 + reload

适用场景与替代方案对比

down 最适合这些情况：

• 运维人员发现某台应用服务器 CPU 持续 100%、OOM 或日志大量报错，需立刻切流排查
• 灰度发布中临时屏蔽某台旧版本节点，避免流量进入
• 配合监控告警脚本，在检测到异常时自动注入 down 标记（需配套配置管理工具）

相比其他隔离方式：

• 停掉后端服务进程：可能引发连接拒绝（Connection refused），客户端易感知错误；而 Nginx 仍可正常响应，只是不发请求过去
• 防火墙 DROP 流量：操作层级高、风险大，且无法快速回滚；down 是纯配置层动作，更安全可控
• 健康检查自动摘除：依赖探测周期（如 5s 一次），存在滞后性；down 是秒级生效的主动干预

验证与日常维护建议

隔离后可通过以下方式确认效果：

• 查看 Nginx 错误日志，确认无向该 IP:Port 发起新连接的日志
• 使用 curl -I http://your-nginx/ 多次请求，用 tcpdump 抓包验证目标 IP 是否不再出现在后端通信中
• 访问 /status（需启用 stub_status）或第三方模块如 nginx-module-vts，观察该节点连接数归零且状态显示为 down

建议将带 down 的配置行加上注释，标明原因和时间，例如：

server 192.168.1.11:8080 down; # 2024-06-15 14:22 | DB连接泄漏，正在排查

避免多人协作时误删或遗忘恢复。