最简单有效的应对硬件差异方式是在upstream块中为每台后端服务器设置weight值，需写在server行后，仅接受正整数，应反映真实吞吐或cpu能力比，并配合健康检查与slow_start等机制确保实效。

直接在 upstream 块里给每台后端服务器设 weight，是最简单也最有效的应对硬件差异的方式。它不改架构、不装模块，把 CPU 核心数、压测 QPS 或实际吞吐比，变成一行可读、可调、可验证的整数。

权重必须写在 upstream 的 server 行里

这是硬性语法要求，写错位置 Nginx 会直接报错：

• ✅ 正确：在 upstream 内，紧挨 server 地址后写 —— server 192.168.1.10:8080 weight=5;
• ❌ 错误：写在 location 或 proxy_pass 附近，Nginx 提示 unknown directive "weight"
• ❌ 错误：绕过 upstream，直接 proxy_pass http://192.168.1.10:8080，weight 完全不生效

数值要反映真实能力，别靠感觉

weight 不是百分比，也不是小数，它是相对比例，且只接受正整数：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 新服务器吞吐 1200 QPS，旧服务器只有 300 QPS → 吞吐比 4:1 → 设 weight=4 和 weight=1
• 三台机器 CPU 分别为 16C、8C、4C → 粗略按核数比设 weight=4、weight=2、weight=1
• 避免用太小的数（如 1 和 2），推荐统一放大——10:4:2 比 5:2:1 更易对齐流量，也更利于后续微调

必须配健康检查，否则权重再准也没用

weight 只管“正常时怎么分”，不管“出问题了怎么办”。没健康机制，慢节点照样收请求：

• 每个 server 行加上 max_fails=3 fail_timeout=30s：连续 3 次超时或 5xx 就暂停转发，30 秒后自动试探恢复
• 故障期间，剩余健康节点会按各自 weight 归一化重分流量（比如原 5:3:2，C 下线后 A/B 实际承接比变为 5:3）
• 新节点上线建议加 slow_start=30s，让流量从零缓慢爬升，防冷启动打满

按路径或特征做分流，补足 server 级权重的不足

当一台机器跑多个服务，或接口资源消耗差异大时，单靠 server 权重不够精细：

• 用 location 拆 upstream：用户中心走 user_backend，订单服务走 order_backend，互不抢资源
• 高并发缓存类接口（如商品详情）可单独指向一组高权重缓存节点
• 避免和 ip_hash 或 hash $request_uri 混用——这些策略会覆盖 weight 的分配逻辑

不复杂但容易忽略：改完记得 nginx -t 验证语法，再 nginx -s reload；用日志里的 $upstream_addr 字段统计实际分发，比理论值更重要。