Upstream本身不参与VIP漂移，仅负责在持有VIP的Nginx节点上将流量转发至后端服务；主备Nginx的upstream配置必须完全一致（包括名称、server列表、权重等参数），且为静态配置、不感知VIP变化，其核心价值在于确保VIP漂移后服务逻辑无缝延续。
Upstream 本身不参与 VIP 漂移，它只负责后端服务器的负载分发；真正实现主备高可用的是 Keepalived + VIP 机制。Upstream 的作用是在 当前持有 VIP 的那台 Nginx 节点上，把流量合理转发给后端服务（如 Tomcat、PHP-FPM 等）。只要主备两台 Nginx 的 upstream 配置完全一致，VIP 漂移后，新接管的节点就能无缝继续提供相同逻辑的服务。
Upstream 必须主备完全一致
若主节点 upstream 指向 192.168.1.20 和 192.168.1.21，而备节点误配成 192.168.1.30 和 192.168.1.31，VIP 漂移后用户请求将打到错误后端，直接导致业务异常。
- 两台 Nginx 的
upstream块名称、server 列表、权重、max_fails、fail_timeout 等参数必须逐字相同 - 建议用统一配置模板部署，避免手工编辑差异
- 可加注释标明“此 upstream 供 VIP:192.168.1.100 对外服务使用”，增强可维护性
Upstream 不需要感知 VIP 漂移
Upstream 是静态配置，不依赖本机 IP 或 VIP。它只在 Nginx worker 进程启动时加载一次，运行中不会因 VIP 变动而重载或失效。只要 Nginx 进程正常、配置未改，upstream 就持续生效。
- VIP 漂移前后，Nginx 进程本身不重启，upstream 连接池和健康检查状态也保持延续（前提是 keepalive 和 proxy_next_upstream 配置得当）
- 无需在 upstream 中写 VIP 地址，也不用做任何“漂移适配”逻辑
- 真正需要响应漂移的是 Keepalived 的 vrrp_script 健康检查——它确保 Nginx 崩溃时主动触发降权，让 VIP 离开故障节点
典型配合结构：VIP → 当前活跃 Nginx → Upstream → 后端集群
客户端始终访问 VIP（如 192.168.1.100），该地址只绑定在当前主节点网卡上。该节点上的 Nginx 收到请求后，按本地 upstream 定义选择后端服务器。备节点虽然也运行着一模一样的 Nginx 和 upstream，但因无 VIP，对外不响应 HTTP 请求。
- upstream 中可启用
ip_hash或sticky实现会话保持，只要主备配置一致，漂移后用户会话不会因 backend 变更而中断（前提是后端共享 session） - 推荐搭配
proxy_next_upstream error timeout http_502;，提升单点 Nginx 对后端异常的容错能力 - 若后端有读写分离或灰度路由需求，upstream 可配合 map 或 split_clients 实现，但这些逻辑仍由当前持有 VIP 的 Nginx 独立执行
不复杂但容易忽略：Upstream 是能力复刻的关键，不是漂移组件，它的价值在于让两台机器“看起来完全一样”。
