down指令是Nginx最直接的故障节点标记方式，语法为server IP:port down;，需严格书写；标记后新请求零转发、健康检查跳过、不参与重试，但长连接仍可用。
用 down 指令手动标记故障节点，是 Nginx 故障转移中最直接、最即时的干预方式——不依赖探测延迟，reload 后立刻生效，新请求零流量进入，已建立连接不受影响。
down 指令怎么写才有效
语法必须严格，否则 nginx -s reload 会失败：
- ✅ 正确：server 192.168.1.20:8080 down;
- ❌ 错误：server 192.168.1.20:8080; down;
- ❌ 错误：server 192.168.1.20:8080 max_fails=2 down;
- ✅ 允许共存的只有静态参数，比如：
server 192.168.1.20:8080 weight=3 backup down;
down 标记后的实际行为
它不是“等它挂了再踢”，而是从调度源头硬性剔除：
- 新请求完全不转发到该节点
- 健康检查模块（无论是否启用
health_check或第三方 check）自动跳过，不发任何探测包 - 不参与
proxy_next_upstream的故障重试逻辑 - 不影响其他节点的权重、轮询顺序或连接池状态
- 已建立的长连接（如 HTTP/1.1 keepalive、WebSocket）仍可继续处理，但不再接受新连接
搭配 backup 实现自动接管
若希望下线期间流量无缝切走，提前配置 backup 节点即可：
- 正常时 backup 节点静默：不建连、不轮询、不探测
- 当所有非 backup 节点都被设为 down 或实际不可用时，backup 自动激活
- 示例配置：
server 192.168.1.100:8080 backup;+server 192.168.1.20:8080 down;
下线与恢复全流程
整个过程无需重启主进程，业务无感：
- 确认目标节点 access_log 停止增长，说明新请求已停止接入
- 在 upstream 对应 server 行末尾添加
down，执行nginx -s reload - 维护完成后，先验证后端服务可用（如
curl http://192.168.1.20:8080/health） - 删掉配置中的
down，再次nginx -s reload，流量即刻回归
注意：down 状态不会持久化，Nginx 主进程重启后自动清空，下次维护需重新配置。
