聊天室、行情推送、在线协作这类实时页面，偶尔出现”连不上”或”用着用着就断”的情况，多数人先怪网速。其实 WebSocket 的建立过程里藏着一个很容易被忽略的环节——升级握手，套了代理之后，这一关往往就是断连的根源。
一次升级握手，决定连接能不能建立
WebSocket 连接不是独立发起的，它从一次普通的 HTTP 请求”升级”而来：客户端先发一个带 Upgrade: websocket 和 Connection: Upgrade 头的 GET 请求，服务端同意后回一个 101 状态码，双方这才切换到长连接模式。代理站在请求路径中间，能不能把这个升级请求原样转过去，直接决定握手成败。
两条路：升级转发还是 CONNECT 隧道
支持 WebSocket 的代理会识别 Upgrade 头，把升级请求完整转发，再原样带回 101 响应，双方在原有连接上完成切换；另一种更省心的方式是 CONNECT 隧道：客户端先和代理建立一条透传隧道，升级握手在隧道内完成，代理只负责搬运字节，不参与任何判断。生产环境里，走隧道的兼容性明显更好。
| 方式 | 原理 | 兼容性 |
|---|---|---|
| 升级转发 | 识别 Upgrade 头并原样转发 | 依赖代理实现，参差不齐 |
| CONNECT 隧道 | 先建隧道，握手在隧道内完成 | 普遍支持，最稳 |
| 不支持升级 | 按普通请求处理或直接丢弃 | 握手必然失败 |
常见的三个坑
一是代理缓冲：某些代理把请求缓存起来再转发，Upgrade 头在缓冲过程中被改写或丢掉，服务端永远等不到升级请求；二是空闲掐断：WebSocket 连接长时间没消息，代理按闲置规则把连接关了，客户端收到的是静默断连；三是老版本兼容：年代较久的代理软件对 Upgrade 头没有专门处理，只能换 CONNECT 方式。
- 先看 101：抓包确认是否返回 101，没有就说明升级请求没被完整转发
- 改走隧道：客户端支持时切换为 CONNECT 隧道方式，绕开升级转发的坑
- 关缓冲：关闭代理对长连接的缓冲与改写，保持请求头原样
- 开心跳：客户端启用保活机制，避免空闲连接被代理掐断
WebSocket 的价值在长连接，代理的价值在出口——两者要配合好，关键就在升级握手这一关。
与 IP 代理的关系：代理IP解决的是出口地址与链路中转，WebSocket 这类长连接能否稳定穿过代理，取决于升级握手与连接保持的处理方式；先确认代理对 Upgrade 请求与 CONNECT 的支持情况，再谈出口选型，才能避免”出口换了还是断”。所有使用都应遵循平台规则与法律法规，用于正当业务目的。