Nginx权重负载均衡按weight整数比（如3:1:2）分配请求，非百分比；需结合CPU、I/O、实测QPS设合理weight，避免过大值，并配max_fails、fail_timeout、slow_start等健康检查参数。
权重值不是百分比，而是相对比例
比如配置：
upstream backend {<br> server 192.168.1.10:8080 weight=3;<br> server 192.168.1.11:8080 weight=1;<br> server 192.168.1.12:8080 weight=2;<br>}实际请求分配比例是 3 : 1 : 2（即约 50% / 16.7% / 33.3%），不是 30% / 10% / 20%。Nginx 的加权轮询算法会按这个整数比循环调度，不四舍五入、不归一化，也不受总和影响。
按真实资源差异设 weight，而非拍脑袋
直接看硬件或监控数据更可靠：
- CPU 核心数差异明显？比如 A 机 16 核、B 机 8 核、C 机 4 核 → weight 可设为 4 : 2 : 1
- 内存带宽或磁盘 I/O 成瓶颈？用
vmstat或iostat观察 avgqu-sz 和 %util，高负载节点适当降低 weight - 应用实测吞吐量（如 QPS）已知？例如 A 服务稳定支撑 1200 QPS、B 为 600、C 为 300 → weight 按 4 : 2 : 1 设更贴近真实承载力
- 避免 weight 过大（如设 100）——容易放大单点故障影响，也削弱调度灵活性
必须配合健康检查，否则权重再准也白搭
光配 weight 不代表流量真能落到可用节点上。建议每台 server 加上容错参数：
-
max_fails=3：连续 3 次探活失败（如 proxy_pass 超时或返回 5xx）即标记不可用 -
fail_timeout=30s：30 秒内不再调度，之后尝试恢复探测 -
slow_start=60s（推荐）：新上线或刚恢复的节点，前 60 秒权重缓慢提升至目标值，防止瞬间洪峰压垮 - 示例：
server 192.168.1.10:8080 weight=3 max_fails=3 fail_timeout=30s slow_start=60s;
验证权重是否生效，不能只看日志时间戳
人工刷浏览器看不出比例，得靠可复现的统计方式：
- 用
ab -n 600 -c 10 http://your-domain/发起 600 次请求，再查各后端 access log 的请求数 - 在后端加统一响应头，如
X-Backend-ID: node-a，用 curl + grep 快速汇总 - 注意：若启用了
keepalive或长连接，单个客户端可能复用连接，影响轮询节奏，测试时建议关闭或用多个 IP 源
