最有效的方式是直接对比ttfb和连接复用率：chrome devtools中connection列显示reuse、ttfb骤降至2–5ms表明keepalive生效；ss命令显示estab连接数缓慢回落、抓包确认keep-alive响应头存在、lcp下降100–300ms可综合验证。
直接对比 TTFB（首字节时间）和连接复用率，是最有效的方式。不能只看配置是否开启，关键要看浏览器是否真在复用连接、延迟是否实际下降。
用 Chrome DevTools 观察真实复用行为
打开网页时，按 F12 → Network 标签页 → 刷新页面。重点关注两列：
- Connection 列：显示 reuse 表示复用成功；new 表示新建连接
- Time 列中的 TTFB：多次请求中，若前几个很高（如 120ms）、后面骤降至 2–5ms，说明 keepalive 已生效
关闭 keepalive 后再测一次：可在 Nginx 配置中临时设 keepalive_timeout 0;，重启后重刷页面，会发现几乎全部请求都标为 new，且 TTFB 普遍稳定在 60–200ms 区间（尤其弱网下更明显）。
用 ss 命令验证连接驻留状态
在服务器终端执行：
ss -tnpo | grep :443 | grep ESTAB | wc -l
这个命令统计当前所有处于 ESTABLISHED 状态的 HTTPS 连接数。分别在以下两种状态下运行并记录数值：
- 开启 keepalive（如设为 60s）且页面刚加载完：连接数应明显高于并发请求数（例如 10 个资源加载产生 1–3 个长连接）
- 关闭 keepalive 或 timeout 设为 5s：连接数会在资源加载完成后快速归零或仅剩极少数
持续观察 10–20 秒，若连接数缓慢回落而非瞬间清零，说明空闲连接被保留，keepalive 正常工作。
抓包确认 Keep-Alive 响应头与客户端行为
用 Wireshark 或 tcpdump 抓取浏览器访问流量，过滤 HTTP 流，检查响应头是否含：
Connection: keep-alive Keep-Alive: timeout=60, max=1000
同时确认客户端请求头中是否带 Connection: keep-alive（HTTP/1.1 默认隐含，但部分 SDK 或 WebView 可能不发）。如果响应头缺失或客户端未声明保活，即使 Nginx 配了 keepalive_timeout 也无效。
对比 LCP 和整体加载时间（需多轮采样）
在 Lighthouse 或 WebPageTest 中，分别对同一页面做 3–5 次测试（清除缓存、禁用预加载），记录关键指标：
- LCP（最大内容绘制）：开启 keepalive 后通常下降 100–300ms，尤其在图片/CSS 多、网络波动时更显著
- Total Blocking Time（TBT）：连接复用减少握手阻塞，间接降低主线程等待
- Requests / Connection：理想情况下，单个连接承载 8–20 个请求（取决于资源数量和间隔）
注意避开 CDN 缓存干扰——可临时加随机查询参数（如 ?v=123）确保每次加载都是真实请求链路。
