WebRTC在实时通信中的NAT穿透怎么解决
摘要：# WebRTC连不上？聊聊NAT穿透那些让人头大的事儿 我前两天帮一个做在线教育的客户排查问题，他们用的WebRTC做一对一视频辅导，结果总有那么几个学生死活连不上老师。老师在北京，学生在山东，两边网络都没问题，可视频就是卡在“正在连接”转圈圈。折腾了…
WebRTC连不上？聊聊NAT穿透那些让人头大的事儿
我前两天帮一个做在线教育的客户排查问题，他们用的WebRTC做一对一视频辅导，结果总有那么几个学生死活连不上老师。老师在北京，学生在山东，两边网络都没问题，可视频就是卡在“正在连接”转圈圈。折腾了一下午，最后发现——又是NAT穿透没搞定。
说实话，这种场景你应该不陌生吧？但凡做过实时音视频的，谁没在NAT这块栽过跟头？今天咱们就抛开那些晦涩的RFC文档，用人话聊聊WebRTC到底怎么跨过NAT这道坎。
先搞明白：NAT为啥成了“拦路虎”？
说白了，NAT（网络地址转换）就是你家的路由器。公网IP地址不够分啊，运营商就给你家一个公网IP，家里所有手机、电脑都用这个IP上网。路由器负责记帐：小明的手机发了个请求，回来数据包得精准送回小明手机。
这本来挺好，但到了P2P直连的场景就麻烦了。
想象一下：你想直接给朋友家打电话，但朋友家没装门牌号（只有内网IP），你只知道他住哪个小区（公网IP）。你对着小区喊：“老王，出来接电话！”——这能行吗？NAT设备根本不知道“老王”对应的是家里哪台设备。
WebRTC的理想很美好：让两个浏览器直接传音视频数据，别老经过服务器中转（费流量、延迟高）。但现实是，超过70%的用户都在各种NAT后面蹲着呢。不解决穿透，P2P就是句空话。
核心三板斧：STUN、TURN、ICE（不是让你全用）
很多教程一上来就堆概念，其实咱们得知道什么时候用哪个。
第一招：STUN——先问问“我在别人眼里长啥样”
STUN服务器干的事特别简单：你（浏览器）向它发个请求：“大哥，从你的角度看，我的地址是啥？”它回你：“你看起来是120.230.76.44:55002。”
这就是你的“公网映射地址”。NAT设备在转发你的包时，会把你的内网地址（比如192.168.1.101:5000）替换成这个公网地址。
如果双方都是“完全锥型NAT”（Full Cone NAT）——这种NAT最友好，谁从公网发数据到这个映射端口都能进来——那STUN一配，双方交换下这个公网地址，直接就能连上了。
但问题来了：现在这种“好说话”的NAT越来越少了。运营商怕安全风险，很多都用“对称型NAT”（Symmetric NAT）。这种NAT特别较真：你对STUN服务器发请求，它给你开个映射端口（比如55002）；但如果你换个人（比如想连的同学）发数据，它会给你开个全新的端口（比如55003）。
得了，STUN在这种情况下就废了。你告诉对方你是55002，结果对方真往55002发数据，你的NAT根本不认。
第二招：TURN——实在不行就“中转”
TURN服务器就是个中转站。双方都连到TURN服务器，所有数据都通过它转发。这肯定能通，因为这是标准的客户端-服务器模式，NAT都放行。
但代价也明显：延迟增加（多了一跳）、流量费翻倍（数据要先上传到TURN再下载）、服务器压力大。很多小团队初期图省事，全走TURN，结果业务量一上来，带宽账单看得手抖。
我自己的经验是：TURN是保底方案，不是默认方案。你得用，但不能全靠它。
第三招：ICE——让系统自己选条最好的路
ICE（交互式连接建立）不是个具体服务器，而是一套决策机制。它的工作流程挺聪明：
- 收集所有可能的“候选地址”：包括你的本地IP、通过STUN获取的公网地址、通过TURN分配的中转地址。
- 双方通过信令服务器（比如你的业务服务器）交换这些候选地址列表。
- 开始“打洞测试”：浏览器自动尝试用各种地址组合互相发测试包。
- 按优先级连接：优先尝试P2P直连（最省最快），不行再 fallback 到TURN中转。
关键在这里：ICE不是让你手动配置用哪个，而是“让浏览器自己试，哪个通就用哪个”。这就像你要去一个地方，导航给你规划了高速、国道、小路，它自己会实时看哪条路堵车，然后选最优的。
那些容易踩的坑（我亲自踩过的）
- “我开了STUN，为啥还连不上？” —— 大概率是你俩有一个在对称NAT后面。这时候STUN给的地址是“一次性”的，没用。得靠TURN兜底。
- “TURN服务器怎么配才不烧钱？” —— 别把所有用户都默认丢给TURN。用ICE，让只有真正需要中转的用户（比如双方都在严格对称NAT后）才走TURN。实测能省下60%以上的中转流量。
- “信令服务器用啥协议？” —— WebRTC本身不管信令。你爱用WebSocket、Socket.io甚至HTTP轮询都行。关键是要快，别让候选地址交换半天，那边NAT映射都超时失效了。
- 移动网络更头疼：4G/5G网络很多是运营商级NAT（Carrier-Grade NAT），穿透难度更大。有时候在WiFi下能P2P，一切蜂窝网络就 fallback 到TURN了——这是正常现象，不是你的bug。
给个实在的建议吧
如果你正在选型或者调试，可以按这个思路来：
第一步：找个靠谱的公共STUN服务器列表（比如Google的stun:stun.l.google.com:19302）配上去。免费的，先用着。
第二步：TURN服务器必须自己搭（或者用云服务商的）。因为TURN要转发你的媒体数据，用别人的既不安全，性能也没保障。推荐用coturn这个开源项目，部署不算复杂。
第三步：在WebRTC的配置里，把ICE候选地址收集策略设为all（收集所有类型），并且一定要开启iceTransportPolicy: relay的fallback。这样浏览器在P2P实在没戏时，会自动切到TURN。
最后说句大实话：WebRTC的NAT穿透，没有一劳永逸的银弹。它就是个“尽最大努力P2P，不行就中转”的务实方案。别指望100%的用户都能直连——尤其是在国内复杂的网络环境下，能有六七成直连率就算不错了。
关键是把ICE流程跑对，把TURN备好，剩下的，就交给浏览器自己去折腾吧。毕竟，网络这玩意儿，有时候就跟天气一样，你只能适应，没法完全控制。
行了，如果你正在调WebRTC，遇到具体问题，欢迎来聊聊——这玩意儿，谁调谁知道，坑永远比想象的多。