核心是采用动态 upstream 替代硬编码 ip：k8s 环境用 ingress-nginx 自动监听 endpoint 变更；非 k8s 环境用 consul + nginx-upsync-module 主动拉取健康实例；辅以健康检查、proxy_next_upstream 容错及自动化 reload 流程。
要让 Nginx 应对后端服务器动态扩容，核心是摆脱静态 IP 列表，转向“自动感知 + 热更新 + 容错分发”的组合能力。手动改配置再 reload 不仅易出错，还难以跟上容器或云环境秒级伸缩节奏。真正可行的方案，得从配置结构、健康协同、流量调度三方面入手。
用动态 upstream 替代硬编码 server
静态写死 IP 是动态扩容的最大障碍。必须把后端节点交给外部系统管理：
- Kubernetes 环境直接用 ingress-nginx 控制器——它原生监听 Service 和 Endpoint 变更，Pod 新建后几秒内就自动纳入 upstream，零配置干预
- 非 K8s 场景推荐 Consul + nginx-upsync-module：后端启动时注册到 Consul，Nginx 主动拉取健康实例列表，自动增删 server 行，无需 reload
- 轻量级过渡可采用 consul-template：监听 Consul 服务变化，自动生成 /etc/nginx/conf.d/upstream.conf，并触发安全 reload（需确保原子性）
- 若暂无服务发现，至少将 upstream 单独抽成独立文件，扩容时只改这一处，降低主配置污染风险
健康检查与渐进式流量接入
新节点上线不是“一加即用”，必须配合状态协同，避免冷启动冲击：
- 在 upstream 中为每个 server 设置 max_fails=2 fail_timeout=15s，防止短暂抖动误判下线
- 新节点初始设低权重（如 weight=1），老节点保持高权重（如 weight=10），再通过脚本分阶段调权（1→3→6→10），每轮 reload 间隔 5 分钟
- 后端暴露 /health 接口，配合 readiness probe 返回 200 后，才被服务发现系统纳入流量；缩容前先标记 draining，Nginx 配合 max_fails=0 fail_timeout=0 停止派发新请求
代理层容错与长连接适配
扩缩容瞬间常伴随超时、502/503，Nginx 必须能自动绕过失败并保活已有连接：
- 在 location 块中启用 proxy_next_upstream error timeout http_502 http_503 http_504，请求失败时自动重试其他健康节点
- WebSocket 或流式响应场景，必须设置 proxy_http_version 1.1、proxy_set_header Connection ""，并把 proxy_read_timeout 设为客户端心跳周期的 1.5 倍（如 ping/pong 每 30 秒，则设为 90）
- 避免使用 ip_hash 做会话保持——扩容会导致哈希重分布；改用 cookie hash，或后端统一存 session 到 Redis
把配置变更纳入自动化流水线
扩容动作不能脱离发布节奏，必须和 CI/CD 对齐：
- 在 Jenkins/GitLab CI 中，应用部署成功后，自动触发服务发现刷新（如 curl Consul API）或 upstream 配置生成任务
- Docker 场景下，由 registrator 或 consul-template 监听容器启停事件，实时更新 Nginx 配置
- 每次变更前执行 nginx -t 校验语法；reload 使用 systemctl reload nginx 或 nginx -s reload，确保热加载不中断连接
