核心是通过upstream块定义服务器组，配置weight、max_fails/fail_timeout、backup/down等参数实现容错与流量控制，并结合proxy_pass完成转发；需按业务选轮询、ip_hash、least_conn或consistent_hash等算法，主动健康检查需第三方模块或Nginx Plus。
用 ngx_http_upstream_module 实现高并发流量调度，核心是把后端服务组织成可管理、可容错、可伸缩的服务器组，并通过合理算法和参数控制请求分发行为。它不是单纯“加机器”就能扛住流量，而是靠配置逻辑让 Nginx 主动识别状态、避开故障、平衡压力。
定义健壮的 upstream 服务器组
必须把后端节点放进 upstream 块中，且放在 http{} 上下文里。一个典型配置需包含基础地址、权重、容错参数和状态标识：
-
server 地址支持多种格式：IP:端口（如
192.168.1.10:8080）、域名（如api-v2.internal）、Unix socket（如unix:/var/run/backend.sock） -
weight 控制分配比例：比如新机器性能强，设为
weight=5；旧机器设为weight=1，Nginx 就按 5:1 分配请求 -
max_fails + fail_timeout 组合防雪崩：例如
max_fails=3 fail_timeout=30s表示连续失败 3 次后，30 秒内不再转发请求给该节点 -
backup 和 down 用于运维场景：灰度发布时用
down临时下线某台；灾备可用backup预留一台低负载备用机
选对调度算法，匹配业务特征
算法不是越智能越好，要结合实际链路特性选择：
- 轮询（rr）或权重轮询（wrr）：适合无状态服务、短连接、后端响应时间较均衡的场景，也是默认行为，开箱即用
- ip_hash：适用于需要会话粘性的老系统（如 PHP+Session 文件），但注意 NAT 环境下易导致单点过载
- least_conn：适合长连接或响应时间差异大的服务（如 WebSocket、文件上传），优先分发到当前连接数最少的后端
- hash $request_uri consistent：缓存类服务（如静态资源、API 结果缓存）推荐用一致性哈希，避免节点增减时大量缓存失效
配合 proxy_pass 完成真实转发
upstream 只是定义“谁来干活”，真正把请求送出去靠 proxy_pass。关键细节包括：
-
必须用 http:// 或 https:// 协议前缀：写成
proxy_pass http://backend_servers;，不能漏掉http:// -
避免缓存干扰调度：如果启用了
proxy_cache，命中缓存时根本不会走 upstream，也就没有负载均衡效果，调试时建议先关缓存 -
透传客户端信息不可少：加上
proxy_set_header X-Real-IP $remote_addr;和X-Forwarded-For，否则后端看不到真实 IP -
超时与重试要设合理值：比如
proxy_connect_timeout 5s;、proxy_next_upstream error timeout http_502;，防止卡死或错误传播
动态扩缩容与健康检查进阶
纯静态配置在云环境或容器化部署中不够灵活，需结合外部机制：
-
resolve 参数支持 DNS 自动更新：当 server 写的是域名（如
server api-prod.service.consul;），加上resolve后，DNS 记录变更时 Nginx 会自动刷新 IP，无需 reload - 配合 Consul 或 Nacos 做服务发现：用 Lua 脚本或 OpenResty 插件定期拉取服务列表，动态生成 upstream 配置
-
主动健康检查需第三方模块：Nginx 开源版只支持被动检测（靠失败计数），如需 HTTP 探针（GET /health），得用 nginx-plus 或 openresty 的
lua-resty-upstream-healthcheck
