weight参数定义后端服务器相对处理份额而非百分比，如weight=2和3对应流量比2:3（约40%:60%），需结合cpu、内存、i/o及p95响应时间合理设定，并配max_fails、fail_timeout及避免与ip_hash混用。
weight 参数不是设置百分比，而是定义节点间的相对处理份额。比如两台服务器 weight=2 和 weight=3，实际流量比例就是 2:3（即约 40% : 60%），Nginx 会按这个比例做加权轮询，长期高并发下趋近该分布，但单次或低流量请求可能出现抖动。
权重值怎么设才合理
权重应反映后端真实服务能力，而非随意估算：
- 优先参考 CPU 使用率、内存占用、磁盘 I/O 等系统指标，再结合应用层 P95 响应时间（如 RT 稳定在 120ms 的节点，比 RT 波动在 800ms 的 weight=5 节点更可靠）
- 建议把权重控制在 1–100 整数范围内，便于团队协作和后续调整；避免用 95 和 5 这类大数值组合，容易因连接复用或请求批次导致实际偏差放大
- 未声明 weight 的 server 默认为 1，所有权重相加得出总权重，单节点占比 = 本机 weight ÷ 总权重
必须同步检查的配套配置
只调 weight 不够，还要确保上下游行为一致：
- proxy_pass 必须写成 http://upstream_name 格式，不能写死 IP+端口，否则权重完全失效
- 每个 server 行建议补上 max_fails=2 fail_timeout=30s，让 Nginx 主动屏蔽临时异常节点，防止流量持续打到慢节点
- 避免与 ip_hash、hash $request_uri 等 hash 类算法共用，二者逻辑冲突，weight 将被忽略
- 若业务强依赖本地 session 或文件缓存，应改用 cookie 透传等粘性方案，而非仅靠 weight 分流
上线后怎么验证效果
调完不能只看配置生效，要盯住真实分流结果：
- 用 nginx -T | grep upstream 确认当前 weight 值已加载；配合 curl -I http://node-ip/health 检查各节点健康状态
- 自定义 log_format，加入 $upstream_addr 和 $upstream_response_time 字段，抽样分析日志即可看出各节点请求数与响应质量
- 首次调整建议微步进：比如从 weight=3→5，而不是 3→10；上线后紧盯 5–10 分钟内各节点的请求量、错误率（≥500）、平均 RT 变化
灰度与动态场景下的实用技巧
weight 天然适合轻量灰度，也能支撑渐进式迁移：
- 想导 5% 流量给新版本？用 v1 weight=20、v2 weight=1，比 95:5 更稳定，小权重对连接复用更友好
- 临时下线某节点？直接设 weight=0，无需注释或删行，reload 后立即生效
- 主力机与备用机性能差异大？可为主力设 weight=8 max_fails=3 fail_timeout=45s，为备用设 weight=2 max_fails=1 fail_timeout=15s，实现差异化容错
