Nginx长连接是否生效取决于TCP连接是否复用；需配置keepalive_timeout、客户端带Connection: keep-alive，用Session发送间隔请求，在Wireshark中观察同一TCP流内多请求及FIN时间是否匹配超时设置。
直接看 TCP 连接的复用行为，而不是只盯着 HTTP 头里的 Connection: keep-alive。Nginx 的长连接是否生效，本质体现在底层 TCP 连接有没有被重复利用——Wireshark 能清晰呈现这一点。
确认 Nginx 已启用 Keep-Alive
检查 nginx.conf 中是否配置了 keepalive_timeout（如 keepalive_timeout 5;），且未被 location 块覆盖。该值定义服务端在无数据交互时保持连接的秒数。注意：客户端是否发起长连接，还取决于其请求头是否带 Connection: keep-alive（现代浏览器和 requests.Session 默认开启）。
用 Session 客户端发送多轮请求
避免单次 curl 命令造成新连接。推荐使用 Python 的 requests.Session 或 curl 的 -H "Connection: keep-alive" + --http1.1，并控制时间间隔：
- 第一次请求后等待 2 秒再发第二次 → 应复用同一 TCP 连接
- 第二次请求后再等 6 秒发第三次 → 若
keepalive_timeout为 5 秒，则此时连接大概率已关闭，第三次会触发新的 TCP 三次握手
在 Wireshark 中观察 TCP 连接生命周期
过滤目标端口（如 tcp.port == 10011），重点关注以下特征：
- 连接复用：连续两个 HTTP 请求出现在同一个 TCP 流中（相同源/目的 IP+端口组合），且中间没有 FIN/RST 包
- 连接关闭：看到 FIN-ACK-FIN-ACK 四次挥手序列，或服务端在空闲超时后主动发 FIN
- 保活探测（可选）：若系统启用了 TCP keepalive（非 HTTP keep-alive），可见周期性零字节 ACK 报文（但 Nginx 默认不依赖此机制）
对比关键时间点与报文序号
右键某条 HTTP 请求 → “Follow” → “TCP Stream”，查看完整交互流。记录：
- 第一个请求的 SYN 时间戳
- 第二个请求是否出现在同一 stream 中、有无重传或延迟确认
- FIN 出现的时间是否接近
keepalive_timeout设置值（从最后一个数据包结束起算）
若多个请求共用一个 TCP 流，且 FIN 出现在预期超时点附近，就说明 Nginx 的长连接策略已按配置生效。
