Nginx代理实现后端集群扩容平滑过渡需四步：原子化热重载配置、健康检查自动准入、请求级智能重试、长连接兼容调优；全过程用户无感、系统无抖动。
实现 Nginx 代理在后端集群扩容时的平滑过渡，关键不是等新节点上线后再手动加配置、硬 reload，而是让流量切换自然发生、长连接不中断、失败请求可重试、新旧节点负载均衡有策略。整个过程应用户无感、系统无抖动。
热重载 + 原子化配置更新
扩容本质是往 upstream 中新增 server 行，但必须确保生效方式不影响在线请求：
- 将 upstream 配置单独拆到 /etc/nginx/conf.d/upstream.conf，避免主配置污染
- 每次扩容只修改该文件，用 nginx -t 校验语法，再执行 nginx -s reload
- reload 是原子操作：旧 worker 继续处理存量请求，新 worker 启动后立即参与新建连接分发
- 严禁直接 kill 或 systemctl restart，那会强制断开所有连接
健康检查与自动准入机制
新节点上线 ≠ 立刻承接流量。Nginx 必须能识别真实就绪状态，而非仅靠 IP 可达：
- 在 upstream 中为每个 server 设置 max_fails=2 fail_timeout=15s，避免瞬时超时误判宕机
- 后端服务暴露 /readyz 接口，并在 Consul/K8s 中设为 readiness probe；只有状态变为 passing 后，才被纳入 Nginx 流量池
- 若使用 nginx-upsync-module 或 ingress-nginx，它会自动过滤非 passing 实例，无需人工干预
请求级容错与智能重试
即使新节点刚加入，也可能因初始化未完成而返回错误。Nginx 要兜底，不让单次失败影响用户体验：
- 在 location 块中启用：proxy_next_upstream error timeout http_502 http_503 http_504
- 配合 proxy_next_upstream_tries 3 和 proxy_next_upstream_timeout 10s，控制重试范围和耗时
- 避免使用 ip_hash——扩容会导致哈希环重分布，已有连接被错误打散；改用 cookie hash 或后端统一 Session 存储
长连接与流式响应兼容调优
对 WebSocket、SSE、大文件下载等场景，代理层需保障连接持续有效：
- 设置 proxy_read_timeout 90（建议为心跳周期的 1.5 倍），防止空闲连接被意外关闭
- 必须开启：proxy_http_version 1.1 和 proxy_set_header Connection ''，否则 Keep-Alive 失效
- 后端服务应支持 draining 模式：收到信号后停止接受新连接，但保留已有连接直至自然结束
