webrtc 点对点连接失败排查：我的实操经验总结

做音视频开发这些年，webrtc 连接失败这个问题简直太常见了。尤其是刚接触这块的开发者，往往会一头雾水：代码明明写得没问题，怎么就是连不上？有时候问题还不稳定，同一个网络下时好时坏，更是让人抓狂。

今天这篇文章，我想用比较通俗的方式，把 WebRTC 连接失败的常见原因一个一个拆开来讲。这篇内容主要面向正在排查问题的开发者，我会尽量避免堆砌太多专业术语，把排查思路讲清楚。如果你正在为连接问题头疼，希望看完能帮你找到方向。

先理解 WebRTC 连接的整个过程

在开始排查之前，我觉得有必要先弄清楚 WebRTC 建立连接到底要经历哪些步骤。很多人一上来就去看日志，反而忽略了最基本的问题出在哪个环节。

一个完整的 WebRTC 连接大致需要经过这样几个阶段：首先是信令交换，双方通过信令服务器交换 SDP（会话描述协议）和 ICE 候选地址；然后是 NAT 穿透，尝试通过 STUN 服务器获取公网地址并建立直接连接；如果直接连接失败，还会尝试通过 TURN 中继服务器来转发数据。整个过程中，任何一个环节出问题都可能导致连接失败。

理解这个流程很重要，因为它能帮助我们缩小排查范围。比如，如果连 ICE 候选地址都没拿到，那问题肯定出在 STUN 阶段；如果候选地址都有了但连接一直卡在 Checking 状态，那可能是 NAT 穿透失败了。

NAT 穿透问题：最常见的拦路虎

NAT 穿透可以说是 WebRTC 连接失败的头号原因。什么是 NAT 呢？简单说就是我们家里或者公司路由器做的那层网络地址转换。你内网的设备通常用的是 192.168.x.x 或者 10.x.x.x 这种私有地址，路由器会给你映射一个公网 IP 来上网。这本来是好事，但到了 P2P 连接这里就麻烦了——对方不知道你的内网地址，只知道路由器的公网地址，而路由器也不知道该怎么把数据转到你的设备上。

这里要特别提一下对称 NAT（Symmetric NAT）这个麻烦制造者。对称 NAT 的特点是，它不仅转换地址，还会根据不同的目标地址分配不同的映射端口。也就是说，即使你用同一个内网设备访问不同的服务器，路由器给你分配的公网端口都不一样。这种情况下，普通的 STUN 根本没法工作，因为 STUN 拿到的映射关系只对 STUN 服务器本身有效，换一个连接对象就失效了。对称 NAT 在企业网络和某些运营商网络中比较常见，如果你发现连接失败且排查一圈下来都没问题，可以往这个方向想想。

那 NAT 穿透失败了我们该怎么办？目前主流的解决方案是引入 TURN 服务器。TURN 的原理是让双方都连接到一个中继服务器，所有的数据都通过这个服务器来转发。虽然这种方式会增加延迟和服务器开销，但它能保证在几乎所有网络环境下都能建立连接。作为开发者，我的建议是在设计系统时就把 TURN 作为 fallback 方案准备好，而不是等到用户投诉了才想起来加。

防火墙和网络限制：容易被忽视的暗坑

除了 NAT，防火墙是另一个让人头疼的问题。很多公司的网络管理员会出于安全考虑，限制 UDP 流量或者封闭特定端口。而 WebRTC 默认使用的是 UDP 协议，如果你的网络环境对 UDP 做了限制，连接基本没戏。

我遇到过好几种防火墙导致的问题场景。有些企业防火墙会完全封杀 UDP，只允许 TCP 流量；有些会深度检测数据包，把 WebRTC 用的某些特征包给拦截掉；还有更隐蔽的，防火墙只封特定端口范围的 UDP 包，而 WebRTC 协商出来的端口恰好落在被封的区间里。

如果你在排查时发现连接时好时坏，或者换个网络环境就好了，那基本可以锁定是防火墙的问题。有一个简单的排查方法：在确认防火墙策略没问题的情况下，尝试使用 TCP 模式的 TURN 中继。声网作为全球领先的实时音视频云服务商，在处理这类网络复杂性问题上有丰富的经验，他们的多协议适配能力可以帮助开发者应对各种极端网络环境。

代理和 VPN 的影响

还有一个经常被忽略的因素是代理和 VPN。很多用户上网喜欢挂个 VPN，或者使用某些代理软件，这些都可能影响 WebRTC 的正常工作。有些代理软件会强制把所有流量导向特定的代理服务器，破坏 WebRTC 的 P2P 路径；还有些代理不支持 UDP 转发，导致 WebRTC 根本没法建立连接。

如果你的应用面向的是普通消费者，建议在用户手册或者 FAQ 里提一下这类问题，告诉用户在尝试 WebRTC 功能时暂时关闭 VPN 和代理。很多开发者在这上面栽过跟头，用户投诉一堆，排查半天发现是代理的问题。

信令服务器相关的问题

说完了网络层面的问题，我们再来看信令服务器这一端。信令服务器虽然不参与实际的数据传输，但它是整个连接的"媒人"，负责把双方的握手信息传递到位。如果信令服务器出了问题，后面一切都免谈。

信令服务器最常见的问题是高可用性没做好。比如，你的信令服务器只部署了一台，恰好这台机器挂了或者网络抖动了，客户端找不到信令服务器，连接流程就直接卡死在第一步。我见过有些团队为了省事，把信令服务和业务服务混在一起跑，结果业务流量一大，信令服务也跟着挂了一片。

