直接在upstream配置中添加down标记可立即摘流，但需配合draining控制实现优雅下线；down为静态剔除、零延迟生效、不可自动恢复，须手动移除并reload；紧急时可批量down+本地降级。
直接在 upstream 配置中把目标节点标记为 down，Nginx 会立即停止向其转发新请求，且无需 reload 或重启服务。这是最轻量、最即时的故障摘流方式，但需配合后端 draining 和连接行为控制，才能真正实现“优雅”。
down 参数的作用与生效机制
down 是 Nginx upstream 中的静态状态标记，不是健康检查结果，也不依赖探测。只要配置里写 server x.x.x.x:port down;，该节点就从负载均衡池中永久剔除——Nginx 在每次选节点时都会跳过它，连连接尝试都不会发起。
- 生效零延迟：修改配置后执行
nginx -s reload即刻生效（注意：reload 不中断已有连接） - 不依赖模块：原生支持，无需编译第三方模块（如 upstream_check）或 Plus 许可
- 不可自动恢复：即使后端恢复正常，也必须手动删掉
down并 reload 才能重新加入
仅用 down 不够，必须配套 draining 控制
标记 down 只解决“不再派新请求”，但已建立的长连接、正在处理的请求仍可能打到该节点（如果此前已建立连接且未断开）。要确保这些存量请求完成，需同步调整代理层行为：
- 设置
proxy_read_timeout 60s;（或更长），让 Nginx 等待后端把手上请求做完，不因超时强行中断 - 启用
proxy_ignore_client_abort on;，防止用户关页面导致 Nginx 提前终止后端仍在响应的连接 - 避免在 upstream 块中混用
keepalive（会与down冲突报错），改用proxy_http_version 1.1;和proxy_set_header Connection "";透传 keep-alive 给后端自行管理
如何安全触发并验证 down 摘流
操作不是孤立的，需和后端下线节奏对齐：
- 后端先切换就绪探针：例如调用
/actuator/health?ready=false返回 503，让其他组件（如注册中心、监控）感知准备退出 - 再修改 Nginx 配置，将对应 server 行末尾加上
down，然后nginx -s reload - 验证是否生效：
nginx -T | grep "server.*down"确认配置加载；访问/status（需启用 stub_status）查看 Active connections 是否缓慢下降，且无该节点的 upstream 连接记录
紧急场景下的组合用法
当整个 upstream 集群需临时停服（如发布维护），可批量标记所有节点为 down，并配合本地降级：
- 在 upstream 块中统一加
down，如server 192.168.1.10:8080 down; - 在 location 中注释掉
proxy_pass，改用return 503 '{"status":"maintenance"}'; - reload 后流量秒级切到本地响应，完全不触达后端，回切时还原配置即可
