[!info] related notes

• 所属 MOC: 浏览器开发者工具 MOC, DevTools Network MOC
• 相关概念: SSE 与 WebSocket 调试, 请求与响应检查, Security / Issues 面板
• 易混淆概念: SSE, WebSocket, 实时通信：SSE vs WebSocket vs Polling, SSE 连接缓存问题

DevTools 流式连接排查路线

范围

这条路线处理的是：

• SSE 一直处于 CONNECTING
• WebSocket 握手失败或反复断开
• 流式输出突然中断、消息不连续
• 代理、压缩、缓冲破坏了长连接

为什么要放在一起理解

流式连接问题常常不是“业务逻辑没写对”，而是连接建立、传输链路和中间层行为出了问题。

排查时必须把这几层分开：

• 协议有没有建立成功
• 消息流有没有持续到达
• 中间层有没有改写 Header、压缩流、缓存结果

排查路线

第一步：先确认连接有没有真正建立

打开 Network 面板：

• SSE 看 Content-Type: text/event-stream
• WebSocket 看握手是否成功
• 看状态码、响应头和连接持续时间

第二步：看是不是中间层破坏了流

重点检查：

• 是否错误启用了压缩
• 是否存在代理缓冲
• 是否有重定向、认证中间件、CORS 或 Header 丢失

这一层优先读 SSE 与 WebSocket 调试。

第三步：看消息流是否真的在动

如果连接建起来了，还要继续看：

• SSE 数据是否持续追加
• WebSocket Frames / Messages 是否正常收发
• 断开前有没有异常关闭码或错误事件

第四步：再看认证和站点状态

很多流式连接失败并不是传输本身坏了，而是：

• 认证没通过
• Cookie / Token 没带上
• 刷新 token 或长连接鉴权链路不一致

这时回到：

• 登录态异常排查路线
• Cookie 调试

第五步：最后再怀疑业务协议层

如果连接和消息流都正常，才继续查：

• 业务消息格式
• 心跳策略
• 客户端状态机和重连逻辑

对比与易混淆点

• SSE 连接建不起来，常见是代理、压缩、缓冲问题，不一定是前端代码
• WebSocket 握手成功，不代表业务消息一定正常
• “看起来像超时”可能其实是认证失败或中间层提前断开

迁移检查

场景：SSE 在本地正常，经过生产 Nginx/CDN 后每 20 秒一次性吐出一大块数据。

不看正文：

1. 先证明连接是否建立成功；
2. 这种现象为什么更像 buffering/flush 而不是前端 parser？
3. 要在 Network、代理配置、服务端日志分别找什么证据？
4. 如果 WebSocket 握手成功但业务无消息，为什么排查路径要从 transport 转向协议/state machine？

Related notes

• 浏览器开发者工具 MOC
• DevTools Network MOC
• SSE 与 WebSocket 调试
• 请求与响应检查