Safari 中定位 WebSocket 异常断开，确实棘手。光盯着 onclose 事件往往不够。得把 Network 面板、Console 日志和 iOS 系统的“小脾气”结合起来看，才能揪出元凶。关键线索包括：

• Network 面板里 101 升级响应、Upgrade 头和 Connection 头是否到位；
• Console 中 onclose.code 是不是常见的 1006；
• iOS 锁屏时的冻结痕迹 —— wasClean 为 false 且 reason 为空；
• 甚至还需要翻翻 TCP 层日志。

这些信息在 Safari 的 Web Inspector 里默认不全显示，得手动开启一些调试选项才能抓到。

在 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 环境，单独验证服务端链路是否通畅。

《夸克》非常好用的免费AI浏览器

下载APP查看