权重调优需使流量分配匹配后端真实承载能力，weight是相对份额而非百分比，未声明默认为1、weight=0临时下线；调优前须验证处理能力、连接配置及会话依赖，并避免与ip_hash混用。
权重比例调优不是简单调大数字，而是让流量分配与后端真实承载能力对齐。调得准，转发成功率自然上升；调偏了，反而会把请求推向响应慢、错误多的节点。
看懂 weight 的真实含义
weight 不是百分比，而是相对份额。比如 server A weight=4、server B weight=1，理想状态下 A 承担约 80% 流量，B 承担约 20%。但这个比例只在高并发、长周期下趋近稳定；单次或低流量时可能不均。未声明 weight 的节点默认为 1，weight=0 表示临时下线，不参与分发。
调优前必须验证三件事
- 后端处理能力是否匹配：不能只看 CPU 或内存空闲率，重点看 P95 响应时间（RT）和错误率。一台 weight=5 但 RT 经常超 2s 的服务，不如 weight=3 且 RT 稳定在 120ms 的节点可靠。
-
连接与超时配置是否一致：各 upstream server 的
max_fails、fail_timeout、proxy_read_timeout等需统一。否则某台节点因超时被频繁剔除，权重再高也分不到流量。 -
是否存在会话或缓存依赖：若业务强依赖本地 session、临时文件或内存缓存，直接按 weight 轮询会导致状态丢失或数据不一致。这种场景应优先用
ip_hash或 cookie sticky，而非硬调权重。
小步快跑的动态调优方法
生产环境建议“可观测 → 小步调 → 持续验”：
- 用
nginx -T | grep upstream确认当前权重配置，配合curl -I http://x.x.x.x/health检查各节点健康状态； - 首次调整建议倍数微调，例如从 weight=2→4 或 3→5，避免从 1 直接跳到 10 导致抖动；
- 上线后紧盯 5–10 分钟内指标：各节点请求数、
$upstream_response_time、5xx 错误率； - 通过自定义
log_format记录$upstream_addr和$upstream_status，便于回溯哪台机器实际承接了失败请求。
避开常见陷阱
weight 和 ip_hash 不能混用——Nginx 会忽略 weight，强制按 IP 哈希路由；least_conn 场景下 weight 仅影响初始选择，后续仍以活跃连接数为准；灰度发布时，不要靠 weight 做全量切换，而应结合 split_clients 或 Lua 控制精准比例。
