down参数是Nginx upstream中用于静态标记后端服务器为不可用的轻量级方式，reload后立即生效：不转发请求、不触发健康检查、不参与故障转移，且必须置于server行末尾单独使用。
使用 upstream 的 down 参数可以**显式标记某个后端服务器为不可用状态**，Nginx 会跳过它，不向其转发请求。这不同于自动探测失败（如 max_fails + fail_timeout），而是人工干预的“静态下线”，适用于维护、紧急隔离或灰度回退等场景。
down 参数的基本用法
down 是 upstream 块中 server 指令的参数，只能用于定义时静态设置，不能热更新（修改后需重载 Nginx 配置）。
- 语法：
server 10.0.1.100:8080 down; - 该 server 不参与负载均衡，也不被健康检查探测
- 即使它实际是通的，Nginx 也完全忽略它
- 搭配
backup或weight使用时，down优先级最高 —— 即使是 backup 服务器，标了down就不会启用
典型使用场景与配置示例
比如你有三台应用服务器，其中一台正在紧急修复，需要立即停止流量接入：
upstream backend {
server 10.0.1.101:8080 weight=3;
server 10.0.1.102:8080 weight=3;
server 10.0.1.103:8080 down; # 立即隔离，不发请求过去
}注意：down 不影响其他 server 的权重计算，也不改变当前连接——已建立的长连接可能还在用，但新请求绝不会路由到该节点。
和健康检查机制的区别
down 是运维主动控制，而健康检查（如 max_fails=3 fail_timeout=30s）是被动响应故障：
- 健康检查可能滞后（需连续失败才触发），且恢复需等待
fail_timeout后重试 -
down立即生效，恢复必须手动删掉down并重载配置 - 二者可共存：一个 server 可同时配置
down和max_fails，但down会让健康检查直接跳过它
配合 reload 实现快速隔离
生产中建议将 down 写在独立的 upstream 文件里（如 upstream_prod.conf），便于批量操作：
- 编辑配置，给目标 server 加上
down - 运行
nginx -t验证语法 - 执行
nginx -s reload生效（毫秒级，无请求丢失） - 后续恢复时，删掉
down再 reload 即可
不复杂但容易忽略：记得 reload 之后检查 nginx -T | grep "server.*down" 确认配置已加载成功。
