最轻量可控的手动隔离方式是在upstream中为server行末尾加down并reload；语法须严格：down紧贴地址端口后、分号前，不可与max_fails等混用，仅可与weight、backup等静态参数共存。
直接在 upstream 块中给目标 server 行末尾加上 down，再执行 nginx -s reload，就能立刻停止分发新请求——这是最轻量、最可控的手动隔离方式。
down 参数怎么写才有效
语法必须严格，否则配置校验失败：
- ✅ 正确写法：
server 10.0.0.5:8080 down;（down紧贴地址端口后、分号前） - ❌ 错误写法：
server 10.0.0.5:8080; down;（换行或分号后加） - ❌ 错误写法：
server 10.0.0.5:8080 max_fails=1 down;（不能与max_fails、fail_timeout等动态参数混用） - ✅ 允许共存的参数只有：
weight、backup、ip_hash等静态配置，例如：server 10.0.0.5:8080 weight=2 backup down;
down 的实际效果是什么
它不是“等它挂了再踢”，而是人工强制逻辑下线：
- 新请求完全不转发过去，零流量接入
- 健康检查模块（哪怕已启用
health_check）自动跳过，不发任何探测包 - 不参与故障转移逻辑，即使集群只剩一台正常节点，也不会被“拉回来”
- 已建立的长连接仍可继续处理（如 WebSocket、HTTP/1.1 keepalive），但不再接受新连接
- 不影响其他 server 的权重计算和轮询顺序
配合 backup 实现自动接管
如果希望主节点下线后流量立刻切到备用机，提前配置 backup 节点即可：
- 正常情况下，
backup节点完全静默：不建连、不轮询、不探测 - 当所有非
backup节点都被设为down或实际宕机时，backup才会被激活 - 示例：
server 10.0.0.6:8080 backup;，搭配server 10.0.0.5:8080 down;即可平滑过渡
下线与恢复全流程
整个过程无需重启 Nginx，业务无感：
- 编辑 upstream 配置，在目标 server 行末尾添加
down - 运行
nginx -t验证语法是否正确 - 执行
nginx -s reload生效（毫秒级，不中断已有连接） - 维护完成后，确认后端服务可用（如
curl http://10.0.0.5:8080/health） - 删掉配置中的
down，再次nginx -s reload，流量即刻回归 - 建议 reload 后执行
nginx -T | grep "server.*down"，确认配置已加载成功
