[!info] related notes

• 所属 MOC: DevTools Network MOC
• 协议: SSE, WebSocket
• 请求检查: 请求与响应检查
• 排障路线: 流式连接排查路线
• SSE 特例: SSE 连接缓存问题

DevTools SSE 与 WebSocket 调试

先区分两种 transport

SSE：

• HTTP response 保持打开；
• server → client 单向事件；
• 重点看 response headers 与 event stream。

WebSocket：

• 建立协议升级/连接；
• 双向 message frames；
• 重点看 handshake 与 Frames/Messages。

两者都“长连接”，但证据结构不同。

SSE：连接建立了吗

先检查：

• request 是否发出；
• status；
• Content-Type 是否为 text/event-stream；
• response 是否保持打开；
• 是否持续收到 event data；
• CORS/credentials 是否满足。

如果 response 很快结束：

→ 服务端、代理或错误路径可能提前关闭连接。

SSE：为什么连着但没有增量

继续检查：

• 服务端是否 flush；
• reverse proxy 是否 buffering；
• compression 是否导致大块缓冲；
• event framing 是否正确；
• heartbeat 是否存在；
• 中间层 timeout。

“状态一直 pending”对正常 SSE 并不一定是错误，因为 response 本来就长期不结束。

WebSocket：握手成功了吗

经典 HTTP/1.1 WebSocket 握手通常会看到 101 Switching Protocols。

如果握手失败，先看：

• request URL / scheme；
• Origin；
• authentication；
• proxy 是否支持 upgrade；
• server response。

不要先排业务 message parser。

WebSocket：连接后看 Frames / Messages

连接成功以后再检查：

• client 是否真的发送 message；
• server 是否响应；
• opcode / text/binary；
• payload；
• close frame / close code；
• 重连是否发生。

连接成功只证明 transport 建立，不证明业务协议正确。

Proxy / Gateway 是常见故障层

长连接经过：

• Nginx；
• CDN；
• API Gateway；
• load balancer；

时，需要检查：

• idle timeout；
• buffering；
• protocol support；
• sticky/state requirements；
• header forwarding。

浏览器 DevTools 只能看到客户端一侧证据；复杂问题需要和 gateway/server log 对齐 trace/request ID。

诊断顺序

SSE

1. 请求是否发出；
2. status / Content-Type；
3. response 是否保持 open；
4. 是否有 event 增量；
5. proxy buffer/timeout；
6. server flush/log。

WebSocket

1. handshake；
2. connection open；
3. Frames/Messages；
4. close code；
5. reconnect；
6. proxy/server log。

迁移检查

给两个故障：

A. SSE 返回 200，但 30 秒后才一次性出现全部 token。
B. WebSocket 已连接，但点击发送后服务端没有业务响应。

分别写出：

1. 第一批浏览器证据；
2. 最可能的中间层/业务层分界；
3. 下一步要找的服务端日志；
4. 为什么不能把“transport connected”当成“业务成功”。