必须将upstream定义在http块顶层，location通过proxy_pass http://upstream_name精准绑定，权重仅在upstream内生效；错误地嵌套在server或location中将导致语法错误或权重失效。
要让某个接口（比如 /api/v1/query）走带权重的负载均衡，核心不是在 location 里写 upstream，而是把 upstream 定义在 http 块顶层，再用 proxy_pass 精准指向它。权重只在 upstream 内生效，location 只负责“路由到哪个 upstream”。
upstream 必须定义在 http 块顶层
这是硬性要求，Nginx 启动时会预加载 http 块下的 upstream 列表。如果写在 server 或 location 里，直接报错或权重完全无效。
- ✅ 正确位置：
http { upstream api_read { server 10.0.1.10:8000 weight=4; server 10.0.1.11:8000 weight=1; } } - ❌ 错误写法：
server { location /api/ { upstream api_read { ... } } }（语法非法） - 权重是正整数，默认为 1；不用归一化，Nginx 自动按比例算流量占比
用 proxy_pass 绑定特定接口和 upstream
location 的作用是匹配请求路径，然后通过 proxy_pass http://upstream_name 把流量交给对应 upstream 处理——这才是实现“特定接口权重分发”的关键动作。
- ✅ 正确写法：
location /api/v1/query { proxy_pass http://api_read; }（注意http://前缀） - ❌ 错误写法：
proxy_pass http://10.0.1.10:8000;（绕过 upstream，权重失效） - ❌ 错误写法：
proxy_pass api_read;（缺协议头，Nginx 当作域名直连） - 路径结尾斜杠影响重写：不加
/会保留原始 URI，加了会截掉匹配前缀
不同接口可配不同 upstream 实现细粒度控制
你可以为高并发接口、管理接口、文件上传等分别定义专用 upstream，各自设不同权重和节点，避免“一刀切”。
- 例如：
upstream api_read { server 10.0.1.10:8000 weight=4; server 10.0.1.11:8000 weight=1; } - 再定义：
upstream api_admin { server 10.0.1.20:8000 weight=1; } - 然后分别绑定：
location /api/v1/query { proxy_pass http://api_read; }和location /api/v1/admin { proxy_pass http://api_admin; }
配套建议提升生产可用性
光有 weight 不够稳，建议同步加健康检查和透传头，让系统更健壮、问题更好排查。
- 每个 server 加上
max_fails=2 fail_timeout=30s，自动屏蔽故障节点 - 设置
proxy_set_header Host $host;和X-Real-IP $remote_addr;，保留原始请求信息 - 需要灾备能力？加
backup标识备用机；临时下线？用down - 注意：ip_hash、least_conn 等算法与 weight 不能共存，选一个主策略
