Nginx中weight用于按服务器真实处理能力分配流量，须写在upstream的server行后，配合健康检查、least_conn等策略实现精细化负载均衡。
用 weight 分配后端流量，核心是让请求比例匹配服务器真实处理能力，而不是平均摊派或凭经验拍脑袋。
权重必须写在 upstream 的 server 行里
weight 只在 upstream 块中生效，且只能紧接在 server 地址后面：
- ✅ 正确写法：
server 192.168.1.10:8080 weight=5; - ❌ 错误写法：把 weight 写在 location 或 proxy_pass 附近，Nginx 会报
unknown directive "weight" - ❌ 错误写法：直接
proxy_pass http://192.168.1.10:8080，绕过 upstream，weight 完全不生效
数值要反映真实能力，别靠猜
weight 是相对比值，不是百分比，也不接受小数。设得准，才能避免“新机空转、老机打满”：
- 压测每台机器的稳定吞吐量（如 wrk 测出 A 能扛 1500 req/s，B 是 500 req/s），按 3:1 设
weight=3和weight=1 - 硬件差异明显时，可先按 CPU 核数粗估（16C vs 4C → 4:1），再结合压测微调
- 避免用太小的数（比如 1 和 2），统一放大——
weight=4; weight=2; weight=1比weight=2; weight=1; weight=0.5更稳妥，也更易对齐实际流量分布
光设 weight 不够，得配健康机制
weight 只管“正常时怎么分”，不管“出问题了怎么办”。没健康检查，故障节点照样收请求：
- 每个 server 行加上
max_fails=3 fail_timeout=30s：连续失败 3 次就暂停转发 30 秒，之后自动试探恢复 - 配合
proxy_next_upstream error timeout http_500 http_502 http_503 http_504，请求失败时自动切到下一个加权节点 - 新节点上线建议加
slow_start=60s，让流量从零开始缓慢爬升，防冷启动冲击 - 临时下线可用
weight=0，不触发健康检查，适合维护窗口期
单一权重不够时，换更贴近业务的策略
当后端响应时间波动大、接口资源消耗差异明显，或需会话保持时，单靠 server 级 weight 难以精细控制：
- 长耗时任务多（如报表导出、文件上传），搭配
least_conn指令，优先发给当前活跃连接最少的节点 - 不同路径走不同集群：用多个 upstream + location 拆分，比如
/user/走 user_backend，/order/走 order_backend - 需要会话保持（如 PHP Session 未共享），用
ip_hash，但注意它和weight不冲突，只是会覆盖轮询逻辑
