直接调高weight参数不提升吞吐量，关键在于按后端真实能力精准分配权重并动态校准：静态权重可依CPU核数×内存GB数粗估，建议最大比值≤3:1；需结合健康检查、实时指标（如P95延迟）及长连接优化协同生效。
直接调高 weight 参数本身不会提升吞吐量，真正起作用的是让流量更合理地落在能承载它的后端上。权重只是调度策略的表达方式，关键在“配得准”和“跟得上”——既要基于真实能力设定初始值，又要能随运行状态动态校准。
按硬件能力设静态权重
这是最基础也最有效的起点。当后端服务器配置差异明显时，硬编码权重比默认轮询更能压满资源：
- 用 CPU 核数 × 内存 GB 数粗略估算相对处理能力，比如 16C/64G 与 8C/32G 的比值约是 2:1，对应 weight 可设为 4 和 2
- 避免权重差距过大（如 10:1），否则小权重节点长期空转，大权重节点易成瓶颈；建议最大比值控制在 3:1 以内
- 上线前做基准压测：单独对每台后端打固定并发，记录稳定 RPS 和平均响应时间，再按 RPS 比例反推 weight 分配
用健康检查联动权重调整
静态权重跑一段时间后会失效。Nginx 自带的健康检查不改权重，但可配合外部动作触发重载或模块更新：
- 启用 active health check：在 upstream 中加
health_check interval=5 fails=3 passes=2，探测路径返回 200 才视为可用 - 结合 max_fails/fail_timeout：某节点连续失败 3 次后自动摘除，等 30 秒再试探恢复——这虽不改 weight，但等效于临时将其权重归零
- 若使用 nginx-upstream-dynamic-servers 模块，可通过 API 把健康检查结果映射为 weight=0 或 weight=1，实现软摘除
接入实时指标做动态权重
吞吐量瓶颈常出现在响应慢、错误多、连接堆积的节点上。靠人工调 weight 落后于问题发生，需系统自动响应：
- 用 OpenResty + Lua 在内存中维护各节点 P95 延迟和 5xx 错误率，每 3 秒更新一次，再用公式
weight = base × (100 / actual_p95)^1.5实时重算 - 用 nginx-upsync-module 对接 Consul，由 sidecar 定期上报 CPU 使用率和请求延迟，写入 KV 的 weight 字段，Nginx 每 300ms 拉取生效
- 所有动态方案必须配套日志验证：access_log 中固定记录
$upstream_addr $upstream_response_time $upstream_http_x_backend_id，确认权重变化后流量确实转向了更快节点
别忽略上下游连接效率
权重再准，如果连接反复新建或卡在中间环节，吞吐量照样上不去：
- 客户端到 Nginx 启用 keepalive：
keepalive_timeout 65; keepalive_requests 10000; - Nginx 到后端必须开长连接：
upstream xxx { keepalive 32; }，并配proxy_http_version 1.1;和proxy_set_header Connection ""; - 后端服务的 keep-alive timeout 要比 Nginx 的
proxy_read_timeout大至少 5 秒，防止连接被单边断开
