nginx权重分发是按配置数值比例分配流量，需在upstream块内server指令中正确设置weight参数，仅对round_robin和ip_hash算法生效，应基于实测p95延迟计算并配合健康检查等机制使用。
权重分发不是让 Nginx “看懂”后端性能，而是用可配置的数值，把流量按比例导向不同节点，前提是这个比例确实反映它们的真实处理能力。配得准，集群吞吐就高、延迟就稳；配错了，高权重点可能被打满，低权重点却闲着。
权重必须写对位置才起作用
weight 参数只在 upstream 块内、server 指令中生效，且必须紧贴 IP 和端口之后：
- ✅ 正确：
server 10.0.0.5:8080 weight=3; - ❌ 错误：写在 location 或 proxy_pass 后面；或单独成行如
server 10.0.0.5:8080;再另起一行weight=3; - ❌ 错误：设为小数（
weight=2.5）、负数或字符串——nginx -t直接报错
只对特定算法有效，别混用
weight 仅在默认的 round_robin 和 ip_hash 下起作用：
- 轮询模式下，weight 决定长期请求概率分布（比如 weight=4 和 weight=1，理论分流比接近 4:1）
- ip_hash 模式下，weight 不影响哈希绑定，只在某节点失效时作为备用选择依据
- least_conn 策略完全忽略 weight，它只看当前活跃连接数；fair、url_hash 等第三方算法也不识别 weight
权重值要基于实测延迟，不是硬件参数
CPU 核心数、内存大小不能直接换算成 weight。真实瓶颈常在 IO、网络或应用逻辑。建议做法：
- 用压测工具（如 wrk）对每台后端做相同负载测试，记录 P95 响应时间
- 选一台基准机（如 P95=100ms），其余节点 weight = 基准 P95 ÷ 自身 P95（四舍五入为正整数）
- 例如：A 机 P95=100ms → weight=1；B 机 P95=200ms → weight=100/200=0.5 → 取整为 1；C 机 P95=50ms → weight=2
- 最大权重比建议控制在 1:4 以内（如 4:2:1），避免高权重点持续承压、低权重点长期闲置
静态配置需搭配运行时机制才可靠
单靠静态 weight 无法应对 GC 停顿、慢查询或网络抖动。必须组合使用：
- 被动健康检查：
max_fails=3 fail_timeout=30s，配合proxy_next_upstream error timeout http_500...，失败后自动切走 - 连接复用：
upstream块加keepalive 32，proxy 区域配proxy_http_version 1.1和proxy_set_header Connection '' - 超时收紧：
proxy_connect_timeout 3s、proxy_read_timeout设为业务 P99 延迟的 1.2–1.5 倍 - 上线后验证：查 access log 统计
$upstream_addr出现频次，观察是否趋近理论比例（数百请求以上才稳定）
