最轻量可控的手动隔离方式是在upstream块中为server添加down参数并reload配置。正确写法是server 10.0.0.5:8080 down;，仅可与weight、backup等静态参数共存，不可与max_fails等动态参数混用；nginx停止分发新请求但保持已有连接处理，需配合后端逐步下线，并支持backup自动接管及ip_hash兼容。
直接在 upstream 块里给目标 server 加 down，reload 配置就能立刻停止分发新请求，已建立的连接仍可正常处理——这是最轻量、最可控的手动隔离方式。
down 参数怎么写才有效
语法必须严格，否则 nginx -t 会报错，导致 reload 失败：
- ✅ 正确写法：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 等动态参数混用）
- ✅ 可共存参数：server 10.0.0.5:8080 weight=2 down;（仅限 weight、backup 等静态参数）
下线过程要配合后端节奏
nginx 只管“不发新请求”，真正零丢失靠后端留出处理时间：
- 先标记 down 并 reload，新请求立即绕过该节点
- 后端同步关闭新入口（如 Spring Boot 调 /actuator/health 返回 DOWN 或停 Tomcat connector）
- 保持已有连接可读写，等活跃连接自然归零（可通过 stub_status 查 active conn）
- 确认连接数降为 0 后，再终止后端进程
搭配 backup 实现流量自动接管
如果希望主节点下线时流量无缝切到备用机，提前配置 backup 即可：
- 正常时：server 10.0.0.6:8080 backup; 完全静默，不轮询、不探测、不建连
- 当所有非 backup 节点都被设为 down 或实际不可用时，backup 自动激活参与分发
- 无需改策略、不等探测收敛，做到“先接后切”
ip_hash 场景下也完全兼容
启用 ip_hash 时，Nginx 的哈希计算会自动跳过带 down 的节点：
- 新请求的 IP 哈希结果只落在剩余可用节点上，不会出现哈希到 down 节点却转发失败的情况
- 已有长连接（HTTP keepalive、WebSocket）不受影响，继续完成处理
- 整个过程无需重启 Nginx，也不破坏会话一致性
