nginx的weight参数是应对后端服务差异化最直接手段，通过预设静态比例（如5:2）实现流量与服务器能力对齐，需搭配健康检查、避免ip_hash冲突，并配合slow_start等参数提升可靠性。

Nginx 中的 weight 参数是应对后端服务差异化最直接、最常用的手段——它不依赖实时指标，而是基于服务能力预设比例，让流量分配与服务器实际承载能力对齐。

weight 是静态能力映射，不是动态负载感知
它把“这台机器能扛多少”这个业务判断，翻译成 Nginx 可执行的数值指令。比如 A 服务器 CPU 是 B 的 2.5 倍、内存多一倍、压测 QPS 高 3 倍，那 weight 就可设为 5:2，而不是凭感觉写个 3:1。权重生效的前提是：所有节点健康、协议一致、无长连接堆积、未启用 ip_hash 等会话保持策略。

按性能差异设权，而非按数量平均分

Nginx Hosting

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

下载

• 若三台机器配置分别为 16C32G、8C16G、4C8G，合理权重可设为 weight=4; weight=2; weight=1
• 若某台专用于计算密集型任务（如报表导出），而其他两台处理常规 API，可适当调低其 weight，避免突发请求挤占关键资源
• 新上线的高配节点，不要立刻给高 weight，配合 slow_start=60s 让流量逐步爬升，防止冷启动冲击

weight 必须搭配健康机制才可靠
光设权重不够，得确保异常节点不吸流：

• 每个 server 行加上 max_fails=2 fail_timeout=10s，连续失败两次就暂停 10 秒
• 对返回 5xx 或超时的请求主动计数，避免僵死进程仍被轮询
• weight=0 可临时下线节点，且不触发健康检查，适合维护窗口期

别踩这些常见坑

• 权重值过大（如 100）会导致小权重节点长期收不到请求，健康检查失效，日志里看不到它的访问记录
• 修改 weight 后必须 nginx -s reload，不会热生效
• 和 ip_hash、hash $request_uri 一起用时，weight 完全失效——因为请求已按固定规则绑定到某台，不再走轮询逻辑

本质上，weight 解决的是“能力不同该分多少”的问题，不是“现在忙不忙”的问题。它简单、稳定、可预期，适合大多数稳态部署场景。