Keepalived仅保障VIP高可用，不参与后端调度；Nginx通过upstream权重调整、健康检查与热加载实现节点平滑替换，需配合draining机制、状态外置及错峰reload等配套措施。
Keepalived 本身不负责后端节点的平滑替换，它只管前端 Nginx 实例的高可用切换；真正实现后端集群节点“平滑替换”的核心是 Nginx 的 upstream 动态调度能力，Keepalived 在其中起的是保障代理层不中断的兜底作用。要达成“旧节点下线无感知、新节点接入无抖动”，需把 Nginx 配置热加载、健康检查协同、流量渐进迁移三者串起来，Keepalived 则确保整个过程中 VIP 始终在线、用户访问路径不变。
Keepalived 定位：守住 VIP，不参与后端调度
Keepalived 的职责非常明确——监控本机 Nginx 进程是否存活，一旦异常（如崩溃、卡死、无法响应健康检查），就触发 VRRP 投票，将虚拟 IP（VIP）快速漂移到备用 Nginx 节点。它不接触 upstream 里的真实后端地址，也不干预请求分发逻辑。因此，后端节点的增删、权重调整、下线 draining，全部由 Nginx 自身配置和配套机制完成，Keepalived 只提供“代理入口永不掉线”的保障。
Nginx upstream 实现节点平滑替换的关键操作
在 Keepalived 保障前端不中断的前提下，后端节点替换必须靠 Nginx 主动控制：
- 下线旧节点前，先在 upstream 中将其 weight 设为 0 或加上 down 标记，再执行
nginx -s reload。Nginx worker 会停止向该节点分发新请求，但已建立的长连接仍可继续处理完，实现 graceful shutdown - 上线新节点时，初始 weight 设为较低值（如 1），避免冷启动瞬间承接过多流量；后续通过脚本定期 reload 并逐步提升权重（例如每 3 分钟 +2），让其自然承接流量
- 配合主动健康检查（如
health_check指令或外部 Consul/etcd 探活），让 Nginx 自动屏蔽未就绪节点，等探测连续成功后再纳入轮询 - 对 WebSocket 或长连接业务，务必启用
proxy_http_version 1.1和proxy_set_header Connection ""，并调大proxy_read_timeout，防止连接被代理层误断
配套机制缺一不可
单靠修改 weight 或 reload 不足以保证平滑：
- 后端服务必须支持 draining：收到 SIGUSR2 或 /drain 接口调用后，拒绝新请求，但保持已有连接直到自然结束
- 会话状态不能绑定进程：登录态、上下文等必须存 Redis 或 DB，禁止用内存 session 或 ip_hash；推荐透传 token（
proxy_set_header X-Auth-Token $arg_token），由后端统一恢复 - 多台 Nginx+Keepalived 节点间配置需统一：upstream 列表、健康检查参数、超时设置必须一致，否则 reload 后各节点行为不一致，引发流量倾斜或 502
- 错峰 reload：若有多台 Nginx 节点，避免同时 reload，应按秒级间隔依次执行，防止瞬时大量新连接冲击后端
验证与可观测性建议
替换过程中需实时确认效果：
- 用
nginx -T查看当前生效配置，确认 upstream 中目标节点状态（up/down）、weight 值是否符合预期 - 通过
stub_status或 Prometheus + nginx-vts-exporter 监控各 upstream server 的 request count、response time、fails 数量变化趋势 - 模拟客户端持续请求，观察日志中 backend IP 分布是否随权重调整同步变化，且无 502/504 或连接重置
- 手动 kill 一台 Nginx 进程，验证 Keepalived 是否在 1–3 秒内完成 VIP 漂移，且业务请求无明显中断
