keepalive_requests 通过限制单连接请求数实现灰度场景下的连接平移：设为400–600（匹配5分钟灰度窗口），配合keepalive_timeout 20–25秒、upstream keepalive及正确proxy设置，使客户端与后端连接同步轮转，确保流量逐步、优雅切至新版本节点。

keepalive_requests 本身不直接参与灰度发布，但它能配合灰度策略实现连接的定期、可控、优雅平移——核心逻辑是：通过主动限制单连接生命周期（次数+时间），让客户端在灰度切换窗口内自然重建连接，从而将流量逐步导向新版本节点，避免长连接僵化导致的灰度延迟或不一致。

为什么需要“连接平移”而不是静默切换

灰度发布常聚焦于请求路由（如按 IP 或标签分发配置），但若客户端与 Nginx 之间存在大量长期复用的 Keep-Alive 连接，这些连接可能在灰度生效后仍持续打到旧后端节点（尤其当 upstream 未启用 keepalive 连接池或后端未及时感知配置变更时）。此时，仅改路由规则无法立即生效，需让旧连接“到期退出”，新连接“按新规则建立”。keepalive_requests 正是控制这个“到期节奏”的关键杠杆。

配置要点：以次数为锚点，驱动连接轮转

在灰度场景下，keepalive_requests 不应设得过大（如 5000），否则单连接可能存活数小时，完全绕过灰度控制；也不宜过小（如 10），否则频繁断连会增加握手开销。推荐按灰度周期反向推算：

• 若灰度窗口为 5 分钟，且客户端平均每秒发起 2 次请求（如前端轮询 + 资源加载），则单连接约承载 600 次请求 → 将 keepalive_requests 设为 400–600，确保多数连接在灰度期内完成生命周期
• 若灰度采用分批推进（如每 10 分钟扩一批），可搭配 keepalive_timeout 设为 20–25 秒，形成“短时高频复用 + 快速自然淘汰”组合，使连接更灵敏响应上游节点变化
• 在 http 块统一设置，避免 server 或 location 级别覆盖导致部分路径连接行为不一致，影响灰度收敛一致性

与 upstream keepalive 协同，确保后端也同步轮转

客户端连接平移只是前半程，后端连接池也需配合更新，否则 Nginx 可能继续复用旧连接打到已下线的老实例：

• upstream 块中启用 keepalive 32（视后端实例数调整），并设 keepalive_requests 300–500，使其与客户端侧节奏大致匹配
• proxy_pass 所在 location 必须包含：
  proxy_http_version 1.1;
  proxy_set_header Connection '';
  否则 upstream keepalive 不生效，Nginx 仍会为每个请求新建后端连接
• 确认后端服务（如 Spring Boot、Node.js）自身 keepalive 超时 ≥ 30 秒，避免后端主动断连干扰 Nginx 的连接复用计划

灰度期间可观测与验证方式

配置生效后，不能只依赖日志，需验证连接是否真实轮转：

• 用 curl 多次请求同一接口（带 -v 查看 Connection 头），观察是否出现 Connection: close 后又恢复 keep-alive，确认请求数阈值触发机制正常
• 在灰度节点上执行 ss -tn state established | grep :80 | wc -l，对比灰度前后连接数分布变化趋势，若新节点连接数稳步上升、旧节点缓慢下降，说明平移正在发生
• 结合 Nginx 日志中的 $connection_requests 变量（记录当前连接已处理请求数），采样分析是否集中在设定阈值附近断连