keepalive_requests是否起效，关键看单个连接实际处理请求数、是否按设定值关闭及有无异常堆积；可通过curl观察响应头Connection变化、access.log中$connection_requests字段统计、ss命令查ESTABLISHED连接数及压测对比验证。
直接观察连接行为比看配置更可靠。高频接口下，keepalive_requests是否起效，关键看单个连接实际处理了多少请求、是否按预期关闭、有没有异常堆积。
用 curl 验证连接复用与断连时机
发起连续请求，观察响应头和连接复用状态：
- 加
-v查看详细交互：curl -v --http1.1 -H "Connection: keep-alive" http://your-api.com/health - 关注响应头中的
Keep-Alive: timeout=XX, max=YY—— 其中max就是当前生效的 keepalive_requests 值 - 重复执行同一命令（或用循环脚本发 500+ 次），当请求数接近设定值时，留意第 N 次响应头是否变成
Connection: close，且后续请求触发新 TCP 连接（可通过tcpdump或ss -tnp确认端口号变化）
通过日志变量统计真实连接负载
在 log_format 中加入 $connection_requests，它记录当前连接已处理的请求数：
- 配置示例：
log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $connection_requests'; - 压测后查 access.log，筛选出
$connection_requests接近你设置的阈值（如 2000）的日志行，确认是否集中出现在某几个连接上 - 若大量连接长期停留在 1～50，说明客户端没复用；若频繁出现 1999→1 的跳变，说明 keepalive_requests 正常触发断连
用 wrk 或 hey 做持续压测对比
模拟真实高频调用节奏，重点观测连接数与请求分布：
- 例如每秒 50 次请求，持续 60 秒：
wrk -t4 -c200 -d60s --http1.1 http://api.example.com/ping - 运行中执行：
ss -tnp | grep :80 | grep ESTAB | wc -l，观察稳定后的并发连接数是否明显低于-c200（说明复用有效） - 对比两组配置：一组
keepalive_requests 100，另一组2000，相同压测条件下看TIME_WAIT数量、平均延迟波动、以及$connection_requests日志中高值连接占比
检查系统级资源是否成为瓶颈
高频场景下，数值设得再合理，也可能被底层限制卡住：
- 确认
worker_connections足够：比如设了keepalive_requests 3000，但worker_connections 1024，连接池根本撑不起高复用 - 检查系统文件描述符：
ulimit -n和/proc/sys/fs/file-max，若压测中报too many open files，说明连接数超限，需同步调大 - 观察 Nginx worker 进程 CPU 占用率：若单 worker 持续 >70%，可能连接管理开销过大，需结合
worker_processes和业务模型调整
