安全关闭异常WebSocket连接需Nginx被动检测（tcp_nodelay、proxy_read_timeout、keepalive_timeout协同）、后端主动触发标准CLOSE帧（如1008码）、客户端响应清理，三者配合实现无残留终止。
安全关闭异常 WebSocket 连接会话，不是靠“主动踢人”，而是通过 Nginx 的被动检测 + 后端协同 + 客户端配合，实现干净、可控、不残留的连接终止。核心思路是：让异常连接能被快速识别、优雅释放资源、避免堆积和状态错乱。
识别并切断已失效的 TCP 连接
Nginx 本身不维护 WebSocket 连接状态，但可通过底层 TCP 行为感知异常：
- 启用 tcp_nodelay on：加速小帧（如 PING/PONG）传输，让心跳更及时，缩短“假在线”窗口
- 设置合理的 proxy_read_timeout：建议设为略大于后端心跳间隔（如后端每 45 秒发一次 ping，则设为 60–90 秒），超时后 Nginx 会自动关闭与后端的上游连接，并向客户端发送 FIN 包
- 开启 keepalive_timeout 与之对齐：防止客户端到 Nginx 这一跳因空闲被系统或中间设备（如云负载均衡）静默断开
配合后端主动触发关闭流程
Nginx 不处理业务逻辑，真正的关闭决策应在后端完成：
- 后端检测到客户端无响应（如连续丢失 2–3 次 PONG）、token 过期、权限变更时，调用
session.close(1008, "Unauthorized")等标准关闭码 - Nginx 会原样透传 CLOSE 帧（含状态码和原因），客户端收到后可执行清理逻辑
- 若后端使用 Spring Boot + Netty，确保配置
server.tomcat.connection-timeout=-1或匹配 Nginx 超时，避免两端“各关各的”
防止断网后连接堆积（Android/iOS 常见问题）
移动端断网重连时易出现“僵尸连接”——TCP 连接未断，但应用层已不可用：
- 在 Nginx 的 location 块中添加 proxy_cache_bypass $http_upgrade：确保 Upgrade 请求不走缓存，避免旧会话被复用
- 后端需实现连接心跳+业务心跳双校验，例如：每 30 秒发 ping，同时检查最近 2 分钟内是否有有效业务消息
- 结合 Nginx 的 limit_conn 限制单 IP 最大并发连接数（如
limit_conn addr 10），防止单设备反复建连耗尽资源
验证是否真正释放
关闭是否生效，不能只看日志，要从三处确认：
- 运行
ss -tnp | grep :8080 | grep ESTAB | wc -l查看后端真实 ESTABLISHED 连接数是否下降 - Nginx error.log 中搜索
upstream prematurely closed connection或client closed connection，有则说明连接已释放 - 浏览器 DevTools → Network → WS → 查看连接状态是否变为
Closed，且关闭码非 1006（意为“异常终止”）
