keepalive_requests 不决定请求均匀度，而是单连接复用次数配额；均匀性由upstream负载算法（如least_conn）与keepalive配置协同决定，设200–3000为宜，避免过小引发频繁建连或过大导致连接粘滞。
keepalive_requests 本身不直接影响请求在后端服务器间的“均匀度”，它控制的是单个长连接能复用多少次，间接影响连接复用效率和后端压力分布。真正决定请求是否均匀分发的，是 upstream 中的负载均衡算法（如轮询、least_conn）和连接复用行为的配合方式。
理解 keepalive_requests 的真实作用
它不是调度策略，而是连接生命周期的“工作配额”：
- 一个客户端与 Nginx 建立的 keep-alive 连接，只要没超时、也没达到 keepalive_requests 次数，就会被持续复用；
- Nginx 不会因为某个后端连接“太老”就主动换后端——除非该连接被关闭或重置；
- 所以，如果 keepalive_requests 设得过大，而用户请求又集中在少数几个连接上，就可能出现“连接粘滞”，导致流量实际只打到一两台后端，其他机器空闲。
如何配合 upstream 策略提升均匀性
关键在于让连接复用不破坏调度逻辑：
- 启用 least_conn 或 hash $remote_addr 等带状态感知的算法，比纯轮询更能适应长连接场景；
- 在 upstream 块中配置 keepalive 32（每个 worker 保持的空闲连接数），避免频繁建连导致新连接扎堆落到同一台后端；
- 搭配 max_conns=1024 限制单台后端最大连接数，强制 Nginx 将新连接分发到其他可用节点；
- 若用 ip_hash，keepalive_requests 影响较小，但要注意客户端 IP 经过 NAT 后可能集中，反而加剧不均。
合理设置 keepalive_requests 数值
数值过小或过大都会削弱均匀性：
- 设为 100（默认值）：高并发下连接频繁重建，新连接按轮询分配，短期看更“均匀”，但引发大量 TCP 握手和 TIME_WAIT，整体吞吐下降；
- 设为 5000+：连接长期存活，若客户端请求频次低，会导致连接闲置占槽位，活跃连接数虚高，真实请求仍集中在少数连接上；
- 推荐区间：200–3000，依据典型会话请求数设定。例如 React 应用首屏+交互约 40–60 请求，设 200 可保障 3–5 次完整交互复用同一连接，又不至于长期僵化。
辅助手段增强调度响应能力
仅靠 keepalive_requests 不足以动态调优，需组合配置：
- 启用 health_check 和 max_fails/fail_timeout，及时剔除异常后端，避免请求持续打过去；
- 对慢响应后端开启 slow_start=30s，防止恢复后瞬间涌入大量连接；
- 监控 upstream.response.time 和 upstream.queue.len，发现某台后端排队变长，说明连接分布已失衡，需检查 keepalive_requests + keepalive_timeout 是否匹配业务节奏。
