直接在upstream块中为节点添加down并reload可秒级隔离——不发新请求、不探活、不参与容错；正确写法为server ip:port down;，仅允许与weight、backup等静态参数共存，不可与max_fails等混用。
直接在 upstream 块中给目标节点加上 down，再执行 nginx -s reload，就能秒级隔离该节点——不发新请求、不探活、不参与容错，且不影响其他节点和 Nginx 自身运行。
正确配置 down 的写法
必须严格遵循语法，否则 reload 会失败：
-
✅ 正确写法：server 192.168.1.10:8080 down;（
down紧跟地址端口后、分号前） - ❌ 错误写法：server 192.168.1.10:8080; down;（换行或分号后加）
-
❌ 错误写法：server 192.168.1.10:8080 max_fails=1 down;（不能与
max_fails、fail_timeout等动态参数混用） -
✅ 允许共存：server 192.168.1.10:8080 weight=2 down;（仅限
weight、backup等静态参数）
down 的实际效果
它不是靠探测失败触发的动态下线，而是初始化时就硬性剔除：
- 新请求完全不转发到该节点
- 健康检查模块（哪怕启用了
health_check或第三方check）自动跳过，不发任何探测包 - 不参与
proxy_next_upstream故障重试逻辑 - 不影响其他节点的权重分配和轮询顺序
- 已建立的长连接仍可继续处理（需后端配合 graceful shutdown）
搭配 backup 实现自动接管
如果希望主节点下线后流量立刻切到备用机，提前配置 backup 节点即可：
- 正常情况下，
backup节点完全静默：不轮询、不建连、不探测 - 当所有非
backup节点都被标记为down或实际不可用时，backup自动激活 - 例如：
server 192.168.1.100:8080 backup;
下线与恢复全流程
整个过程无需重启 Nginx 主进程，业务无感：
- 确认目标节点已无新请求进入（如观察 access_log 停止增长）
- 在 upstream 中对应 server 行末尾添加
down，执行nginx -s reload - 维护完成后，先验证后端服务可用（如
curl http://192.168.1.10:8080/health） - 删掉配置中的
down关键字，再次nginx -s reload，流量即刻回归
注意：down 状态不会持久化，Nginx 主进程重启后自动清空，下次维护需重新配置。
