应按资源特征路径识别、能力匹配分组调度、实测带宽设权，将静态资源单独路由至专用upstream；location匹配后proxy_pass指向static_backend，其内节点权重严格按实测带宽比（如10:10:1）配置，并辅以健康检查、keepalive和proxy_buffering off等优化。
让图片等静态资源优先走高带宽节点，不能只靠在 upstream 里调高某台服务器的 weight——权重控制的是“请求分发比例”，不是“资源类型路由”。真正起作用的是：按资源特征做路径识别 + 按能力匹配做分组调度 + 按实测带宽设权。
静态资源必须单独路由到专用 upstream
别把图片、CSS、JS 和 API 请求混在一个 upstream 里轮询。Nginx 不会自动判断“这个请求是图片就该去快机器”，它只认配置规则。
- 用
location匹配静态路径，比如location ~* \.(jpg|jpeg|png|gif|webp|css|js)$ - 把这个 location 的
proxy_pass指向一个专为静态服务设计的 upstream，例如http://static_backend - 这个
static_backend里只放你确认过带宽充足、磁盘 I/O 稳定的节点（比如两台 1Gbps 服务器 + 一台 100Mbps 备份机）
权重必须严格按实测带宽比例设置
静态服务瓶颈几乎全在带宽和并发连接数，CPU 和内存占用极低。拿 CPU 使用率设权，等于无视真实瓶颈。
- 实测三台节点的稳定吞吐：ServerA 920Mbps、ServerB 950Mbps、ServerC 95Mbps → 权重比约为
10:10:1 - 写成：
server 10.0.1.10:8080 weight=10;、server 10.0.1.11:8080 weight=10;、server 10.0.1.12:8080 weight=1; - 每24小时用
$upstream_response_time的 P95 值反向校验一次：如果某节点延迟持续高于均值 2 倍，临时降权或检查网卡/交换机限速
给高带宽节点加健康检查与连接优化
光设权不够，得确保流量真能高效打过去、不被假死节点拖住。
- 每个
server行加上max_fails=2 fail_timeout=10s，连续两次超时或 5xx 就剔除 - 在
static_backendupstream 中启用keepalive 32，复用连接减少握手开销 - 关闭响应体缓冲：
proxy_buffering off;，尤其对大图传输更友好
热度感知可进一步提升效率
热门图片（如首页 banner）反复被请求，冷资源（如旧版本图标）极少回源。轮询不该一视同仁。
- 接入轻量统计（如 Redis HyperLogLog），按 URI 统计 1 小时 UV
- UV > 1000 的资源，用
map+split_clients或 Lua 脚本，强制路由到最高带宽节点（跳过轮询） - UV < 10 的资源，可临时归入低优先级组，避免干扰主链路
