keepalive_requests默认值100适用于传统页面加载，但高频短连接业务（如心跳、轮询）需调至1000–5000，并同步缩短keepalive_timeout至15–30秒，实现“时间+次数”双控，避免频繁重建或空闲滞留。
高频短连接业务（如每秒多次心跳、轮询、轻量 API 调用）本质上并不“短”，而是请求频密、单次耗时低、复用意愿强——此时长连接利用率高低，直接取决于 keepalive_requests 是否匹配真实会话密度。设太小，连接反复重建；设太大，空闲连接滞留；关键不在“值本身”，而在它与请求节奏、超时策略、系统资源的协同。
为什么默认 100 在高频场景下明显不够
默认值 100 源于传统页面加载模型（一次 HTML + 少量 JS/CSS），但对高频短周期业务完全不适用：
- 若客户端每 2 秒发一次心跳，100 次请求 ≈ 200 秒连接寿命 —— 远超实际交互窗口，易堆积空闲连接
- 若每 500ms 轮询一次，100 次仅支撑 50 秒，连接频繁断开重建，
TIME_WAIT激增、端口耗尽风险上升 - 大量小请求复用同一连接本是优势，但 100 的硬限迫使客户端在活跃期就重连，白白损失复用收益
如何按业务节奏反推合理取值
目标是：让一个典型会话周期内的全部请求，尽可能落在同一个连接上完成，且连接不会“过期”或“僵死”。推荐按以下逻辑估算：
-
心跳类（如设备在线保活）：预期间隔 1–3 秒，单连接期望存活 15–30 秒 → 设
keepalive_requests为 1000–3000，同步配keepalive_timeout 15s–30s -
前端轮询（如订单状态、消息未读数）：间隔 2–10 秒，用户会话常持续数分钟 → 建议 2000–5000，搭配
timeout 30s防止空闲滞留 - 移动端 SDK 短请求聚合：SDK 内部批量发送，单连接承载数十至百次请求 → 可设 500–1500，避免单个异常请求拖垮整条连接
必须同步调整的配套项
keepalive_requests 不是孤立参数，脱离上下文调优会失效甚至起反作用：
-
务必缩短
keepalive_timeout：高频场景下，空闲比超时更危险。建议设为 15–30 秒，与requests形成“时间+次数”双控，防止单连接长期驻留 -
确认客户端支持 HTTP/1.1 keep-alive：curl 测试响应头含
Connection: keep-alive；若客户端强制用 HTTP/1.0 或禁用 keep-alive，该参数不生效 -
检查系统文件描述符限制：过高的
requests值 × 高并发连接数，可能触发too many open files。需同步调大worker_connections和系统级nofile - 不要设为 0：不限制会掩盖连接老化、内存缓慢增长等真实问题，且多数生产环境不接受无上限连接生命周期
验证是否真正提升利用率
不能只看配置写没写对，要观察真实连接行为：
- 用
ss -s | grep "tcp:"查看 ESTABLISHED 连接总数是否稳定，剧烈波动说明复用率低 - 连续执行
curl -s -o /dev/null -w "%{http_code}\n" http://x/y十几次，再查netstat -an | grep :80 | grep ESTABLISHED | wc -l—— 若连接数基本不变，说明复用成功 - 配合 Nginx stub_status 模块，观察
Active connections与Reading/Writing/Waiting比例，Waiting 长期高位可能意味着连接空闲堆积
