WebRTC最迷人的地方在于它能让浏览器之间直接传输音视频数据，不经过服务器中转。但很多人在动手实践时会卡在同一个环节：SDP交换完成了，ICE候选者也收集了，可就是对不连，控制台里一堆日志看不出所以然。问题的根源往往不在WebRTC本身，而在信令服务器没搭好，或者STUN、TURN没配置到位。本文借助AI工具来生成一套可用的信令服务器代码，同时把NAT穿透的原理和配置细节讲透。
一、信令服务器到底负责什么
先厘清一个容易被误解的概念：WebRTC标准本身并没有定义信令协议。也就是说，两个浏览器如何交换建立连接所需的信息，完全由开发者自己决定。这套信息交换的通道就叫信令服务器，它只负责传递两类关键数据：SDP会话描述和ICE候选者。
SDP描述了浏览器想发送和接收的媒体能力，比如编码格式、分辨率、音频参数。ICE候选者则是本机收集到的候选连接地址，包括本机内网IP、STUN服务器探测出的公网映射地址、TURN服务器的中继地址。这两类数据必须在双方建立点对点连接之前互相交换到位，而此时双方还没有任何直接通道，所以必须依赖一台双方都能访问的服务器来中转这些消息。
一个常见的误区是把信令服务器和流媒体服务器混为一谈。信令服务器只在建连阶段工作，交换完信息、点对点通道打通之后，音视频数据直接在两个浏览器之间传输，信令服务器不再参与媒体转发。理解了这一点，就明白为什么信令服务器可以用很轻量的WebSocket服务来实现。
二、用AI生成一套Node.js信令服务器
手动写信令服务器容易遗漏边界情况，比如房间满员、重复加入、异常断开后的清理。把需求描述清楚后交给AI生成初版代码，再人工审查修正，效率会高很多。给AI的提示词可以这样写：基于Node.js和ws库实现WebRTC信令服务器，支持创建房间、加入房间、广播SDP、交换ICE候选者，客户端断开时通知房间内其他成员。
AI生成的核心代码大致如下，人工检查过消息路由逻辑后即可使用：
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });
// 房间结构：roomId -> Set<ws>
const rooms = new Map();
function joinRoom(ws, roomId) {
if (!rooms.has(roomId)) rooms.set(roomId, new Set());
const room = rooms.get(roomId);
if (room.size >= 2) {
ws.send(JSON.stringify({ type: 'room-full' }));
return;
}
room.add(ws);
ws.roomId = roomId;
// 通知先加入的一方：有新人来了，你该发起offer
room.forEach(client => {
if (client !== ws) {
client.send(JSON.stringify({ type: 'peer-joined' }));
}
});
}
wss.on('connection', (ws) => {
ws.on('message', (data) => {
const msg = JSON.parse(data);
const room = rooms.get(ws.roomId);
switch (msg.type) {
case 'join':
joinRoom(ws, msg.roomId);
break;
case 'offer':
case 'answer':
case 'candidate':
// 把信令消息转发给房间里的另一个人
room.forEach(client => {
if (client !== ws) client.send(JSON.stringify(msg));
});
break;
}
});
ws.on('close', () => {
const room = rooms.get(ws.roomId);
if (room) {
room.delete(ws);
room.forEach(client => {
client.send(JSON.stringify({ type: 'peer-left' }));
});
if (room.size === 0) rooms.delete(ws.roomId);
}
});
});
console.log('信令服务器已启动，监听8080端口');这段代码的交互顺序是：A先加入房间，B随后加入，服务器通知A有人加入，A创建RTCPeerConnection并生成offer发给服务器，服务器转发给B，B设置远程描述后回answer，之后双方不断交换ICE候选者。注意这里没有使用WebSocket集群和Redis，单机内存存储房间状态只适合开发调试，生产环境如果信令服务要水平扩展，需要把房间状态外置到Redis，并按房间做消息路由。
另外提醒一点，AI生成的代码经常忽略鉴权和信令校验，拿到生成结果后务必补上token验证逻辑，防止任何人都能向任意房间注入伪造的offer。信令通道被劫持的后果是攻击者可以冒充一方加入通话。
三、STUN与TURN的工作机制差异
信令通了只是第一步，真正的连接建立靠ICE框架。ICE会同时收集三类候选者：主机候选者（本机内网IP）、服务器反射候选者（通过STUN探测到的公网映射地址）、中继候选者（TURN服务器分配的中转地址）。收集完成后按优先级逐对测试连通性，这个过程就是常说的打洞。
STUN的工作方式很简单：客户端向STUN服务器发一个请求，服务器把看到的源IP和端口返回，客户端就知道了自己在公网上的映射地址，把这个地址通过信令告诉对方，双方尝试直接互连。对于完全锥形NAT和受限锥形NAT，这种方式成功率高。但对于对称型NAT，同一客户端访问不同目标会得到不同的映射端口，STUN探测到的地址对另一个客户端无效，直连基本会失败。
TURN就是为这种失败场景兜底的。客户端提前和TURN服务器建立长连接，TURN分配一个中继地址，所有无法直连的媒体流量都经由这台服务器转发。代价是带宽和延迟：TURN服务器要承载实际的媒体流量，成本远高于STUN。实践中普遍的做法是STUN和TURN都配置，让ICE优先尝试直连，直连不成自动降级到中继，绝大多数通话能直连，只有少数对称NAT用户走TURN。
四、coturn部署与生产环境配置要点
开源方案里coturn是事实标准，部署在公网服务器上，配置STUN和TURN两种服务。下面是一份经过验证的最小可用配置：
# /etc/turnserver.conf listening-port=3478 tls-listening-port=5349 # 对外IP，云服务器上填写公网地址 external-ip=你的公网IP realm=ipipp.com # TURN认证用户，生产环境建议用REST API临时密码 user=calluser:yourStrongPassword lt-cred-mech # 开启长期凭证机制 fingerprint # 建议开启日志便于排查 log-file=/var/log/turnserver.log verbose
前端配置非常简单，把Google公共STUN和自建TURN一起写进iceServers即可：
const pc = new RTCPeerConnection({
iceServers: [
{ urls: 'stun:stun.l.google.com:19302' },
{
urls: ['turn:你的服务器IP:3478', 'turns:你的服务器IP:5349'],
username: 'calluser',
credential: 'yourStrongPassword'
}
]
});
// 监听候选者状态，判断最终走的是直连还是中继
pc.addEventListener('icegatheringstatechange', () => {
console.log('收集状态:', pc.iceGatheringState);
});部署时有几个高频踩坑点值得记录。第一，云服务器安全组必须放行3478、5349端口，同时放行TURN的中继端口范围，coturn默认使用49152到65535之间的随机端口做媒体中继，不开这段范围会导致直连失败后中继也建立不起来。第二，浏览器从Chrome高版本开始限制了对称NAT环境下的ICE候选者类型，某些网络下会强制走TURN，预算带宽时要留足余量。第三，排查连接问题时看iceConnectionState的变化，如果长时间停留在checking然后变成failed，基本可以判定直连和TURN都没通，优先检查TURN服务器的external-ip配置和安全组。还可以访问Trickle ICE这类在线测试页面，逐项验证STUN和TURN是否真的能拿到候选地址。
把信令、STUN、TURN三块都跑通之后，建议再补上信令的断线重连和TURN的临时凭证接口，这两点是从演示到生产必须跨越的门槛。信令部分逻辑不复杂，真正决定通话成功率的是网络层面的穿透方案，理解ICE的候选者优先级和降级机制，比死记配置参数有用得多。