关键在于验证keepalive_requests是否作用于客户端到Nginx连接：需置于http/server块、排除location覆盖、抓包确认TCP复用与FIN时机、确保客户端发Connection: keep-alive、并协同keepalive_timeout配置。
排查客户端长连接未按预期触发 keepalive_requests，关键不是看“它有没有生效”，而是验证“它是否被正确作用于客户端到 Nginx 这一段连接”，并排除协议层、配置作用域和客户端行为的干扰。
确认 keepalive_requests 是否真的在 client → Nginx 链路上生效
很多人误以为在 upstream 块里设了 keepalive_requests 就能控制客户端连接——其实完全无关。该指令只对 客户端到 Nginx 的连接 有效，且必须放在 http 或 server 块中（不能只写在 location 里）。
- 检查配置位置：确保类似
keepalive_requests 1000;出现在http { ... }或server { ... }顶层作用域内 - 验证是否被覆盖：若 server 块里没设，但 http 块设了 1000，那它就生效；若某个 location 里又写了
keepalive_requests 1;，则该 location 下的连接会在第 1 次请求后就断开——这是常见误配 - 用
nginx -t && nginx -s reload确认配置已加载，避免改了没生效
抓包验证连接是否真被复用、何时关闭
日志看不出计数逻辑，必须靠 TCP 层证据：
- 在 Nginx 服务器上执行：
tcpdump -i any 'host [客户端IP] and port [客户端端口]' -w client_conn.pcap - 用 Wireshark 打开，过滤
tcp.stream eq X查单个连接流，观察：- HTTP 请求是否复用同一 TCP 流（连续多个 GET/POST 共享同一个源/目的端口对）
- FIN 包是否出现在第
keepalive_requests个请求响应之后（例如设为 100，第 100 次响应发完后立刻 FIN） - 若 FIN 出现在第 2 次或第 50 次之后，说明计数被重置、被覆盖，或客户端主动断连
检查客户端是否真正发起 Keep-Alive 请求
Nginx 不会强制客户端长连接，它只响应符合协议的行为：
- 浏览器默认都带
Connection: keep-alive，但某些 SDK（如 Python requests 默认不带）、旧版 Android WebView 或自定义 HTTP 客户端可能发Connection: close - 用 curl 测试：运行
curl -v --http1.1 -H "Connection: keep-alive" http://your-domain.com/api，观察是否复用连接 - 若客户端每次请求都新建 TCP 连接（三次握手重复出现），那
keepalive_requests根本无从计数——先解决客户端行为问题
排除 keepalive_timeout 的干扰
两个参数是“与”关系：连接必须同时满足“请求数未超限”且“空闲时间未超限”才能继续复用。
- 若
keepalive_timeout 5s;，而客户端每 10 秒才发一次请求，那连接在第 1 次响应后 5 秒就被关，keepalive_requests永远不会走到 2 - 典型搭配：高频接口（如轮询）设
keepalive_timeout 15s; keepalive_requests 1000;；低频管理页可设keepalive_timeout 60s; keepalive_requests 100; - 临时调大
keepalive_timeout（如设为 300s）做对比测试，若此时连接能稳定复用多次，说明原 timeout 是瓶颈
