网页正常，实时连接却失败？WebSocket 握手与断线排查

网页能打开，实时消息却一直连接中，先分清是握手没有完成，还是建立连接后又断开。网页和实时接口可能使用不同地址；首页正常、节点测速正常，都不能代替对那条连接的检查。

作者：小六｜资料核对日期：2026年10月30日

本文适用于浏览器中的 WebSocket 连接。地址常以 ws:// 或 wss:// 开头，后者通过 TLS 加密。若请求实际采用 SSE，可参考本站实时内容成批出现与断流排查，两种机制需要分别判断。

先找到失败的实时请求

以 Chrome 为例，打开开发者工具的 Network（网络）面板，再重现问题，选择 WS 筛选项。点开对应连接，在 Headers 查看地址与握手信息，在 Messages 查看消息和时间，操作入口见 Chrome 官方说明。

记录目标域名、建立时间、是否收到过消息，以及断开前的错误。没有找到 WS 请求时，先取消筛选，确认操作是否触发了连接，别把普通网页请求当成实时接口。

例如首页是 www.example.com，实时接口却是 live.example.com，排查应围绕后者。这个例子仅说明地址关系，不是可用测试服务。

以下对照适用于 HTTP/1.1 的 Upgrade 握手：

MDN 的 101 说明解释了协议切换。仅看到数字还不够，浏览器也要接受相关握手字段；握手通过更不能保证后面的业务一直正常。

这个表不能直接套到所有 HTTP 版本。RFC 8441定义的 HTTP/2 扩展 CONNECT 方式可以使用 200 建立 WebSocket，不使用上述 101 升级流程。先确认实际握手方式，再解释状态。

对于 403，先确认账号登录状态、接口路径和服务方提示。来源检查也是一种可能：RFC 6455允许服务端根据 Origin 决定是否接受连接。因此，403 本身不能证明节点故障，也不能仅凭它确定是哪一层拒绝。

1006 与 HTTP 403 属于不同的编号体系。MDN 关闭码说明将它列为异常关闭；RFC 6455 进一步规定，它是保留值，不能由端点放进 Close 帧发送。

可以把它理解为“没有完成正常的关闭交代”。先找更早出现的握手报错，或最后一条消息之后发生了什么，不能只拿一个 1006 就判断服务端、代理节点或本机谁出了问题。

如果曾经持续收到消息，重点记录最后收包到断开的间隔；如果从未成功建立，则回到握手阶段检查。两种情况的下一步不同。

保持同一浏览器、账号和操作，每次只改变一个条件。在客户端连接记录中寻找实时接口域名，核对它命中的规则和实际链路；首页走了所选节点，不代表另一个子域名也走同一路径。

需要比较两个节点时，先确认没有重要操作，再让目标页面建立新连接。旧会话可能仍保留原链路，具体可看切换节点后的长连接检查方法。

若某一路径稳定复现失败，另一条正常，这只是缩小了检查范围。还应保留失败阶段、时间和目标记录，不能据此直接给整个服务下结论。

这种现象值得检查中间层的空闲限制。以网站使用 Nginx 反向代理为例，官方文档说明：默认情况下，上游连续 60 秒没有传来数据会关闭连接，可调整读取超时，或由上游周期性发送 Ping 帧。

这里是特定组件的默认行为，不能推成所有网站都只能连一分钟。应记录“最后收到数据到断开”的间隔，由维护者核对实际配置与心跳；机场客户端的节点健康检查也不能替网站发送 WebSocket 心跳。

网站维护者还需按其 HTTP/1.1 部署检查 Upgrade、Connection 的转发。普通访客可反馈现象，这些远端设置不能通过本机切换一个代理开关直接修改。

准备浏览器与客户端版本、目标域名和时间、握手结果或关闭码、换路径后重新连接的对照结果。截图遮住 Cookie、认证字段、含令牌的查询参数及私人消息，不必提交完整订阅或整份会话记录。

想交流网页正常但实时连接失败的问题，可以带上这些脱敏线索：Telegram 联系我