WebSocket 代理 IP 握手、长连接与反向代理排查

WebSocket 代理出现握手失败、连接约 60 秒后断开或返回 502/504 时，应按客户端、代理 IP、反向代理和目标服务四段定位。普通 HTTP 返回 200 只说明基础请求走通，还要确认 HTTP 代理 IP 的 CONNECT 隧道、WebSocket 握手是否返回 101，以及连接空闲时是否被某一跳的超时关闭。代理 IP 只改变对外的出口 IP，不会替你修复 Upgrade、TLS 或反向代理配置。

WebSocket 代理请求经过哪些环节？

使用 HTTP 代理 IP 访问 wss://ws.example.com/socket 时，客户端先向代理发送 CONNECT ws.example.com:443。这一步只负责建立到目标端口的隧道；代理返回 200 Connection established 后，TLS 和 WebSocket 握手才在隧道内完成。因此，407 发生在 CONNECT 认证阶段，还没有进入 WebSocket 握手。SOCKS5 直接转发 TCP，不经过这一层 CONNECT。协议选择可参考HTTP/HTTPS/SOCKS5 代理怎么选。

WebSocket 握手和长连接怎么验证？

先用最小请求确认代理 IP 生效

先用同一组代理参数请求一个回显出口 IP 的接口，再访问目标服务。如果检测到的出口 IP 仍是本机地址，先不要分析 WebSocket 握手，应检查客户端是否真正接管了当前流量、系统代理是否冲突，以及主机、端口、账号或密码是否填错。白名单只在明确采用 API 提取方式时检查。

```bash
curl -v --proxy http://user:pass@proxy.example:8080 https://api.ipify.org?format=json
```

再检查握手请求和 101

WebSocket 客户端应发送类似下面的请求头：

```http
GET /socket HTTP/1.1
Host: ws.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: <random-base64-key>
Sec-WebSocket-Version: 13
```

服务端成功时返回 101 Switching Protocols，并带有 Sec-WebSocket-Accept。返回 200，通常说明请求被当成普通 HTTP 处理；返回 400 或 426，优先检查 Upgrade/Connection 头、请求路径和上游是否支持 WebSocket。返回 407，则回到上面的代理认证或 CONNECT 阶段排查。

可以用 wscat 做最小复现：

```bash
wscat -c wss://ws.example.com/socket --proxy http://user:pass@proxy.example:8080
```

最后观察心跳、超时和重连

连接建立后仍要验证 ping/pong、空闲时长和重连策略。连接总是在约 60 秒断开，先查反向代理的读超时；断开时间每次不同，则更像上游主动关闭、网络抖动或出口 IP 轮换。关闭码 1000/1001 通常是正常关闭，1006 表示没有收到正常的关闭帧，不能单独据此断定是代理 IP 失效。

WebSocket 代理 IP 怎么选

WebSocket 选型看的是一条连接要持续多久，而不是只看协议名称：

• 行情推送、聊天机器人、实时面板、长驻订阅等需要长时间保持同一连接的任务，通常评估静态住宅代理 IP，减少出口 IP 轮换触发的重连。
• 短时、允许断线重连的批量订阅或多地区测试，可以评估动态住宅代理 IP；粘性时长应高于单条连接的预期时长，但不能承诺在线时长与设置值完全一致。
• 只做连通性、速度或成本验证，且目标服务对住宅属性要求不高时，可以评估机房代理 IP。

如果连接在动态住宅代理 IP 切换出口后立即重连，先记录切换时间、关闭码和新的出口 IP，再判断这是产品行为还是反向代理超时，不要把两类问题混在一起。

WebSocket 错误排查：按错误码定位哪一跳

1. 407：检查代理主机、端口、账号、密码和认证方式；只有使用 API 提取方式时才检查白名单。
2. 400 或 426：检查反向代理是否使用 HTTP/1.1、是否转发 Upgrade 和 Connection，以及 proxy_pass/upstream 路径是否一致。
3. TLS 或证书错误：确认目标域名、SNI、证书名称和客户端 TLS 版本；HTTP 代理 IP 的 CONNECT 成功不代表上游 TLS 一定成功。
4. 502：如果 upstream 健康检查正常但 WebSocket 返回 502，先核对 proxy_pass 指向的端口、Host/SNI 和 DNS；如果 error log 出现 connection refused，优先检查 upstream 是否监听了错误端口，并保留原始日志。
5. 504 或固定时长断开：如果连接总是在接近同一时长后断开，比较 upstream 的响应间隔和 proxy_read_timeout，再确认客户端心跳是否早于链路最短的空闲超时。
6. 随机断开或 1006：对照上游关闭原因、出口 IP 是否变化、重连次数和请求并发，不要只更换代理 IP 重试。

需要进一步拆分客户端、代理 IP、本地网络和目标站问题时，先按本文的四段链路记录状态码、响应头、出口 IP 和日志；网络超时、连接拒绝和 TLS 问题也要保留原始错误文本，避免只凭“连接失败”归因。连续 3 次在同一阶段失败，或目标服务返回 403、429、验证码时，应先停止扩大请求并按平台规则处理。

Nginx 和 Caddy WebSocket 配置怎么分流？

已经确认普通 HTTP 正常、问题集中在反向代理配置时，再看对应服务器文章：

• Nginx：重点核对 proxy_http_version 1.1、Upgrade/Connection 头和 proxy_read_timeout，参阅Nginx WebSocket 反向代理配置与连接失败排查。
• Caddy：重点核对 reverse_proxy、upstream、TLS/SNI 和 transport 超时，参阅Caddy WebSocket 反向代理配置与常见错误。

FAQ

连接约 60 秒后断开，先查哪里？

先查反向代理的 proxy_read_timeout 和上游空闲超时；如果客户端每 30 秒发送一次心跳，超时时间应明显高于 30 秒。断开时间不固定时，再对照上游日志和出口 IP 轮换记录。

WebSocket 长连接适合哪种代理 IP？

需要长时间保持同一连接时，通常评估静态住宅代理 IP；可以接受重连的短时任务，再评估动态住宅代理 IP，并把重连和失败重试写进客户端逻辑。

什么时候应该停止继续重试？

连续 3 次在同一错误阶段失败，或出现 403、429、验证码等目标服务明确拒绝信号时，应先降低频率、缩小范围或停止任务，记录状态码、响应头、关闭原因和出口 IP 后再决定下一步。代理 IP 不用于规避目标服务的访问限制。

参考：WebSocket RFC 6455、Nginx WebSocket、Caddy reverse_proxy。