测WebSocket代理链路长连接保持率，本质是量化真实连接在预期时长内未被意外中断的比例，需通过握手验证、可控压测、Nginx日志分析及系统网络层交叉验证四步实现，确保可观察、可归因、可复现。
要测 WebSocket 代理链路中长连接的保持率，本质是量化真实连接在预期时长内未被意外中断的比例。这不是测“能不能连上”，而是看“连上了能稳多久、断多少、为什么断”。关键在可观察、可归因、可复现。
一、先确认链路是否真正支持长连接
没打通握手或 TCP 层就断，保持率永远是 0。三步快速验证：
- 用
curl发起一次标准 WebSocket 握手，检查返回是否为HTTP/1.1 101 Switching Protocols：curl -i -N \ -H "Connection: Upgrade" \ -H "Upgrade: websocket" \ -H "Sec-WebSocket-Key: $(openssl rand -base64 16)" \ http://your-nginx-ip/ws/
- 用 Wireshark 或
tcpdump抓包，过滤目标端口（如port 80 or port 443），确认：
✅ 三次握手完成
✅ 客户端发GET /ws/+Upgrade: websocket
✅ 服务端回101后，后续通信为纯 TCP 帧流（无 HTTP 状态行）
❌ 出现 RST 或 FIN 过早出现，说明某层（Nginx、防火墙、内核）主动切断 - 查后端日志，确认连接建立时记录了唯一标识（如
connection_id=abc123），且该 ID 在后续心跳或消息中持续出现
二、设计可控的压测场景来统计保持率
保持率 =（实际存活 ≥ T 秒的连接数）÷（总发起连接数）× 100%。T 根据业务定（如 5 分钟、30 分钟、2 小时）。推荐用 JMeter + WebSocket 插件：
- 每个线程模拟一个客户端，执行以下流程：
- 连接 WebSocket endpoint（带重试，最多 3 次）
- 成功后启动定时心跳（如每 25 秒发
{"type":"ping"}） - 监听
pong或业务响应，超时（如 40 秒未收）则标记“异常断连” - 运行满 T 秒后主动关闭，记为“正常结束”
- 聚合结果看三类数据：
- 总连接数、主动关闭数、被动断连数（含
onclosecode ≠ 1000）、超时未响应数 - 断连时间分布（例如：70% 断在 55–65 秒，大概率是
proxy_read_timeout=60导致） - Nginx access log 中
$upstream_response_time和$upstream_addr字段，确认是否集中在某台后端或某个 upstream server
- 总连接数、主动关闭数、被动断连数（含
三、从 Nginx 日志反推连接稳定性
开启自定义日志格式，把关键指标打出来：
log_format ws_log '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'$upstream_addr $upstream_response_time '
'$upstream_http_connection $upstream_http_upgrade';
access_log /var/log/nginx/ws-access.log ws_log;分析时重点关注：
-
upstream_response_time长期为-或极小值（如0.000）：说明连接建立后没走proxy_read_timeout逻辑，可能被中间设备（如云 LB、NAT）截断 -
upstream_addr出现大量切换：说明会话未绑定，轮询导致连接反复重建 -
upstream_http_connection不是upgrade：Nginx 未成功透传头，握手降级为 HTTP，后续必然断
四、结合系统与网络层交叉验证
Nginx 配置再对，也挡不住外层掐线。需同步检查：
-
Nginx 主机 TCP 参数：
sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes
建议设为
300 15 3（5 分钟探测，间隔 15 秒，失败 3 次断链），比默认 2 小时更激进 -
云环境限制：AWS ALB 默认空闲超时 60 秒、阿里云 SLB 可配但最低 60 秒、腾讯云 CLB 最低 300 秒——这些都比 Nginx 的
proxy_read_timeout更优先生效 -
客户端侧干扰：手机浏览器后台冻结、省电模式禁用定时器、企业防火墙主动 kill 空闲连接。可在客户端加日志：记录每次
ws.onopen、ws.onmessage、ws.onclose时间戳，导出后比对断连时间点是否集中出现在整分钟附近
不复杂但容易忽略
