weight参数实现加权轮询而非平均分发，按相对份额分配流量（如3:7），非百分比；weight=0临时下线，未声明则默认为1；调优需验证后端能力、连接配置与会话依赖，并避免与ip_hash混用。

在Nginx负载均衡中，weight参数是控制后端服务器流量分配比例的核心手段。它不等于“平均分发”，而是按权重值做加权轮询（weighted round-robin），理解其真实行为和调优逻辑，比盲目设置数字更重要。

weight的本质：不是百分比，而是相对份额

Nginx不会把weight直接换算成百分比。比如两台服务器：server1 weight=3、server2 weight=7，实际请求分配比例是 3:7，即 server1 承担约 30%，server2 约 70%。但注意：这个比例只在长周期、高并发下趋近理想值；单次或低流量场景可能出现偏差。

• weight=0 表示该节点不参与负载，常用于临时下线维护
• 所有未显式声明 weight 的 upstream server，默认 weight=1
• weight 值没有上限，但建议控制在 1–100 范围内，便于计算和协作理解

调优前必须确认的3件事

盲目调高某台机器的 weight 可能适得其反。动手前先验证：

• 后端真实处理能力是否匹配？ 查看 CPU、内存、磁盘 I/O 和应用响应时间（如 P95 RT）。一台 weight=5 但 RT 长达 2s 的服务，不如 weight=3 且 RT 稳定 100ms 的节点可靠
• 连接复用与超时是否一致？ upstream 中 keepalive、proxy_timeout、max_fails、fail_timeout 等参数需协同调整，否则 weight 再合理也会被频繁剔除
• 是否有会话粘性（sticky）或缓存依赖？ 若业务强依赖本地 session 或文件缓存，单纯靠 weight 分流可能引发数据不一致，此时应优先考虑 ip_hash 或 sticky cookie

动态调优的实操建议

静态 weight 设置适合稳定环境，但生产中更推荐“可观测→小步调→持续验”的节奏：

• 用 nginx -T | grep upstream 检查当前配置，配合 curl -I http://upstream-ip/health 确认各节点健康状态
• 首次调整建议以倍数关系微调，例如从 weight=1→2 或 3→5，避免跳变过大导致抖动
• 上线后紧盯 5–10 分钟内的指标：各节点请求数（$request_number）、响应时间（$upstream_response_time）、错误率（$upstream_status ≥ 500）
• 可配合 log_format 自定义日志字段，记录 upstream_name 和 chosen_server，便于回溯分流路径

常见误区与规避方式

很多线上问题源于对 weight 的误用：

• “weight 越大越快” —— 错。weight 只影响调度频次，不加速单个请求。性能瓶颈在后端，不在 Nginx 分发逻辑
• 混用 weight 和 ip_hash —— 不兼容。ip_hash 会覆盖 weight，此时权重失效，所有同 IP 请求固定打到同一台
• 忽略 max_fails 导致“假健康”。某节点因瞬时过载返回大量 502，若 max_fails=1 且 fail_timeout=10s，它可能刚恢复就被反复踢出，weight 再高也无意义