
如何排查本地网络中的 WebRTC 摄像头问题
WebRTC 摄像头的故障看起来可能很突然,因为在第一帧出现之前要经过多个步骤。应用会获取信令信息、收集网络候选、协商点对点连接并启动原生视频解码器。即使其中任何一步失败,遥测数据仍可能正常。
在 Printer Tools 中,Creality K2 以及受支持的远程摄像头路径都使用 WebRTC。不要把它们当作简单的 MJPEG URL 来排查。
确认信令来源
Printer Tools 应从受支持的打印机或服务获取 WebRTC offer、会话详情或端点。一个恰好显示 WebRTC 画面的普通网页,不能作为视频流 URL 粘贴进来。
请确认打印机的确切型号,并使用最新版本的应用。按型号进行的路由决定了 Printer Tools 是否应该尝试使用 WebRTC。
区分遥测和摄像头协商
如果仪表板能通过打印机 API 更新,但 Live View 失败,请记录这一点。这说明本地路径的一部分是通的,从而把问题缩小到信令、候选、媒体或解码。
如果两者都失败,请先修复打印机地址和网络路由,再去解读 WebRTC 消息。
检查 ICE 和网络候选
在简单的局域网中,双方可以通过本地候选直接连接。VLAN 规则、VPN、多个活动网络接口以及客户端隔离,都可能产生无法访问的候选,或在信令成功后阻断媒体路径。
请把手机和打印机都放在主局域网中进行测试。测试期间只关闭发生冲突的 VPN,之后应设计明确的路由,而不是让保护措施一直处于关闭状态。
保持原生运行环境为最新
WebRTC 播放使用原生库。如果发布优化时删除了必要的原生类或二进制文件,构建可能可以正常编译,但在运行时失败。在整理回归报告之前,请使用 Printer Tools 的最新官方版本。
如果打开摄像头时应用关闭,请记录确切的版本和平台,并在重新启动后导出日志。不要在进行对打印至关重要的操作时反复触发崩溃。
解读常见症状
- 立即被拒绝,说明端点或本地服务不可用;
- 一直处于连接中,说明信令或 ICE 协商没有完成;
- 有音频或状态却没有画面,说明媒体轨道或解码器有问题;
- 画面开始后又卡住,说明存在网络丢包、码率压力或解码器停滞;
- 应用被终止,说明原生运行环境出现故障,需要确切的构建信息。
避免不安全的网络变通做法
不要把信令或媒体端口大范围暴露到互联网。远程访问请使用受支持的服务流程或可信的 VPN。过于宽松的路由器规则可能掩盖问题,同时让摄像头面临严重暴露风险。
关于 Creality 的具体设置,请参阅 K2 WebRTC 摄像头指南。
常见问题
WebRTC 只是另一个视频 URL 吗?
不是。它包括信令、候选协商和媒体轨道,而不只是一个静态的视频流路径。
为什么 WebRTC 失败时打印机数据仍然正常?
打印机 API 和摄像头的点对点连接使用不同的服务和网络流量。
我应该转发所有候选端口吗?
不应该。不要开放大范围的公网端口。请修复本地路由,或使用受支持的远程访问方式。
崩溃报告中应包含哪些内容?
应用版本、平台、打印机型号、固件、确切的操作,以及重新启动后导出的新加密日志。
官方资料: MDN — WebRTC API · RFC 8445 — ICE





