调试与排障：日志系统、Wireshark抓包分析、常见问题排查指南

做WebRTC开发，说白了就是跟各种莫名其妙的问题打交道。我见过太多人，代码写得挺溜，一遇到线上问题就抓瞎。其实调试排障这事儿，有章可循。今天我就把压箱底的经验掏出来，跟你聊聊怎么用好日志、怎么抓包分析、以及那些我踩过的坑。

日志系统：你的第一道防线

日志这东西，平时觉得没啥，出问题的时候它就是救命稻草。WebRTC内部有一套完整的日志体系，但很多人不知道怎么用好它。

开启Native日志

在Chrome或者基于Chromium的浏览器里，你可以通过命令行参数开启WebRTC的内部日志。我个人习惯用这个组合：

--enable-logging --v=1 --vmodule=*/webrtc/*=2

解释一下：

• --enable-logging：开启日志输出
• --v=1：全局日志级别，1是基本信息，2是详细，3是调试
• --vmodule：针对特定模块设置更细的级别

我在项目中遇到过一个问题，视频一直黑屏，但音频正常。打开日志一看，发现是视频编码器初始化失败，日志里明确写着 Failed to create video encoder。嗯，顺着这个线索，很快就定位到是GPU驱动兼容性问题。

JavaScript侧的日志

前端开发时，RTCPeerConnection 的 oniceconnectionstatechange 和 onconnectionstatechange 是你最该盯住的。我习惯这样打日志：

pc.oniceconnectionstatechange = () => {
  console.log(`[ICE状态] ${pc.iceConnectionState}`);
  if (pc.iceConnectionState === 'failed') {
    console.warn('ICE连接失败，开始排查...');
  }
};

pc.onconnectionstatechange = () => {
  console.log(`[连接状态] ${pc.connectionState}`);
};

你想想看，如果连状态变化都不打日志，出了问题就只能靠猜了。

Wireshark抓包分析：深入网络层

日志能告诉你「发生了什么」，但Wireshark能告诉你「为什么」。这是我最常用的调试手段，没有之一。

抓包前的准备

首先，你得让Wireshark认识WebRTC的流量。WebRTC默认使用DTLS加密，所以你需要导出密钥。Chrome支持这个：

1. 设置环境变量 SSLKEYLOGFILE=/path/to/keylog.txt
2. 启动Chrome，访问你的WebRTC应用
3. 在Wireshark中设置 Edit -> Preferences -> Protocols -> TLS -> (Pre)-Master-Secret log filename

有了密钥，你就能看到加密后的RTP/RTCP包内容了。我记得有一次排查音画不同步问题，就是靠这个发现发送端的NTP时间戳和RTP时间戳对应关系错了。

关键过滤表达式

Wireshark里流量太杂，你得学会过滤。我常用的几个：

过滤表达式	作用
rtp	只看RTP包
rtcp	只看RTCP包
stun	只看STUN包（ICE相关）
dtls	只看DTLS握手包
rtp.ssrc == 123456	只看特定SSRC的流

分析RTP流

Wireshark的 Telephony -> RTP -> Show All Streams 是个神器。它能列出所有RTP流，并显示丢包率、抖动、延迟等关键指标。我一般先看这几个：

• 丢包率：超过5%就要警惕了
• 抖动：超过30ms会影响体验
• 序列号跳变：说明有包乱序或丢失

有一次客户反馈视频卡顿，我一看丢包率才1%，但抖动高达80ms。再深入看，发现是Wi-Fi信号不稳定导致突发延迟。嗯，这种问题光看丢包率是看不出来的。

常见问题排查指南

下面这几个问题，我敢说你迟早会遇到。我把排查思路整理成了一张图：

问题一：连接失败

这是最常见的。排查步骤：

1. 看ICE状态：如果卡在 checking 不动，大概率是STUN/TURN配置有问题
2. 检查STUN/TURN服务器：用 curl 或者在线工具测试一下服务器是否可达
3. 抓包看STUN响应：如果STUN请求发出去了但没收到响应，那就是防火墙拦了

我曾经遇到一个案例，客户说「我们内网能用，外网就不行」。一查，TURN服务器配置的是内网IP。嗯，这种低级错误其实挺常见的。

问题二：音画不同步

这个问题的根因，90%是时间戳不对。排查思路：

• 检查发送端是否用了同一个时钟源来生成音频和视频的RTP时间戳
• 用Wireshark看RTP包的 Timestamp 字段，音频和视频的增量是否匹配
• 确认接收端的 RTCP SR（发送端报告）中的NTP时间戳和RTP时间戳对应关系

问题三：卡顿和花屏

卡顿的原因很多，但排查路径是固定的：

1. 先看丢包率：如果丢包率超过10%，那就是网络问题，考虑FEC或NACK
2. 再看抖动：抖动大说明网络不稳定，考虑增加jitter buffer
3. 最后看编码器：如果网络没问题，那就是编码器参数不合理，比如码率设太高

我记得有一次，用户说「视频偶尔花一下」。我抓包一看，丢包率才0.5%，但花屏确实存在。后来发现是编码器的关键帧间隔设得太长，导致丢包后要等很久才能恢复。把 keyFrameInterval 从3000ms改成1000ms，问题解决。

调试排障这事儿，说白了就是「日志+抓包+经验」的组合。日志告诉你表象，抓包告诉你真相，经验帮你快速定位。别怕遇到问题，每个坑都是你成长的阶梯。

---