聊天室、行情推送、在线协作这类实时应用，底层几乎都是 WebSocket。很多人本地连得好好的，一挂上代理就握手失败、反复掉线，这篇讲清楚 WebSocket 走代理时最容易踩的三个坑，以及正确的配置思路。
先分清 WebSocket 和普通网页请求的差别
普通网页请求是“请求-响应”模式，发一次收一次就结束。WebSocket 不一样：客户端先发一个带 Upgrade 头的 HTTP 请求，服务端返回 101 表示同意升级，此后这条连接就变成双向长连接，双方随时可以互推数据。关键在升级握手发生在 HTTP 层，而升级之后的流量不再走普通请求的逻辑，代理对这一段的处理方式，决定了能不能成。
代理对 WebSocket 的支持分三档
| 代理方式 | 对 WebSocket 的支持 | 典型表现 |
|---|---|---|
| HTTP 代理（直接转发） | 多数支持 Upgrade 转发 | 握手正常，长连接可用 |
| CONNECT 隧道 | 完全支持 | 隧道建立后流量透明，最稳 |
| SOCKS5 | 视实现而定 | 部分支持长连接，部分掐断 |
| 不支持 Upgrade 的代理 | 不支持 | 拿不到 101，直接报错 |
最容易踩的三个坑
- 代理不支持 Upgrade：服务端已同意升级，代理却把后续帧当普通请求处理，连接瞬间断开
- 空闲连接被掐断：长连接一段时间没消息，代理或中间设备回收连接，客户端无感知，下一次收发就失败
- 端口与协议限制：部分代理只开放固定端口或只处理普通 HTTP 流量，握手阶段就被拦下
掉线后按这个顺序排查
- 先直连测试，确认服务端和本地没问题
- 确认代理是否支持 Upgrade，必要时改用 CONNECT 隧道方式
- 客户端开启自动重连，配合心跳消息保活
- 长连接场景优先选静态出口，避免中途换地址
WebSocket 对连接连续性要求极高，一断就要重连，重连又意味着新的握手和可能的状态丢失，所以“稳定不换”比“快”更重要。
和 IP 代理的关系
动态轮换的代理每隔一段时间就换出口，WebSocket 长连接很难稳定维持，频繁掉线往往不是服务端的问题，而是出口在变。静态出口、对长连接友好的代理资源，才是实时类应用的正当选择——它解决的是连接稳定与延迟波动，不改变业务本身的合法边界。选代理时先确认出口是否固定、是否支持长连接，比纠结速度参数更关键。
一句话：WebSocket 走代理，握手升级和长连接保活是两大关卡；静态出口加 CONNECT 隧道是最稳的组合，动态轮换代理是掉线头号嫌疑。