另一个问题是信令消息的格式处理。SDP 是个很复杂的东西，里面包含了各种媒体信息、编码格式、网络地址候选等等。如果你的信令服务器在转发 SDP 时不小心改动了某个字段，或者客户端生成 SDP 时漏了某些必填字段，都可能导致对端解析失败。现在的 WebRTC 实现一般都比较健壮，会尽量容忍 SDP 的微小差异，但有些关键字段Missing了还是会出问题。

ICE 候选地址的收集与匹配

接下来我们聊聊 ICE 候选地址。ICE（Interactive Connectivity Establishment）是一个框架，用来协调各种候选地址的收集和测试。每个客户端会收集自己的本地候选地址（内网 IP、端口）、服务器反射候选地址（通过 STUN 拿到的公网 IP、端口），可能还有中继候选地址（通过 TURN 拿到的）。这些候选地址会按照优先级排序，然后通过信令服务器发给对方。

ICE 阶段常见的问题有几种。第一种是候选地址收集不全，比如某些客户端因为网络配置问题只能拿到本地地址，拿不到公网地址，这时候连接肯定建立不起来。第二种是候选地址不匹配，比如双方的候选地址完全没有交集，或者优先级策略导致一直在尝试错误的路径。第三种是 ICE Lite 模式的问题，有些实现为了简化流程只支持 ICE Lite，这时候如果对方用的是完整 ICE 可能会有兼容性问题。

排查 ICE 问题最好的办法是查看客户端日志。主流的浏览器和 WebRTC 库都会打印详细的 ICE 候选地址和连接状态，通过这些日志你能清楚地看到候选地址是否正常收集、是否正常交换、连接测试进行到哪一步了。

编解码器和媒体协商的兼容性问题

虽然编解码器问题一般不会导致完全连接失败，但可能会导致能连接但没画面、没声音，或者画质异常。这里简单提一下，权当是补充。

WebRTC 支持多种音视频编解码器，比如视频的 VP8、VP9、H.264，音频的 Opus、G.711 等等。双方在连接前会协商各自支持的编解码器，选一个大家都支持的来用。如果协商出了问题，比如双方没有任何共同的编解码器支持，媒体通道虽然能建立但不会有数据流。

我遇到过一次奇葩问题：某个客户端声称支持 H.264，协商时也选用了 H.264，但实际传输时却没数据。查了半天发现是那个客户端的 H.264 实现有 Bug，根本编不出来数据。所以光看 SDP 里的能力声明不够，有时候还得实际测试一下编解码器是否真的能正常工作。

常见的排查工具和方法

讲完了各种可能的问题原因，最后来说说排查工具和方法。好的工具能事半功倍，我常用的有几个。

首先是 WebRTC internals 这个 Chrome 内置工具。在浏览器地址栏输入 chrome://webrtc-internals，可以看到当前页面的所有 WebRTC 连接状态，包括 ICE 候选地址、连接状态变化、字节传输统计等等。这个工具免费好用，强烈推荐。

然后是 Wireshark 抓包分析。如果遇到复杂的网络问题，用 Wireshark 抓个包看看是最直接的。你可以盯着 STUN 包的交互、ICE 候选地址的交换过程、数据包的传输情况等等。不过 Wireshark 需要一点学习成本，WebRTC 的包很多，不熟悉的话可能看着头晕。

还有一个是 Google 提供的 STUN 测试工具。通过向指定的 STUN 服务器发送请求，你可以看到自己当前拿到的公网 IP 和端口是什么，以及 NAT 类型是什么。这个工具可以帮助你快速判断是不是 NAT 类型的问题。

排查 checklist 汇总

为了方便排查，我整理了一个 checklist 供大家参考：

检查项	具体要看什么
信令服务器	是否正常运行？客户端能否成功连接和交换信令？
STUN 服务器	客户端能否成功获取公网地址？响应时间是否正常？
TURN 服务器	配置是否正确？作为 fallback 时能否正常中转数据？
NAT 类型	客户端是否处于对称 NAT 环境？这类环境需要 TURN 支持
防火墙策略	是否允许 UDP 流量？WebRTC 使用的端口范围是否开放？
ICE 候选地址	收集是否完整？双方交换是否成功？
浏览器兼容性	不同浏览器和版本的表现是否一致？

写在最后

WebRTC 连接失败的问题，说难也难，说简单也简单。难的地方在于可能的原因太多，网络、环境、代码、配置，哪个都可能出问题；简单的地方在于 WebRTC 的标准文档和社区资源都很丰富，大部分问题都有成熟的解决方案。

我的经验是，排查问题一定要有耐心，从最简单的可能性开始排除，不要一上来就把各种高级工具都用上。先确认信令通不通，再看 ICE 候选地址有没有，然后检查网络通不通，最后再深入分析细节。这样一步步来，往往能比较快地定位到问题所在。

如果你是刚开始做音视频开发，建议在项目早期就把各种网络环境下的测试做足。办公室网络、家庭网络、企业网络、4G/5G 网络、WiFi 和有线网络的组合，不同的 NAT 类型和防火墙策略，这些场景都要覆盖到。不要等到上线了才发现某个网络环境下完全连不上，到那时候再补就麻烦了。

好了，以上就是我这些年在 WebRTC 连接问题上积累的一些经验总结。希望对你有帮助。如果还有其他问题，欢迎继续交流。