这个问题戳中了WebSocket和HTTP会话绑定的一个常见痛点，咱们结合反向代理的场景一步步拆解：

核心基础逻辑 #

首先得明确：WebSocket是独立的TCP长连接，一旦通过HTTP握手阶段建立成功，就和发起握手的那个HTTP请求脱钩了——但如果你的反向代理是靠会话Cookie做校验，那关键要看代理的校验逻辑是只在握手阶段生效，还是会持续监控会话状态。

分场景讨论 #

场景1：反向代理仅在WebSocket握手时校验会话 #

这种是最常见的配置：代理只在客户端发起WebSocket握手（GET /ws HTTP/1.1带Upgrade头）的时候检查会话Cookie的有效性，握手通过后就只负责转发WebSocket帧，不再管后端的HTTP会话状态。

这种情况下，HTTP会话超时后，WebSocket连接不会自动关闭，直到触发以下任一条件：

• 客户端主动断开连接（比如页面关闭、刷新）
• 业务服务端主动检测到会话超时，找到对应的WebSocket连接并发送关闭帧（需要服务端维护会话与连接的映射关系）
• TCP层本身的超时机制触发（比如长时间无数据传输，触发TCP keepalive断开）

场景2：反向代理配置了持续会话校验 #

如果你的反向代理（比如Nginx+Lua脚本、Envoy自定义过滤器）做了额外配置，会定期检查后端会话存储（比如Redis）里的会话有效性，那当HTTP会话超时后，代理会主动切断WebSocket连接：

• 代理会先给客户端和服务端发送WebSocket关闭帧（常用code 1008表示「政策冲突」，也可以用自定义code）
• 然后断开底层的TCP连接，避免无效连接占用资源

场景3：业务服务端主动绑定会话与WebSocket连接 #

即使代理不做持续校验，业务服务端也可以自己实现关联逻辑：

• 在WebSocket握手成功时，把当前的会话ID和WebSocket连接实例绑定（比如用一个全局哈希表，key是会话ID，value是该会话对应的所有WebSocket连接集合）
• 当HTTP会话超时（比如会话存储中的键过期），服务端遍历该会话对应的连接，主动发送关闭帧并释放连接资源
• 这种方式需要注意线程安全，尤其是在分布式服务场景下，要借助共享存储（比如Redis）来同步会话状态和连接映射

常见实践建议 #

• 优先在业务层实现会话与WebSocket的绑定逻辑，这样能更精准地控制连接生命周期，不受代理配置限制
• 配合WebSocket心跳机制：客户端定期发送ping帧，服务端回复pong，如果长时间没收到心跳，直接关闭连接——这既能处理会话超时的情况（会话过期后客户端可能停止发送心跳），也能清理僵死连接
• 如果用反向代理做持续校验，要注意校验频率，避免给后端会话存储带来过大压力

内容的提问来源于stack exchange，提问作者mns