如何在Safari浏览器控制台中排查WebSocket连接异常频繁断开的问题？
Safari中定位WebSocket异常断开，须结合Network面板检查101升级响应及Upgrade/Connection头、Console中onclose.code（如1006）、iOS锁屏冻结痕迹（wasClean=false且reason为空）及TCP层日志。
要在 Safari 浏览器控制台中准确定位 WebSocket 频繁异常断开的根源，不能只看 onclose 是否触发，必须结合 Network 面板的协议升级细节、Console 中的事件码、以及 iOS 系统特有的冻结行为痕迹——这些信息在 Safari 的 Web Inspector 中默认不全显示，需手动开启特定调试选项才能捕获。
启用 Safari Web Inspector 的 WebSocket 详细日志
打开 Safari → 偏好设置 → 高级 → 勾选“在菜单栏中显示‘开发’菜单”；然后访问目标页面 → 开发 → 当前页面 → 显示 Web 检查器；切换到“网络”标签页 → 左下角点开过滤器图标 → 勾选“WebSocket”；关键一步：右键表头区域 → 勾选“状态码”和“协议”两列，否则看不到 101 升级响应是否真正返回。
这一步漏掉，“协议”列为空，你就永远不知道连接是否卡在握手阶段。
从 Network 面板确认握手是否成功
刷新页面，在 Network 面板中找到 ws:// 或 wss:// 请求项，点击它：
查看响应状态行是否为 HTTP/1.1 101 Switching Protocols；
检查 Response Headers 中是否存在 Upgrade: websocket 和 Connection: Upgrade；
若状态是 200、403、502 或直接无响应，说明服务端或 Nginx 根本没完成协议升级——此时连接会在 1 秒内关闭，onclose.code 通常为 1006，但根本不是“断开”，而是“压根没连上”。
在 Console 中捕获并解析 onclose 事件细节
在控制台粘贴并执行以下代码，强制覆盖全局 WebSocket 构造函数，注入诊断日志：
const originalWS = window.WebSocket; window.WebSocket = function(url, protocols) { const ws = new originalWS(url, protocols); ws.onclose = function(event) { console.groupCollapsed(`【WS closed】${url} | code:${event.code} | wasClean:${event.wasClean} | reason:${event.reason || '(empty)'}`); console.trace(); console.groupEnd(); }; return ws; };
这段代码会把每次断开的完整调用栈、code、wasClean 和 reason 打印出来。iOS Safari 锁屏后触发的断连，往往 event.wasClean === false 且 code === 1006，但 reason 为空——这是系统级静默终止的铁证，不是你的 JS 报错。
验证心跳是否被冻结（iOS 专属）
在控制台中运行以下检测脚本：
第一步：记录当前时间 → const t0 = Date.now();
第二步：锁屏 15 秒后唤醒 → 再次执行 console.log(Date.now() - t0);
如果输出值远小于 15000（比如只有 2000），说明 setInterval 已被 Safari 冻结；此时任何基于定时器的心跳都会失效，服务端在空闲超时后必然发 RST 断连。
第三步：立即检查 WebSocket.readyState → 若为 0（CONNECTING）或 3（CLOSED），说明实例已被销毁，不能再调 send 或 close。
抓取真实 TCP 层中断信号（需配合 macOS 控制台）
方法一：打开 macOS “控制台”App → 左侧选择“报告”→ 筛选关键词 “websocket” 或 “tcp”；
方法二：终端执行 sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder 清理 DNS 缓存后重试，排除 DNS 解析延迟导致的假性握手失败；
方法三：在 Safari 开发 → 开发者工具 → 网络 → 右键 WebSocket 请求 → “复制为 curl”，粘贴到终端执行，观察是否返回 101 —— 这能绕过页面 JS 环境，单独验证服务端链路是否通畅。