Nginx upstream 必须定义在 http 块内、名称全局唯一，支持加权轮询、least_conn、ip_hash 等负载算法，并需配置 max_fails/fail_timeout、backup、down 等健康检查参数，再通过 proxy_pass 调用并设置 Host、X-Real-IP 等代理头完成转发。
配置 Nginx upstream 块是构建高性能后端服务集群最直接、最稳定的方式。它不依赖外部组件，原生支持负载分发、健康探测和故障自动规避，是生产环境反向代理与高可用架构的基石。
upstream 必须放在 http 块内，且名称需全局唯一
upstream 不是独立指令，而是 Nginx HTTP 模块的上下文块，只能定义在 http{...} 范围中，不能嵌套在 server 或 location 里。每个 upstream 名称（如 web_cluster 或 api_backend）在整份配置中必须唯一，后续通过 proxy_pass http://名称 引用。
- 错误写法：
server { location / { upstream demo {...} } }—— 语法报错 - 正确结构：所有 upstream 集中写在 http 块开头或末尾，便于统一维护
- 命名建议使用语义化小写+下划线，如 cms_backend、auth_service
合理选择负载算法并设置节点权重
默认轮询适合均质服务器，但真实环境中节点性能、网络延迟常有差异，应主动干预流量分配。
-
加权轮询（weight）：给高性能节点更高权重，例如
server 10.0.1.5:8080 weight=4承担约 4 倍于weight=1节点的请求 - 最少连接（least_conn）：适用于长连接场景（如 WebSocket、gRPC），新请求优先落到当前活跃连接数最少的后端
- IP 哈希（ip_hash）：确保同一客户端 IP 始终路由到固定后端，适合无共享 Session 的传统应用；启用后不可再设 weight
为每个 server 添加健康控制参数
仅靠算法不够，必须让 Nginx 主动识别并隔离异常节点，避免请求打到已宕机或响应超时的服务上。
- max_fails=3 fail_timeout=30s：连续 3 次失败（如 502/504 或超时），则该节点在 30 秒内不再接收新请求
- backup：标记为备用节点，仅当所有非 backup 节点都不可用时才启用，适合灾备或低优先级实例
- down：手动置为不可用，常用于计划内维护，配置重载后立即生效
- 注意：fail_timeout 时间不宜过短（如 60s），影响故障恢复速度
配合 proxy_pass 完成完整转发链路
upstream 定义完只是“声明”，真正起作用要靠 server 块中的 proxy_pass 调用，并补全关键代理头。
- location 中写
proxy_pass http://web_cluster;—— 注意结尾无斜杠，除非后端路径逻辑要求（如需透传 /api/v1/ 则保持一致） - 必须设置
proxy_set_header Host $host;，否则后端可能收不到原始 Host 值 - 推荐加上
proxy_set_header X-Real-IP $remote_addr;和X-Forwarded-For $proxy_add_x_forwarded_for;，便于后端日志和风控识别真实客户端 - 若后端支持长连接，可加
proxy_http_version 1.1;和proxy_set_header Connection "";，再配合 upstream 中的keepalive 32;复用连接
