24、WebRTC的调试与排错：常用调试工具（chrome://webrtc-internals）、常见错误码解析、日志分析技巧
做WebRTC开发，最头疼的是什么？不是信令协议写不对，也不是媒体流推不上去。而是——明明代码逻辑看起来都对，但就是连不上。这时候你盯着屏幕，浏览器控制台一片空白，ICE状态卡在checking，然后超时断开。
嗯，这种场景我遇到过太多次了。说实话，WebRTC的调试排错，是区分初级和资深工程师的一道分水岭。今天我就把压箱底的调试经验拆开揉碎了讲给你听。
24.1 调试第一利器：chrome://webrtc-internals
我个人习惯，只要遇到WebRTC连接问题，第一件事就是打开这个页面。你可以在Chrome地址栏直接输入 chrome://webrtc-internals，它会实时记录当前所有PeerConnection的详细状态。
这个工具能看什么？我列几个最常用的面板：
- ICE Connection State：实时显示ICE状态变化（new → checking → connected → completed 或 failed）
- Candidate Pair：当前正在尝试的候选者组合，以及它们的优先级和延迟
- Stats Graphs：比特率、丢包率、RTT的实时曲线图
- Event Log：所有ICE事件的时间线，包括STUN/TURN请求和响应
我记得有一次线上问题，用户反馈视频通话经常卡顿然后断开。我远程连上去一看，webrtc-internals里显示ICE状态在connected和disconnected之间反复横跳。再一看Candidate Pair，发现TURN候选者的RTT高达800ms。说白了，就是TURN服务器离用户太远了。后来换了就近的TURN节点，问题就解决了。
24.2 常见错误码解析：ICE失败到底是谁的锅？
WebRTC的错误码不像HTTP那么直观。很多错误都藏在ICE状态机里。我整理了一份最常见的错误场景对照表，你调试时可以直接对照：
| 错误现象 | 可能原因 | 排查方向 |
|---|---|---|
| ICE状态卡在checking然后超时 | STUN/TURN服务器不可达，或防火墙阻断了UDP | 检查turn服务器地址和端口，用telnet测试连通性 |
| ICE状态在connected和disconnected之间切换 | 网络不稳定，或TURN服务器负载过高 | 查看RTT曲线，考虑切换TURN节点 |
| 收到ICE失败事件，但日志没有具体原因 | 候选者类型不匹配（如双方都只有host候选者但不在同一网络） | 检查双方SDP中的candidate行，确认是否有srflx或relay类型 |
| 媒体流建立但无声音/画面 | 编解码器协商失败，或SSRC冲突 | 查看SDP中的m=行，确认codec列表是否一致 |
为什么会这样？我举个例子。有一次我排查一个跨NAT的连接问题，双方都在公司内网，但就是连不上。打开webrtc-internals一看，双方都只生成了host类型的候选者。说白了，就是STUN服务器没返回公网映射地址。后来发现是STUN服务器配置错了端口，UDP包被防火墙丢了。
24.3 日志分析技巧：从海量日志中快速定位问题
WebRTC的日志量非常大。如果你直接打开chrome://webrtc-internals的Event Log，会发现每秒可能有几十条日志。怎么从里面找到关键信息？我分享几个实用技巧：
24.3.1 关注ICE状态变化的时间点
你不需要逐条看所有日志。先找到ICE状态变化的时间戳，然后只看这个时间点前后2秒内的日志。比如ICE从checking变成failed的那一瞬间，前后日志里一定有线索。
24.3.2 搜索关键词
在Event Log里，直接搜索以下关键词：
STUN：看STUN请求是否发出，响应是否收到TURN：看TURN分配是否成功candidate：看候选者类型和优先级error：看是否有明确的错误描述failed：定位失败事件
24.3.3 对比双方日志
很多时候问题出在双方状态不一致。比如A方已经connected了，B方还在checking。这时候你需要把双方的webrtc-internals日志都导出来，对比同一时间点的ICE状态和候选者列表。
24.4 知识体系总览
下面这张图总结了WebRTC调试排错的核心流程。你可以把它当作一个检查清单，遇到问题时按这个顺序排查：
这张图的核心逻辑很简单：先确认ICE状态，再检查候选者，然后根据成功或失败走不同分支。我每次排查问题都按这个流程走，基本不会漏掉关键信息。
24.5 实战：一个完整的排查案例
最后，我分享一个真实的排查案例。有一次用户反馈，在某个酒店WiFi下无法建立WebRTC连接。我远程连上用户的电脑，打开webrtc-internals，看到以下现象：
- ICE状态从checking直接跳到了failed，中间没有经过connected
- Candidate Pair列表为空，说明没有找到任何可用的候选者对
- Event Log里只有STUN请求，没有收到任何STUN响应
嗯，看到这里我基本有数了。STUN请求发出去没响应，说明UDP被阻断了。我让用户切换到手机热点（4G网络），问题立刻消失。后来跟酒店IT确认，他们的WiFi确实禁用了UDP 3478端口。解决方案是让用户使用TURN over TCP作为备选。
公众号:蓝海资料掘金营，微信deep3321