最可靠压测用真实设备但成本高，推荐wrk模拟长连接+抓包+nginx日志交叉验证，重点观察连接复用率、超时行为和内存增长趋势。
直接用真实设备压测最可靠，但成本高、难复现；推荐用轻量级工具模拟长连接 + 抓包 + Nginx 日志交叉验证，重点看连接复用率、超时行为和内存增长趋势。
用 wrk 或 go-wrk 模拟海量长连接
普通 curl 或 ab 不支持持久连接复用，容易误判。wrk 默认启用 HTTP/1.1 keepalive，适合模拟 IoT 设备“建连后长期空闲、偶发心跳”的行为：
- 启动 10,000 个连接，每秒只发 1 个心跳（GET /ping），持续 5 分钟：
wrk -c 10000 -t 4 -d 300 --timeout 30s -H "Connection: keep-alive" http://your-nginx/ping - 观察 wrk 输出中的 Requests/sec 和 Connestions 是否稳定，若连接数大幅波动或重连频繁，说明 keepalive 被意外中断
- 搭配
ss -s或netstat -an | grep :80 | wc -l实时核对 Nginx 实际维持的 ESTABLISHED 连接数
检查 Nginx keepalive 关键配置是否生效
IoT 场景下默认配置往往不适用，需显式调优并确认运行时值：
-
worker_connections：确保足够容纳峰值连接（如 65536），并在 events 块中启用
use epoll;（Linux） -
keepalive_timeout：设为 300–600 秒（避免设备心跳间隔略超时导致断连），同时配
keepalive_requests 1000;防止单连接请求过多耗尽资源 - client_header_timeout / client_body_timeout：建议同步设为略大于 keepalive_timeout（如 610s），防止空闲期间读 Header 超时主动断连
- 用
nginx -T | grep -A 5 'keepalive'确认加载的是预期配置，而非被 include 覆盖
抓包 + 日志联动分析真实连接生命周期
单看指标易漏细节，tcpdump 抓包与 access log 时间戳对齐可定位异常断连根源：
- 在 Nginx 机器上抓指定端口的 FIN/RST 包：
tcpdump -i any -nn port 80 -w keepalive.pcap 'tcp[tcpflags] & (tcp-fin|tcp-rst) != 0' - 开启带毫秒时间戳和连接 ID 的日志（需编译时含
--with-http_realip_module）：log_format detailed '$time_iso8601 $connection $connection_requests $status $request_time'; - 对比某连接 ID 在日志中最后请求时间 vs 抓包中 FIN 时间：若差值 ≈ keepalive_timeout，属正常回收；若远小于此（如 60s 内突断），可能是内核 net.ipv4.tcp_fin_timeout、防火墙 idle timeout 或客户端异常下线
监控连接内存与 worker 状态防隐性泄漏
长连接本身不耗 CPU，但每个连接占用约 2–4KB 内存；连接数激增时易触发 OOM 或 worker 拒绝新连接：
- 定期采样：
ps -o pid,user,%cpu,%mem,vsz,rss,comm -C nginx—— 关注 RSS 增长是否线性于连接数 - 检查 worker 是否卡住：
kill -USR2 $(cat /var/run/nginx.pid)触发 reload 后，观察旧 worker 进程是否及时退出（残留说明连接未正常关闭） - 启用 stub_status 模块（
location /nginx_status { stub_status; }），关注 Active connections 与 Reading/Writing/Waiting 分布：Waiting 长期 >90% 表明连接空闲但未释放，符合预期；若 Writing 持续升高，可能后端响应阻塞
