主题
WebSocket协议原理与代理转发机制详解
WebSocket是一种建立在单个TCP连接之上的全双工通信协议，允许客户端和服务器在连接建立后随时双向发送数据，而不需要像传统HTTP那样每次都重新发起请求。它常用于需要服务器主动、持续向客户端推送数据的场景，例如AI对话的流式输出、在线协作文档的实时同步、聊天应用的消息推送等。
从HTTP到WebSocket：协议升级的过程
WebSocket连接的建立，起点其实是一个普通的HTTP请求。客户端会发送一个带有特殊请求头的HTTP请求，其中包含 Upgrade: websocket 和 Connection: Upgrade 字段，表明它希望将这条连接从HTTP协议"升级"为WebSocket协议。如果服务器支持，会返回状态码 101 Switching Protocols，握手完成后，这条底层TCP连接就会一直保持打开状态，双方可以在上面自由收发数据帧，直到某一方主动关闭连接。
这个过程被称为"协议升级"，其关键在于：握手完成之后，这条连接的性质已经发生了根本变化——它不再是一问一答的短连接，而是一条需要长期维持的持久通道。
代理服务器转发WebSocket时的常见问题
普通的HTTP代理只需要转发一来一回的请求和响应，处理起来相对简单。但WebSocket要求代理服务器识别并正确处理协议升级请求，并且在升级完成后，将这条连接当作一条需要长期保持的双向通道来对待，而不是按照普通HTTP请求的生命周期去管理。如果代理软件或中间网络设备的实现不够完善，可能出现以下问题：
- 未能正确转发升级请求头：导致握手失败，连接直接建立不起来。
- 对空闲连接设置过短的超时时间：WebSocket连接在没有数据传输的间隙也需要保持打开，如果代理认为"长时间没有数据就是连接已经失效"而主动断开，就会造成看似随机的掉线。
- 数据缓冲导致的推送延迟：部分反向代理默认会对响应进行缓冲，这在处理流式数据时会造成明显的卡顿或迟滞，需要显式关闭缓冲才能保证实时性。
为什么WebSocket断连比普通请求失败更"难受"
普通HTTP请求失败，重试一次通常就能恢复，用户几乎无感。但WebSocket承载的是一个持续的会话状态——例如AI模型正在逐字生成一段很长的回复，一旦连接中断，服务端和客户端此前建立的上下文通道就已经失效，无法像视频播放那样"从断点续传"，往往只能重新发起整个请求。这也是为什么流式AI对话对底层网络连接稳定性的要求，明显高于普通网页浏览。
常见问题
Q：WebSocket和普通TCP长连接是一回事吗？ A：WebSocket是运行在TCP之上的一种应用层协议，本质上依赖TCP提供的长连接能力，但额外定义了握手方式和数据帧格式。理解TCP长连接的行为，有助于理解WebSocket为什么对网络稳定性如此敏感，可以参考TCP长连接的影响。
如果您在使用ChatGPT等AI工具时经常遇到流式回复中断的问题，可以结合网络基础：WebSocket与长连接对AI工具的影响和ChatGPT Codex持续断流排查做进一步排查。
仍然存在网络连接问题？
如果账号、设备、浏览器、客户端和DNS均已排查，但仍出现连接超时、长连接中断、视频缓冲或出口IP频繁变化，可以继续查看对应场景的线路选择指南。