轮询模式不区分请求类型，仅按顺序分发，负载是否均衡取决于后端处理各类请求的实际耗时与资源占用是否接近；它在七层代理层面工作，不解析HTTP内容，仅维护服务器索引指针推进调度。
轮询模式本身不区分请求类型，它只按顺序分发请求，不管请求是静态资源、API 接口还是上传文件。它的负载表现是否均衡，取决于后端服务器处理各类请求的实际耗时和资源占用是否接近。
轮询不感知请求内容，只看连接顺序
Nginx 的默认轮询（Round Robin）在七层代理层面工作，但它并不解析 HTTP 方法、URL 路径或请求体内容。它只是维护一个服务器索引指针，每来一个新连接（或新请求，取决于是否启用 keepalive），就推进一位，指向下一个可用的 upstream server。
- GET /api/users 和 POST /upload 不会被分类，都算作“一次请求”参与轮询计数
- 即使某台后端专用于处理大文件上传（耗时长、占内存多），轮询仍会照常把第5、第8、第11个请求分给它
- 没有内置机制跳过正在处理慢请求的节点——轮询调度发生在请求进入 Nginx 的瞬间，而非后端响应完成时
多类型请求下轮询易出现负载倾斜
当后端服务器能力一致但请求类型差异大时，轮询可能造成事实上的不均衡：
- 一台服务器收到连续 3 个视频上传请求（每个耗时 8 秒），而另一台只收到 3 个毫秒级的健康检查 GET 请求
- 静态文件（/static/css/app.css）通常由 Nginx 自行服务，不进 upstream；但若配置了 proxy_pass 到后端，这类高频轻量请求就会和重逻辑 API 共用同一轮询队列
- 无健康检查配合时，某台后端因 GC 卡顿 2 秒，Nginx 仍会继续向其派发新请求，直到超时触发失败重试或 next_upstream 规则
改善多类型请求下轮询表现的实用做法
不改算法，也能让轮询更贴近真实负载需求：
- 用 upstream 健康检查（如
health_check interval=3 fails=2 passes=2）自动剔除临时响应迟缓的节点，避免请求堆积 - 对明显异构的请求路径做 分流 + 独立 upstream：例如把
/api/.*和/upload/.*分到不同 upstream 块，各自轮询，互不影响 - 搭配 weight 参数做粗粒度适配：若某台机器 SSD 更快、更适合处理文件类请求，可将其 weight 设为 2 或 3，提升分配概率
- 开启 proxy_buffering off 和合理设置
proxy_busy_buffers_size，减少 Nginx 自身缓冲对请求排队的干扰
什么时候该换策略，而不是硬撑轮询
如果业务中存在强会话依赖（如登录态）、固定用户需粘性访问、或请求处理时长方差极大（从 10ms 到 30s），轮询就不是最优解：
- ip_hash 适合需会话保持但无 Cookie/Token 控制能力的旧系统
- least_conn 更适合多类型混杂且后端处理能力波动大的场景——它看的是当前活跃连接数，比轮询更贴近实时负载
- 真正需要按请求内容调度（比如 /report/* 走高配集群，/public/* 走 CDN 回源集群），就得靠 多个 location + 多 upstream 显式路由，而非依赖单一轮询逻辑
