启用ip_hash的nginx集群平滑下线后端节点，核心是用down参数标记节点并热重载，ip_hash自动从可用池剔除该节点、重平衡新请求，不中断已有长连接；需配合后端优雅关闭与超时设置，并注意代理场景透传真实ip。
在启用 ip_hash 的 Nginx 集群中平滑下线后端节点，核心是让新请求自动避开目标节点，同时不中断已有连接——ip_hash 本身会自动跳过被标记为 down 的节点，无需改算法、不引发哈希重分布，真正实现零抖动。
用 down 参数标记节点，ip_hash 自动重平衡
ip_hash 的哈希逻辑不是固定映射到某台机器，而是基于当前“可用节点列表”动态计算。一旦某个 server 行末尾加上 down，它就从可用池中实时剔除，后续新请求的哈希结果只落在剩余健康节点上：
- 语法必须规范：例如
server 192.168.1.10:8080 down;，down要写在分号前，不能与其他参数（如max_fails）混用 - 热重载生效：
nginx -s reload后立即摘流，不收新请求，也不发健康检查 - 已有长连接（HTTP/1.1 keepalive、WebSocket）不受影响，可继续处理完
配合后端优雅关闭，确保连接自然归零
仅 Nginx 摘流还不够，后端需主动配合释放资源：
- 下线前，调用后端的
/actuator/shutdown（Spring Boot）或自定义/graceful-shutdown接口，停止接收新请求 - 设置合理超时：Nginx 侧建议
proxy_read_timeout 60s，留足时间让后端完成存量请求 - 监控
stub_status或 Prometheus 指标，确认该节点的活跃连接数持续下降至 0
避免常见陷阱
几个关键点容易出错，务必注意：
-
ip_hash不支持weight和backup，所以不能靠权重归零或备用节点接管；依赖down是唯一轻量可靠的方式 - 若客户端走代理（如 NAT 网关），所有请求可能来自同一出口 IP，导致全部哈希到单台——需透传真实 IP：
proxy_set_header X-Real-IP $remote_addr;并在ip_hash前加hash $http_x_real_ip consistent;替代方案 - 配置变更后必须执行
nginx -t校验，失败会导致整站不可用
自动化集成建议
在 CI/CD 或运维平台中，可将下线流程标准化：
- 平台根据工单自动修改 upstream 配置，在目标行追加
down - 校验通过后触发
reload，并轮询/upstream_show确认节点已从活跃列表消失 - 连接清零后，自动调用后端下线接口；必要时保留
down标记作为灰度开关
