upstream块必须定义在http上下文中，不可置于server或location内；需唯一命名并在proxy_pass中正确引用，仅写名称不带路径或端口；默认被动健康检查不足，需配合proxy_next_upstream等参数增强容错。

upstream 块必须定义在 http 上下文中

nginx 的负载均衡核心是 upstream 模块，但它不能写在 server 或 location 块里。常见错误是把 upstream 直接塞进 server 中，导致 nginx -t 报错：unknown directive "upstream"。

• upstream 必须放在 http 块内（通常在 /etc/nginx/nginx.conf 的 http { ... } 区域）
• 每个 upstream 需要唯一名称，比如 backend_servers，后续在 proxy_pass 中引用
• 不支持在 if 或 map 中动态定义 upstream，运行时不可变

proxy_pass 指向 upstream 名称而非 URL

配置反向代理时，proxy_pass 的值如果是 upstream，必须只写名称，不能带协议或路径，否则会退化为普通代理，失去负载均衡能力。

• ✅ 正确：proxy_pass http://backend_servers;
• ❌ 错误：proxy_pass http://backend_servers/;（末尾斜杠触发重写逻辑，可能丢路径）
• ❌ 错误：proxy_pass http://backend_servers:8080;（端口会被忽略，且语法非法）
• 注意：如果 upstream 中某台服务器指定了端口（如 192.168.1.10:3000），则无需在 proxy_pass 中重复

健康检查不能靠默认 passive 检测兜底

nginx 开源版默认只做 passive 健康检查（即仅在请求失败时标记服务器为 down，超时后自动尝试恢复），它不主动探测后端是否存活。这意味着：一台进程已僵死但端口仍通的服务器，会持续接收流量，直到首次请求超时。

• 启用主动检查需使用 nginx-plus 或开源版配合第三方模块（如 nginx-upstream-check-module）
• 开源常用折中方案：严格设置 proxy_next_upstream，例如：proxy_next_upstream error timeout http_500 http_502 http_503;
• max_fails=2 fail_timeout=10s 是合理起点，避免因瞬时抖动频繁摘除节点
• 别忽略 proxy_read_timeout 和 proxy_connect_timeout，它们直接影响失败判定节奏

http {
    upstream backend_servers {
        server 192.168.1.10:3000 max_fails=2 fail_timeout=10s;
        server 192.168.1.11:3000 max_fails=2 fail_timeout=10s;
        keepalive 32;
    }

    server {
        listen 80;
        location / {
            proxy_pass http://backend_servers;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_next_upstream error timeout http_500 http_502 http_503;
            proxy_connect_timeout 5s;
            proxy_read_timeout 10s;
        }
    }
}