对话走到一半画面停住、声音断掉，先不要急着换网络：把「本地预览是否也卡」和「连接状态是否在重连」两条线索放在一起看，通常能把问题分到网络侧与会话侧两类。本地预览流畅而远端停住，多半在传输、对端采集或转发环节；本地预览也卡，先看设备采集、编码和浏览器资源；控制台与网络面板里出现周期性连接重建，则更接近会话超时或心跳失效。

判别顺序建议：先用本地预览把采集与传输分开，再看网络面板和控制台里连接是否反复重建，然后用传输量时间轴与前后台切换做交叉验证，最后用空闲计时把「画面停住」与「连接断开」两种现象分开记录。连接保持但画面停住，更像媒体传输或渲染问题；连接被重建、且空闲间隔接近某个固定值，更像会话超时或心跳丢失。单次现象不足以定性，建议至少记录三轮对照再下判断；具体到 Loxinity 的空闲阈值与心跳配置，需要结合该产品自身的设置项与日志确认。

在开发者工具里看连接状态有没有反复重连

第一步要分清「连接掉了」和「连接还在但没声音没画面」。打开浏览器开发者工具的 Network 面板，勾选 Preserve log，再按类型筛选：信令走长连接的，选 WS；如果是轮询式信令，就切到 Fetch/XHR，用 socket、signal、rtc 之类的关键字过滤。连接类条目一般会经历 pending、101 或 200、最后关闭，Time 列给出这条连接存活了多久。

• 卡顿发生的瞬间，观察连接条目有没有关闭再新建。没有新建，说明会话还在，问题在媒体通道或渲染。
• 每出现一次卡顿就伴随一次连接重建，或者重建间隔很规律，更偏向会话侧，比如心跳没发出去、空闲超时被服务端断开。
• Console 面板同样勾选 Preserve log，把断开前后的报错原文、堆栈首行和记录时间抄下来，不要只截一张图。

如果 Loxinity 客户端提供日志导出或诊断入口，建议在复现问题时同时导出一次完整会话日志，与上面的时间线对照，比单看浏览器面板更可靠。

// 在 Console 粘贴，给后续所有观察打上相对时间戳
const t0 = Date.now();
const log = (...a) => console.log(`+${((Date.now() - t0) / 1000).toFixed(1)}s`, ...a);
document.addEventListener('visibilitychange', () => log('visibility', document.visibilityState));
window.addEventListener('offline', () => log('offline'));
window.addEventListener('online', () => log('online'));

只看本地画面预览，判断卡在采集还是传输

多数音视频界面都有「关闭摄像头」「隐藏远端画面」或设备预览这类入口；页面里没有的话，可以先停掉远端视频元素，或单独打开一个只显示自己摄像头的预览页。这样做的目的是把本地采集渲染与远端传输两条链路拆开。

• 本地预览流畅、远端画面停住：说明采集和编码大致正常，重点查上行带宽占用、下行传输、对端采集或服务端转发。先看看本机是不是在同时上传大文件、跑备份或其他视频会议。
• 本地预览也在掉帧或冻结：优先怀疑设备、采集权限、编码负载和浏览器资源。关掉其它占用较高的标签页，把分辨率或帧率调低一档再试。
• 两边都卡时，下一步不是继续换网络，而是打开系统任务管理器看浏览器进程的 CPU 与内存占用，再用同一台机器上的另一个浏览器复现一次，区分设备问题与页面问题。

把两条线索合起来，可以按下面这张顺序表判断先做哪一步：

用网络面板的传输量变化替代看丢包率

没有专业抓包工具时，看数据量随时间起伏，往往比猜丢包率更有用。先说明一个常见误区：基于 WebRTC 的媒体流通常不走 HTTP，Network 面板里看不到媒体包，只能看到信令和部分长连接。想近似观察媒体收发量，可以在 Chrome 或 Edge 打开 webrtc-internals 页面，盯住 bytesSent、bytesReceived 这类计数曲线的走势；如果 Loxinity 走的是 WebSocket 或 HTTP 长连接承载媒体，那就直接在 Network 面板按 WS 或 XHR 过滤，看消息条数与载荷大小的变化。

• 按时间轴对齐：先记住卡顿发生的大致秒数，再回看曲线在该时刻是平滑下降、突然归零，还是基本没变。
• 数据量在卡顿瞬间归零且再没恢复，更像传输中断；曲线一直有数据但画面不动，更像渲染、解码或对端丢帧。
• 切换 Wi-Fi 与有线，或换一个接入点后再复现一次，对照两次的曲线形态是否一致。形态随网络路径变化，说明问题偏网络侧。

切到别的标签页再切回来，看是否被后台节流

浏览器会节流后台页面的定时器和渲染，页面不可见时动画帧基本停止。对话卡住后，切到别的标签页停留一会儿再切回来，是一个成本很低的排除动作。

• 切换前记录：画面是否卡、连接条目是否还在、有没有报错。
• 切换后记录：画面是立刻恢复、延迟几秒恢复，还是完全不动甚至触发重连。
• 如果切回后画面自动恢复且连接条目没变，多半是渲染或定时器被节流，不是会话超时；如果切回后连接仍然重建，才回到会话侧继续查。

页面可见性变化时，前面那段日志会打出 visibility 的取值，把切换时间点与卡顿时间点对齐，就能确认现象是否与后台状态相关。

记录空闲多久后断开，区分超时与卡顿

「画面停住」和「连接断开」是两种现象，要分开记录。做法很简单：在最后一次看到画面更新或听到声音时开始静默计时，直到页面出现提示或连接条目关闭为止，记下这段间隔。

• 断开时先看页面提示出现在哪个位置：是右上角提示条、居中对话框，还是顶部横幅；把文案原样记下来，注意里面有没有重连、超时、会话结束这类词。
• 同时看 Network 面板对应条目是正常关闭还是异常关闭，以及关闭的先后顺序。
• 多次测量后写成对照表，而不是只记一次结论。

多次间隔接近同一个数值，更接近客户端或服务端配置的空闲超时；间隔忽长忽短，且断开前后传输量有明显骤降，更接近网络抖动。需要提醒的是，间隔接近并不等于一定超时，还要结合期间有没有心跳消息、信令请求是否还在发送来判断；如果心跳一直在发却依然断开，就要去查服务端或客户端侧的超时设置，而不是继续换网络。