keepalive_requests 通过控制长连接复用请求数间接缓解 TIME_WAIT，需配合 upstream keepalive、HTTP/1.1 和后端长连接配置协同生效；合理值为1000～5000，过高或过低均引发连接不稳定。
keepalive_requests 本身不直接减少 TIME_WAIT，但它通过延长单个连接的复用次数，间接降低新建连接频率，从而缓解端口耗尽。关键在于：减少短连接数量，才能从源头压制 TIME_WAIT 的生成。
keepalive_requests 的作用机制
这个参数控制 Nginx 与上游服务器之间，同一个长连接最多承载多少次 HTTP 请求后才主动关闭。它只在 upstream 块中启用 keepalive 后才生效。
- 默认值是 100，对多数轻量 API 来说偏小；
- 若设得太低（如 10 或 50），连接会过早断开，触发频繁重建 → 更多 TCP 握手 + 更多 TIME_WAIT；
- 若设得过高（如 100000），而上游服务又设置了较短的 keepalive timeout（比如 30 秒），可能导致连接被后端主动 RST 掉，Nginx 收到后需重试或降级为短连接，反而增加不稳定风险。
合理设置 keepalive_requests 的要点
- 建议范围：1000～5000，适用于稳定、轻量、支持 HTTP/1.1 pipelining 的后端（如 Go/Java 微服务）；
- 若后端是 Python Flask/FastAPI 等默认不开启长连接的框架，先确认其是否真正复用连接（比如用
uvicorn --keep-alive 60）；否则调高该值无效； - 可结合日志观察：若
error.log中频繁出现upstream prematurely closed connection或client closed connection while waiting for request，说明连接老化或后端提前断连，此时应适当调低keepalive_requests（例如降到 200～500），并同步检查后端 keepalive timeout 是否足够长； - 它不单独起作用，必须配合以下配置：
-
proxy_http_version 1.1; -
proxy_set_header Connection ''; - upstream 内启用
keepalive N;（如keepalive 32;） - upstream 内可选设
keepalive_timeout 60s;（建议 ≤ 后端值）
-
配合应用层协同减少 TIME_WAIT
光调 keepalive_requests 不够，还需确保整个链路复用连接：
- 后端服务自身开启 HTTP Keep-Alive（如 Tomcat 的
connectionTimeout和keepAliveTimeout，或 Nginx 的keepalive_timeout）； - 若 Nginx 是代理到另一个反向代理（如 K8s Ingress），需逐层透传
Connection ''和HTTP/1.1； - 客户端（如前端 JS、App）也应使用持久连接（现代浏览器默认开启，但需避免手动设置
Connection: close）； - 非 HTTP 场景（如 Redis、MySQL 调用），务必使用连接池，避免每次请求新建连接。
不复杂但容易忽略
