upstream块是Nginx实现高可用后端集群的核心，必须置于http块内，通过server指令定义多节点、配合轮询/weight/ip_hash/least_conn等算法及max_fails/fail_timeout等参数实现负载均衡与自动故障转移。
用 upstream 块构建高可用后端集群，核心是把多个后端节点组织成一个逻辑组，并让 Nginx 主动分发请求、自动规避故障。它不依赖外部工具，纯配置即可实现基础的高可用和负载均衡。
在 http 块中正确定义 upstream 组
upstream 必须放在全局 http 块内，不能嵌套在 server 或 location 里。名称要简洁明确，便于后续引用：
- 每个 server 指令代表一个后端地址，支持 IP:端口、域名、Unix socket 等格式
- 避免只写一个 server：Nginx 对单节点会忽略 max_fails/fail_timeout，健康检查失效
- 若需长期维护某节点，加 down 参数；临时下线但保留配置，可用 backup 标记
选择合适的负载策略并合理设置参数
默认轮询适合均质节点，但生产环境常需更精细控制：
- 性能差异大时用 weight：比如 server 192.168.1.10:8080 weight=5; 分担更多流量
- 需要会话保持（如登录态）时启用 ip_hash，注意它与 weight 冲突，且故障转移后用户可能重连
- 连接数敏感型服务（如长连接网关）优先 least_conn，新请求自动导向最空闲节点
- 所有策略都可叠加 max_fails 和 fail_timeout，例如 max_fails=2 fail_timeout=20s 表示 20 秒内失败 2 次即剔除该节点
通过 proxy_pass 关联 upstream 并透传关键头信息
server 块中用 proxy_pass 调用 upstream 名称，必须带协议前缀且结尾不加斜杠（除非后端路径有特殊约定）：
- 务必设置 proxy_set_header Host $host，否则后端可能无法识别原始域名
- 添加 X-Real-IP 和 X-Forwarded-For，确保后端日志和权限判断基于真实客户端 IP
- HTTPS 场景下补上 X-Forwarded-Proto $scheme，让后端知道原始请求是 http 还是 https
- 如后端支持长连接，可配 keepalive 32 + proxy_http_version 1.1 + Connection “” 提升复用率
验证与持续观察集群状态
配置生效后不能只看是否能访问，要确认分发逻辑和容错机制真实起作用：
- 用 curl -I 访问多次，检查响应头中的 Server 或 X-Powered-By 是否来自不同后端，确认轮询生效
- 手动停掉一台后端服务，观察请求是否在 fail_timeout 后自动转向其余节点，且无明显报错
- 查看 Nginx error.log，搜索 upstream timed out 或 failed to connect，确认健康检查触发准确
- 配合 access_log 的 $upstream_addr 字段，可直接记录每次请求实际转发到哪台机器
