权重参数不直接调控流量，而是让Nginx在轮询中按相对比例分发请求；需满足后端健康、配置生效等前提，且必须写在upstream的server行内，配合健康检查、least_conn等机制才有效。
权重参数本身不直接“调控流量”，而是让 Nginx 在轮询过程中按相对比例分发请求。它起作用的前提是：后端节点健康、连接策略合理、配置生效且可验证。单纯改 weight 数值，若脱离运行时状态和可观测性，容易适得其反。
权重必须写在 upstream 的 server 行里
weight 只在 upstream 块中有效，且必须紧跟 server 地址之后：
- ✅ 正确：
server 192.168.1.10:8080 weight=4; - ❌ 错误：
server 192.168.1.10:8080; weight=4;（语法无效） - ❌ 错误：
proxy_pass http://backend; weight=2;（weight 不属于 location 上下文）
权重默认为 1；设为 0 表示该节点不参与分发，但仍接受健康检查探测。
权重值不是百分比，而是相对份额
两台服务器 weight=3 和 weight=1，理论请求比是 3:1，即约 75% 和 25% —— 这个比例需在数百次以上请求中统计才稳定。小流量下可能出现连续打到同一台的情况，属正常行为。
- 避免用过大的数（如 100 和 1），易放大偏差；推荐控制在 1–10 范围内，例如 5:3:2
- 所有未声明 weight 的 server 默认为 1，无需补全
- weight=0 不等于 down：它仍被健康检查访问，只是不接流量；真正强制摘除要用
down
权重只是起点，必须搭配运行时机制
静态 weight 无法响应 CPU 突增、慢查询或 GC 停顿。真实可用的配置需组合以下要素：
-
健康检查：加
max_fails=3 fail_timeout=30s，失败后自动隔离，恢复后试探重入 - least_conn：在 upstream 块开头加上该指令，优先选当前活跃连接最少的节点，缓解长耗时请求堆积
-
连接复用：upstream 内配
keepalive 32，proxy 区域启用 HTTP/1.1 和空 Connection 头 -
超时收紧：如
proxy_connect_timeout 3s、proxy_read_timeout 8s，防慢响应阻塞连接池
上线后必须验证并迭代优化
reload 后不能只看 Nginx 是否启动成功，要确认真实效果：
- 查 access log：
awk '{print $NF}' /var/log/nginx/access.log | sort | uniq -c | sort -nr，观察各后端 IP 出现频次是否趋近理论比例 - 监控每台后端的 P95 延迟、活跃连接数、CPU 使用率；若某台负载明显偏高但权重未超标，说明其应用存在瓶颈，需单独优化
- 权重不是一劳永逸：硬件升级或部署变更后，应重新压测并微调，比如 SSD 升级后延迟下降 30%，weight 可提升 1～2 点
