nginx反向代理多副本调度需配置upstream块并结合健康检查与算法选择：默认轮询，可配weight、least_conn、ip_hash或一致性哈希；启用主动health_check实现秒级故障摘除；须正确传递x-real-ip、host、x-forwarded-proto等头信息。
处理 Nginx 反向代理中后端应用的多副本调度，核心在于合理配置 upstream 块并结合健康检查与调度策略，让请求被动态、可靠地分发到可用实例上，而不是简单“堆机器”。
明确 upstream 定义与基础调度方式
所有后端副本必须统一归入一个 upstream 组，Nginx 才能对其做集中调度。该块需放在 http 上下文中，不能嵌套在 server 内：
- 每个
server行代表一个后端地址（IP 或域名），支持端口、路径和参数 - 默认使用轮询（round-robin）：请求按顺序依次打到各副本，适合性能相近、状态无依赖的服务
- 若副本能力差异大，用
weight显式分配流量比例，例如server 192.168.1.10:8000 weight=3和server 192.168.1.11:8000 weight=1表示前者承担约 75% 请求
根据业务特征选择合适调度算法
轮询不是万能解。AI 推理、长时任务或会话敏感类服务需要更精细的决策逻辑：
- least_conn：适用于响应时间波动大的场景（如混合简单/复杂推理请求），优先发往当前活跃连接数最少的副本，缓解排队阻塞
- ip_hash：保证同一客户端 IP 的请求始终落到同一台后端，适合有本地缓存或未做状态分离的应用（注意 IPv6 或 NAT 环境下可能失准）
- hash $request_uri consistent：对 URL 做一致性哈希，适合静态资源或幂等查询类接口，提升缓存命中率
- 不建议盲目用
random，除非后端完全无状态且实例数稳定；它缺乏可预测性，不利于问题追踪
让调度真正“智能”：启用主动健康检查
仅靠 max_fails + fail_timeout 的被动探测不够——Nginx 默认只在请求失败时才标记节点异常，已故障的实例仍可能被轮到一次才下线。
- 添加
health_check指令（需开启ngx_http_upstream_health_check_module，通常在较新版本中默认编译） - 配置定期 GET 某个轻量健康端点（如
/healthz），设超时、间隔与失败阈值，实现秒级故障发现与自动摘除 - 搭配
backup参数可定义备用节点，主集群全宕时自动切流，避免服务中断 - 对于容器化环境，建议后端服务暴露标准就绪探针（ready probe），Nginx 健康检查与其对齐
避免常见陷阱：连接与头信息处理
调度正确只是第一步，请求抵达后端后能否被正确识别和处理，取决于代理层是否传递关键上下文：
- 务必设置
proxy_set_header X-Real-IP $remote_addr和X-Forwarded-For $proxy_add_x_forwarded_for，否则后端日志和限流策略将丢失真实客户端 IP - 添加
proxy_set_header Host $host，防止后端因 Host 头缺失或错误而返回 404 或跳转异常 - 若后端是 HTTPS 服务或需协议感知，补上
X-Forwarded-Proto $scheme，避免重定向循环或混合内容警告 - 对长连接或流式响应（如 SSE、gRPC-Web），需调整
proxy_buffering off、proxy_http_version 1.1和proxy_set_header Connection ''
