简介CS_WebRTC_Conference_Server_Peer.v4.1.1 是一套面向实时音视频通信开发者的 WebRTC 会议服务端 PeerServer 发布包适合需要搭建端对端会议、研究信令与连接管理的中高级开发者。资源围绕 RTCPeerConnection、RTCDataChannel、ICE 穿透及 SRTP/DTLS 加密等核心机制提供可部署的服务端实现并带有 Intel 平台相关的性能适配倾向。压缩包为 tgz 格式共 8 个文件约 16KB包含 2 个 js 主逻辑脚本、2 个 pem 证书文件、2 个 json 配置与依赖描述、1 个 sh 安装脚本及 1 个许可说明文本结构精简便于快速理解服务端启动、证书配置与依赖管理流程。目前已有 287 人浏览学习。通过该资源读者可获取一套可直接运行的会议服务端骨架掌握信令协调、连接建立与安全传输的落地思路并借助配置与脚本快速完成本地部署验证为后续扩展负载均衡与 QoS 策略打下基础。1. 从 CS_WebRTC_Conference_Server_Peer.v4.1.1 说起一套自托管多人会议服务端到底长什么样多人实时音视频这件事最容易被低估的不是编解码而是信令和拓扑。CS_WebRTC_Conference_Server_Peer.v4.1.1 这个标题里CS 通常指 Conference ServerPeer 指对等连接v4.1.1 是版本号。合起来看它描述的是一套自托管的 WebRTC 会议服务端核心职责是帮多个浏览器客户端完成信令交换、建立 P2P 媒体通道并在必要时做转发兜底。它解决的是「不想把会议数据交给第三方、又想快速跑起多人通话」这个诉求适合有内网部署需求、想自己掌控信令和媒体路径的开发者。很多人第一次搭 WebRTC 会议卡在信令服务器和 NAT 穿透上这套东西的价值就在于把这两块打包成可部署的服务端。2. 信令、ICE 与媒体拓扑先搞懂这套服务端在替你做什么2.1 信令服务器不是可选项而是会议的地基WebRTC 本身只规定了浏览器之间怎么传媒体没规定双方怎么找到对方。这个「找到对方」的过程就是信令。CS 这类服务端的第一个职责就是提供一个 WebSocket 或 HTTP 通道让每个加入房间的客户端把 SDP offer/answer 和 ICE candidate 发给服务端再由服务端转发给同房间的其他 peer。常见做法是客户端连上信令服务后先发一个 join 消息带上房间号和自己的 peerId服务端维护一个roomId - [peerId]的映射表新 peer 进来时通知房间内已有 peer由已有 peer 主动发起 offer。这个「谁先发 offer」的规则必须定死否则双方同时发 offer 会出现 glare 冲突表现为连接一直卡在 connecting。我一般会把信令消息设计成三类join/leave 控制消息、offer/answer 会话描述、candidate 网络候选。服务端只做转发和房间成员管理不解析 SDP 内容这样服务端逻辑足够薄出问题时容易定位是信令没到还是媒体没通。2.2 ICE 与 STUN/TURNP2P 能不能成全看这一步信令通了只是知道对方存在真正建立媒体通道要靠 ICE 框架去收集本机的候选地址。候选分三类host本机网卡地址、srflx经 STUN 反射出的公网地址、relay经 TURN 转发的地址。同一局域网内 host 候选就能直连跨公网时往往需要 srflx对称型 NAT 下只能靠 relay。服务端配置里通常要填 STUN/TURN 地址。STUN 只做地址发现成本低TURN 要转发媒体流带宽成本高。我的经验是内网会议只配 STUN 就够跨公网会议必须配 TURN否则一定有一部分用户连不上。TURN 的 credential 建议用临时凭证机制不要写死在客户端里。// 客户端构造 RTCPeerConnection 时的典型配置 const pc new RTCPeerConnection({ iceServers: [ { urls: stun:stun.example.internal:3478 }, { urls: turn:turn.example.internal:3478, username: 临时用户名, credential: 临时密码 } ], iceTransportPolicy: all // 设为 relay 可强制走 TURN用于排查 });这段配置里iceTransportPolicy是关键排查开关正常用all如果怀疑是 NAT 穿透失败临时改成relay强制走 TURN能通就说明是候选收集或 NAT 类型问题不能通就是 TURN 本身没配好。urls支持数组可以同时填多个 STUN 提高发现成功率。2.3 Mesh、SFU、MCUPeer 模式到底适合几个人标题里的 Peer 暗示了这套服务端偏向 P2P 直连模式也就是 Mesh 拓扑每个客户端和其他每个客户端都建一条 RTCPeerConnection。3 人会议每人维护 2 条连接5 人每人 4 条连接数按 n×(n-1)/2 增长。拓扑连接数n 人服务端带宽适用规模Meshn×(n-1)/2几乎为零24 人SFUn高转发550 人MCUn极高混流50 人以上Mesh 的优点是服务端几乎不耗带宽部署简单缺点是上行带宽随人数线性增长4 人以上普通家用上行就扛不住。所以这套 Peer 模式的服务端定位就是小规模会议。如果你要开 10 人以上的会得换 SFU 方案这是选型阶段就要想清楚的别等上线了才发现卡成幻灯片。3. 从零把服务端跑起来环境、配置与最小验证3.1 环境准备与依赖安装这类 Node.js 系的服务端常见依赖是 express 做 HTTP 服务、ws 做 WebSocket、以及一个静态文件服务托管前端页面。先确认 Node 版本建议 18 LTS 以上低版本对 WebSocket 和 TLS 的支持会有坑。# 确认运行时版本 node -v npm -v # 初始化并安装常见依赖 npm init -y npm install express ws安装完先别急着写业务跑一个最小 WebSocket 回声服务验证环境能回声说明端口和运行时都没问题。这一步花两分钟能省掉后面半小时的「到底是代码错还是环境错」的纠结。3.2 信令服务端最小实现下面是一个能支撑房间加入和消息转发的信令服务骨架逻辑刻意保持薄方便你在此基础上加鉴权、录制等能力。const express require(express); const http require(http); const { WebSocketServer } require(ws); const app express(); app.use(express.static(public)); // 托管前端页面 const server http.createServer(app); const wss new WebSocketServer({ server }); // roomId - Map(peerId - ws) const rooms new Map(); wss.on(connection, (ws) { ws.peerId null; ws.roomId null; ws.on(message, (raw) { let msg; try { msg JSON.parse(raw); } catch (e) { return ws.send(JSON.stringify({ type: error, reason: bad json })); } if (msg.type join) { ws.peerId msg.peerId; ws.roomId msg.roomId; if (!rooms.has(msg.roomId)) rooms.set(msg.roomId, new Map()); const room rooms.get(msg.roomId); // 通知已有成员有新 peer 进来了 for (const [pid, peer] of room) { peer.send(JSON.stringify({ type: peer-joined, peerId: msg.peerId })); } room.set(msg.peerId, ws); // 回给新成员当前房间成员列表 ws.send(JSON.stringify({ type: joined, peers: [...room.keys()].filter((id) id ! msg.peerId) })); return; } // offer / answer / candidate 一律定向转发 if ([offer, answer, candidate].includes(msg.type)) { const room rooms.get(ws.roomId); if (!room) return; const target room.get(msg.target); if (target target.readyState 1) { target.send(JSON.stringify({ ...msg, from: ws.peerId })); } } }); ws.on(close, () { const room rooms.get(ws.roomId); if (!room) return; room.delete(ws.peerId); for (const peer of room.values()) { peer.send(JSON.stringify({ type: peer-left, peerId: ws.peerId })); } if (room.size 0) rooms.delete(ws.roomId); }); }); server.listen(8080, () console.log(signaling on :8080));逻辑说明rooms用嵌套 Map 存房间和成员查找是 O(1)。join 时先广播给老成员再把自己加进去顺序不能反否则新成员会收到自己的加入通知。offer/answer/candidate 只做定向转发服务端不碰 SDP 内容这是保持服务端稳定的关键。参数上server.listen的端口要和前端 WebSocket 连接地址一致生产环境记得套 TLS否则浏览器在 HTTPS 页面下会拒绝连 ws://。3.3 客户端连接与最小通话验证服务端跑起来后用两个浏览器标签页分别加入同一房间验证能否看到对方的视频。客户端核心是拿到成员列表后对每个已有成员主动发 offer。const ws new WebSocket(ws://localhost:8080); const pcs new Map(); // peerId - RTCPeerConnection ws.onopen () { ws.send(JSON.stringify({ type: join, roomId: room1, peerId: peer- Date.now() })); }; ws.onmessage async (evt) { const msg JSON.parse(evt.data); if (msg.type joined) { // 对已有成员逐个发起连接 for (const pid of msg.peers) await createOffer(pid); } else if (msg.type peer-joined) { // 新成员由对方发起这里只等 offer } else if (msg.type offer) { const pc getPC(msg.from); await pc.setRemoteDescription(msg.sdp); const answer await pc.createAnswer(); await pc.setLocalDescription(answer); ws.send(JSON.stringify({ type: answer, target: msg.from, sdp: answer })); } else if (msg.type answer) { await pcs.get(msg.from).setRemoteDescription(msg.sdp); } else if (msg.type candidate) { await pcs.get(msg.from).addIceCandidate(msg.candidate); } }; async function createOffer(pid) { const pc getPC(pid); const offer await pc.createOffer(); await pc.setLocalDescription(offer); ws.send(JSON.stringify({ type: offer, target: pid, sdp: offer })); } function getPC(pid) { if (pcs.has(pid)) return pcs.get(pid); const pc new RTCPeerConnection({ iceServers: [{ urls: stun:stun.example.internal:3478 }] }); pc.onicecandidate (e) { if (e.candidate) ws.send(JSON.stringify({ type: candidate, target: pid, candidate: e.candidate })); }; pc.ontrack (e) { const video document.createElement(video); video.srcObject e.streams[0]; video.autoplay true; document.body.appendChild(video); }; pcs.set(pid, pc); return pc; }这里的关键约定是「已有成员发起 offer新成员只应答」避免双方同时发 offer。ontrack里把远端流挂到 video 元素上注意要设 autoplay否则浏览器不会自动播放。如果两个标签页在同一台机器上测试摄像头可能被占用可以用getUserMedia加{ video: true, audio: true }前先确认没有其他程序占用设备。4. 避坑与排查那些让会议连不上的真实原因4.1 现象双方都显示已加入但视频一直黑屏原因通常是 ICE 候选没交换成功或者交换了但没被addIceCandidate消费。常见于 candidate 在 setRemoteDescription 之前就到达此时addIceCandidate会抛错。解决办法是把早到的 candidate 先缓存进数组等 remoteDescription 设置完再批量添加。这个坑我踩过不止一次日志里只看到 candidate 消息发出去了但连接状态一直停在 checking。4.2 现象内网正常一跨公网就连不上原因是没有配 TURN或者 TURN 的 credential 过期。对称型 NAT 下 host 和 srflx 候选都无法建立连接必须有 relay 候选。排查方法是在客户端把iceTransportPolicy临时设为relay如果这样能通就确认是 NAT 穿透问题去检查 TURN 服务是否可达、凭证是否有效。注意 TURN 的 3478 是 UDP/TCP5349 是 TLS防火墙要放行对应端口。4.3 现象人一多就卡上行带宽跑满原因是 Mesh 拓扑下每个客户端要往 n-1 个方向发流。4 人会议每人上行要发 3 路普通宽带上行只有 1020Mbps一路 720p 就占 1.5Mbps 左右3 路加上重传很容易打满。解决办法是限制人数在 4 人以内或者降低分辨率和码率用RTCRtpSender.setParameters把 maxBitrate 压到 500kbps 左右。要开大会议就得上 SFU这是拓扑决定的不是调参能救的。4.4 现象服务端跑几天后内存持续上涨原因是房间成员断开时没有清理rooms里的映射或者 close 事件里ws.roomId已被置空导致删不掉。检查 close 回调里是否用ws.roomId和ws.peerId正确删除了成员并在房间为空时删除整个房间键。另外 WebSocket 的 ping/pong 心跳要开否则半开连接会一直占着内存。我一般会加一个定时器每 30 秒扫一遍readyState ! 1的连接强制清理。4.5 现象HTTPS 页面下 WebSocket 连接被浏览器拒绝原因是混合内容策略HTTPS 页面不允许连 ws://必须用 wss://。解决办法是给信令服务套 TLS 证书或者用反向代理统一入口。注意证书要覆盖你实际访问的域名自签证书浏览器会拦截测试阶段可以手动信任生产环境必须用受信任证书。5. 进阶把 Peer 模式压榨到极限的几个技巧5.1 用 Simulcast 让弱网用户也能看清Mesh 模式下虽然不能像 SFU 那样灵活选层但发送端可以开 Simulcast同时发高低两档分辨率接收端根据带宽选择订阅哪一档。配置方式是在addTransceiver时传sendEncodings。const transceiver pc.addTransceiver(track, { direction: sendrecv, sendEncodings: [ { rid: h, maxBitrate: 1500000, scaleResolutionDownBy: 1 }, { rid: l, maxBitrate: 300000, scaleResolutionDownBy: 2 } ] });rid是这档流的标识scaleResolutionDownBy: 2表示分辨率减半。接收端通过setParameters里的encodings选择订阅哪一档。注意 Simulcast 在 Mesh 下收益有限因为每条连接都要独立协商人数多时协商开销反而上升建议只在 34 人且网络差异大的场景用。5.2 用 getStats 做质量监控而不是靠感觉会议卡不卡不能靠用户喊要主动采集。pc.getStats()返回的 RTCInboundRtpStreamStats 里有 packetsLost、jitter、framesPerSecond这些是判断质量的硬指标。指标含义健康阈值packetsLost累计丢包数增量持续大于 0 需关注jitter抖动秒小于 0.03 可接受framesPerSecond接收帧率低于 15 明显卡顿roundTripTime往返时延小于 0.2 秒我一般每 5 秒采一次把增量丢包率和 jitter 打到日志里出问题时能直接看出是网络抖动还是编码跟不上。注意 getStats 是异步的别在 ontrack 里同步调会拿不到数据。5.3 一个我坚持了很久的习惯每次改完信令逻辑我一定先用两个标签页在本地跑一遍再上真机跨网络测。本地能通不代表跨网能通跨网能通不代表弱网能通。真正让我少加很多班的是在客户端加一个「连接状态面板」把 iceConnectionState、signalingState 和 getStats 的关键指标实时显示出来。出问题时不用猜看一眼状态就知道卡在哪一层。这套 Peer 模式的服务端不复杂复杂的是网络环境把可观测性做足比多写一百行业务代码都值。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/11 7:08:04 · 阅读 1.2k WebRTC多人会议服务端实战：信令、ICE与Mesh拓扑部署指南
简介CS_WebRTC_Conference_Server_Peer.v4.1.1 是一套面向实时音视频通信开发者的 WebRTC 会议服务端 PeerServer 发布包适合需要搭建端对端会议、研究信令与连接管理的中高级开发者。资源围绕 RTCPeerConnection、RTCDataChannel、ICE 穿透及 SRTP/DTLS 加密等核心机制提供可部署的服务端实现并带有 Intel 平台相关的性能适配倾向。压缩包为 tgz 格式共 8 个文件约 16KB包含 2 个 js 主逻辑脚本、2 个 pem 证书文件、2 个 json 配置与依赖描述、1 个 sh 安装脚本及 1 个许可说明文本结构精简便于快速理解服务端启动、证书配置与依赖管理流程。目前已有 287 人浏览学习。通过该资源读者可获取一套可直接运行的会议服务端骨架掌握信令协调、连接建立与安全传输的落地思路并借助配置与脚本快速完成本地部署验证为后续扩展负载均衡与 QoS 策略打下基础。1. 从 CS_WebRTC_Conference_Server_Peer.v4.1.1 说起一套自托管多人会议服务端到底长什么样多人实时音视频这件事最容易被低估的不是编解码而是信令和拓扑。CS_WebRTC_Conference_Server_Peer.v4.1.1 这个标题里CS 通常指 Conference ServerPeer 指对等连接v4.1.1 是版本号。合起来看它描述的是一套自托管的 WebRTC 会议服务端核心职责是帮多个浏览器客户端完成信令交换、建立 P2P 媒体通道并在必要时做转发兜底。它解决的是「不想把会议数据交给第三方、又想快速跑起多人通话」这个诉求适合有内网部署需求、想自己掌控信令和媒体路径的开发者。很多人第一次搭 WebRTC 会议卡在信令服务器和 NAT 穿透上这套东西的价值就在于把这两块打包成可部署的服务端。2. 信令、ICE 与媒体拓扑先搞懂这套服务端在替你做什么2.1 信令服务器不是可选项而是会议的地基WebRTC 本身只规定了浏览器之间怎么传媒体没规定双方怎么找到对方。这个「找到对方」的过程就是信令。CS 这类服务端的第一个职责就是提供一个 WebSocket 或 HTTP 通道让每个加入房间的客户端把 SDP offer/answer 和 ICE candidate 发给服务端再由服务端转发给同房间的其他 peer。常见做法是客户端连上信令服务后先发一个 join 消息带上房间号和自己的 peerId服务端维护一个roomId - [peerId]的映射表新 peer 进来时通知房间内已有 peer由已有 peer 主动发起 offer。这个「谁先发 offer」的规则必须定死否则双方同时发 offer 会出现 glare 冲突表现为连接一直卡在 connecting。我一般会把信令消息设计成三类join/leave 控制消息、offer/answer 会话描述、candidate 网络候选。服务端只做转发和房间成员管理不解析 SDP 内容这样服务端逻辑足够薄出问题时容易定位是信令没到还是媒体没通。2.2 ICE 与 STUN/TURNP2P 能不能成全看这一步信令通了只是知道对方存在真正建立媒体通道要靠 ICE 框架去收集本机的候选地址。候选分三类host本机网卡地址、srflx经 STUN 反射出的公网地址、relay经 TURN 转发的地址。同一局域网内 host 候选就能直连跨公网时往往需要 srflx对称型 NAT 下只能靠 relay。服务端配置里通常要填 STUN/TURN 地址。STUN 只做地址发现成本低TURN 要转发媒体流带宽成本高。我的经验是内网会议只配 STUN 就够跨公网会议必须配 TURN否则一定有一部分用户连不上。TURN 的 credential 建议用临时凭证机制不要写死在客户端里。// 客户端构造 RTCPeerConnection 时的典型配置 const pc new RTCPeerConnection({ iceServers: [ { urls: stun:stun.example.internal:3478 }, { urls: turn:turn.example.internal:3478, username: 临时用户名, credential: 临时密码 } ], iceTransportPolicy: all // 设为 relay 可强制走 TURN用于排查 });这段配置里iceTransportPolicy是关键排查开关正常用all如果怀疑是 NAT 穿透失败临时改成relay强制走 TURN能通就说明是候选收集或 NAT 类型问题不能通就是 TURN 本身没配好。urls支持数组可以同时填多个 STUN 提高发现成功率。2.3 Mesh、SFU、MCUPeer 模式到底适合几个人标题里的 Peer 暗示了这套服务端偏向 P2P 直连模式也就是 Mesh 拓扑每个客户端和其他每个客户端都建一条 RTCPeerConnection。3 人会议每人维护 2 条连接5 人每人 4 条连接数按 n×(n-1)/2 增长。拓扑连接数n 人服务端带宽适用规模Meshn×(n-1)/2几乎为零24 人SFUn高转发550 人MCUn极高混流50 人以上Mesh 的优点是服务端几乎不耗带宽部署简单缺点是上行带宽随人数线性增长4 人以上普通家用上行就扛不住。所以这套 Peer 模式的服务端定位就是小规模会议。如果你要开 10 人以上的会得换 SFU 方案这是选型阶段就要想清楚的别等上线了才发现卡成幻灯片。3. 从零把服务端跑起来环境、配置与最小验证3.1 环境准备与依赖安装这类 Node.js 系的服务端常见依赖是 express 做 HTTP 服务、ws 做 WebSocket、以及一个静态文件服务托管前端页面。先确认 Node 版本建议 18 LTS 以上低版本对 WebSocket 和 TLS 的支持会有坑。# 确认运行时版本 node -v npm -v # 初始化并安装常见依赖 npm init -y npm install express ws安装完先别急着写业务跑一个最小 WebSocket 回声服务验证环境能回声说明端口和运行时都没问题。这一步花两分钟能省掉后面半小时的「到底是代码错还是环境错」的纠结。3.2 信令服务端最小实现下面是一个能支撑房间加入和消息转发的信令服务骨架逻辑刻意保持薄方便你在此基础上加鉴权、录制等能力。const express require(express); const http require(http); const { WebSocketServer } require(ws); const app express(); app.use(express.static(public)); // 托管前端页面 const server http.createServer(app); const wss new WebSocketServer({ server }); // roomId - Map(peerId - ws) const rooms new Map(); wss.on(connection, (ws) { ws.peerId null; ws.roomId null; ws.on(message, (raw) { let msg; try { msg JSON.parse(raw); } catch (e) { return ws.send(JSON.stringify({ type: error, reason: bad json })); } if (msg.type join) { ws.peerId msg.peerId; ws.roomId msg.roomId; if (!rooms.has(msg.roomId)) rooms.set(msg.roomId, new Map()); const room rooms.get(msg.roomId); // 通知已有成员有新 peer 进来了 for (const [pid, peer] of room) { peer.send(JSON.stringify({ type: peer-joined, peerId: msg.peerId })); } room.set(msg.peerId, ws); // 回给新成员当前房间成员列表 ws.send(JSON.stringify({ type: joined, peers: [...room.keys()].filter((id) id ! msg.peerId) })); return; } // offer / answer / candidate 一律定向转发 if ([offer, answer, candidate].includes(msg.type)) { const room rooms.get(ws.roomId); if (!room) return; const target room.get(msg.target); if (target target.readyState 1) { target.send(JSON.stringify({ ...msg, from: ws.peerId })); } } }); ws.on(close, () { const room rooms.get(ws.roomId); if (!room) return; room.delete(ws.peerId); for (const peer of room.values()) { peer.send(JSON.stringify({ type: peer-left, peerId: ws.peerId })); } if (room.size 0) rooms.delete(ws.roomId); }); }); server.listen(8080, () console.log(signaling on :8080));逻辑说明rooms用嵌套 Map 存房间和成员查找是 O(1)。join 时先广播给老成员再把自己加进去顺序不能反否则新成员会收到自己的加入通知。offer/answer/candidate 只做定向转发服务端不碰 SDP 内容这是保持服务端稳定的关键。参数上server.listen的端口要和前端 WebSocket 连接地址一致生产环境记得套 TLS否则浏览器在 HTTPS 页面下会拒绝连 ws://。3.3 客户端连接与最小通话验证服务端跑起来后用两个浏览器标签页分别加入同一房间验证能否看到对方的视频。客户端核心是拿到成员列表后对每个已有成员主动发 offer。const ws new WebSocket(ws://localhost:8080); const pcs new Map(); // peerId - RTCPeerConnection ws.onopen () { ws.send(JSON.stringify({ type: join, roomId: room1, peerId: peer- Date.now() })); }; ws.onmessage async (evt) { const msg JSON.parse(evt.data); if (msg.type joined) { // 对已有成员逐个发起连接 for (const pid of msg.peers) await createOffer(pid); } else if (msg.type peer-joined) { // 新成员由对方发起这里只等 offer } else if (msg.type offer) { const pc getPC(msg.from); await pc.setRemoteDescription(msg.sdp); const answer await pc.createAnswer(); await pc.setLocalDescription(answer); ws.send(JSON.stringify({ type: answer, target: msg.from, sdp: answer })); } else if (msg.type answer) { await pcs.get(msg.from).setRemoteDescription(msg.sdp); } else if (msg.type candidate) { await pcs.get(msg.from).addIceCandidate(msg.candidate); } }; async function createOffer(pid) { const pc getPC(pid); const offer await pc.createOffer(); await pc.setLocalDescription(offer); ws.send(JSON.stringify({ type: offer, target: pid, sdp: offer })); } function getPC(pid) { if (pcs.has(pid)) return pcs.get(pid); const pc new RTCPeerConnection({ iceServers: [{ urls: stun:stun.example.internal:3478 }] }); pc.onicecandidate (e) { if (e.candidate) ws.send(JSON.stringify({ type: candidate, target: pid, candidate: e.candidate })); }; pc.ontrack (e) { const video document.createElement(video); video.srcObject e.streams[0]; video.autoplay true; document.body.appendChild(video); }; pcs.set(pid, pc); return pc; }这里的关键约定是「已有成员发起 offer新成员只应答」避免双方同时发 offer。ontrack里把远端流挂到 video 元素上注意要设 autoplay否则浏览器不会自动播放。如果两个标签页在同一台机器上测试摄像头可能被占用可以用getUserMedia加{ video: true, audio: true }前先确认没有其他程序占用设备。4. 避坑与排查那些让会议连不上的真实原因4.1 现象双方都显示已加入但视频一直黑屏原因通常是 ICE 候选没交换成功或者交换了但没被addIceCandidate消费。常见于 candidate 在 setRemoteDescription 之前就到达此时addIceCandidate会抛错。解决办法是把早到的 candidate 先缓存进数组等 remoteDescription 设置完再批量添加。这个坑我踩过不止一次日志里只看到 candidate 消息发出去了但连接状态一直停在 checking。4.2 现象内网正常一跨公网就连不上原因是没有配 TURN或者 TURN 的 credential 过期。对称型 NAT 下 host 和 srflx 候选都无法建立连接必须有 relay 候选。排查方法是在客户端把iceTransportPolicy临时设为relay如果这样能通就确认是 NAT 穿透问题去检查 TURN 服务是否可达、凭证是否有效。注意 TURN 的 3478 是 UDP/TCP5349 是 TLS防火墙要放行对应端口。4.3 现象人一多就卡上行带宽跑满原因是 Mesh 拓扑下每个客户端要往 n-1 个方向发流。4 人会议每人上行要发 3 路普通宽带上行只有 1020Mbps一路 720p 就占 1.5Mbps 左右3 路加上重传很容易打满。解决办法是限制人数在 4 人以内或者降低分辨率和码率用RTCRtpSender.setParameters把 maxBitrate 压到 500kbps 左右。要开大会议就得上 SFU这是拓扑决定的不是调参能救的。4.4 现象服务端跑几天后内存持续上涨原因是房间成员断开时没有清理rooms里的映射或者 close 事件里ws.roomId已被置空导致删不掉。检查 close 回调里是否用ws.roomId和ws.peerId正确删除了成员并在房间为空时删除整个房间键。另外 WebSocket 的 ping/pong 心跳要开否则半开连接会一直占着内存。我一般会加一个定时器每 30 秒扫一遍readyState ! 1的连接强制清理。4.5 现象HTTPS 页面下 WebSocket 连接被浏览器拒绝原因是混合内容策略HTTPS 页面不允许连 ws://必须用 wss://。解决办法是给信令服务套 TLS 证书或者用反向代理统一入口。注意证书要覆盖你实际访问的域名自签证书浏览器会拦截测试阶段可以手动信任生产环境必须用受信任证书。5. 进阶把 Peer 模式压榨到极限的几个技巧5.1 用 Simulcast 让弱网用户也能看清Mesh 模式下虽然不能像 SFU 那样灵活选层但发送端可以开 Simulcast同时发高低两档分辨率接收端根据带宽选择订阅哪一档。配置方式是在addTransceiver时传sendEncodings。const transceiver pc.addTransceiver(track, { direction: sendrecv, sendEncodings: [ { rid: h, maxBitrate: 1500000, scaleResolutionDownBy: 1 }, { rid: l, maxBitrate: 300000, scaleResolutionDownBy: 2 } ] });rid是这档流的标识scaleResolutionDownBy: 2表示分辨率减半。接收端通过setParameters里的encodings选择订阅哪一档。注意 Simulcast 在 Mesh 下收益有限因为每条连接都要独立协商人数多时协商开销反而上升建议只在 34 人且网络差异大的场景用。5.2 用 getStats 做质量监控而不是靠感觉会议卡不卡不能靠用户喊要主动采集。pc.getStats()返回的 RTCInboundRtpStreamStats 里有 packetsLost、jitter、framesPerSecond这些是判断质量的硬指标。指标含义健康阈值packetsLost累计丢包数增量持续大于 0 需关注jitter抖动秒小于 0.03 可接受framesPerSecond接收帧率低于 15 明显卡顿roundTripTime往返时延小于 0.2 秒我一般每 5 秒采一次把增量丢包率和 jitter 打到日志里出问题时能直接看出是网络抖动还是编码跟不上。注意 getStats 是异步的别在 ontrack 里同步调会拿不到数据。5.3 一个我坚持了很久的习惯每次改完信令逻辑我一定先用两个标签页在本地跑一遍再上真机跨网络测。本地能通不代表跨网能通跨网能通不代表弱网能通。真正让我少加很多班的是在客户端加一个「连接状态面板」把 iceConnectionState、signalingState 和 getStats 的关键指标实时显示出来。出问题时不用猜看一眼状态就知道卡在哪一层。这套 Peer 模式的服务端不复杂复杂的是网络环境把可观测性做足比多写一百行业务代码都值。希望帮到你。本文还有配套的精品资源点击获取