Cloudflare Realtime SFU 故障排查与调优实战指南Gotchas Troubleshooting【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills本指南以 Cloudflare Realtime SFUSelective Forwarding Unit的故障排查文档为核心系统梳理从首连慢无媒体流到ICE 失败网络切换断线等高频问题的成因与解决方案并给出可复制的 ICE 重启、指数退避重试等 TypeScript 代码。读完本文你将掌握基于 WebRTC 会话Session与轨道Track模型构建实时音视频应用时的完整排障方法论、chrome://webrtc-internals调试技能以及 SFU 平台的资源限额与安全基线可直接用于生产环境的联调与上线前检查。一、故障排查全景六个高频问题速览Cloudflare Realtime SFU 的核心心智模型是客户端与 Cloudflare 边缘建立一个 WebRTC 会话Session发布本地轨道Track音频/视频/数据通道通过后端共享轨道 ID其他客户端用轨道 ID 会话 ID订阅远端轨道详见 realtime-sfu/README.md。当链路出现问题时问题往往集中在 SDP 协商、ICE 打洞、轨道发布/订阅状态这三个层面。原文档gotchas.md给出了六类最常遇到的错误症状核心成因关键动作慢初始连接~1.8s共识形成阶段首个 STUN 被延迟等待后续连接靠 CF 提前探测 DTLS ClientHello 补偿无媒体流SDP 交换不完整、连接未建立、offer 前未添加轨道、浏览器权限缺失按 5 步链路逐项核对轨道收不到数据轨道未发布、轨道 ID 未共享、会话 ID 不匹配、未设置pc.ontrack、未重协商检查发布/订阅两侧 ID 一致性ICE 连接失败网络变化、防火墙封 UDP、需要 TURN、瞬时网络抖动触发 ICE restart 并携带iceRestart标志重新协商轨道卡住/冻结发送方暂停轨道、网络拥塞、编解码不匹配、移动端被后台化检查track.enabled与getStats丢包/抖动网络切换断线移动端 WiFi↔蜂窝切换、笔记本更换网络监听navigator.connection并 restartIce或直接用 PartyTracks下面逐类展开成因与可落地的解决方案。二、慢初始连接~1.8s属正常现象勿当 bug 处理成因在 ICE 共识形成consensus forming阶段首个 STUN 绑定请求存在一次固有延迟这是协议协商的正常行为并非配置错误。解决方案后续连接会明显更快不要基于首次连接耗时做性能结论Cloudflare 边缘会提前检测 DTLS ClientHello 以补偿该延迟即首包握手路径已被平台层优化生产环境建议复用已建立的会话避免为每次通话重建 PeerConnection。结合 patterns.md 中的性能数据平台典型的连接耗时约 100–250ms、95 分位延迟约 50ms、端到端玻璃到玻璃延迟约 200–400ms首次连接的 1.8s 不应作为持续性的性能基准。三、无媒体流No Media Flow按 5 步链路排查成因SDP 交换不完整、连接未建立、轨道在创建 offer 之前未添加、浏览器音视频权限缺失任一环节断裂都会导致对端无媒体。解决方案逐项验证验证 SDP 交换完整发布端offer与订阅端answer都必须成功送达可通过后端日志确认/renegotiate请求的往返检查连接状态确认pc.connectionState connected未连接则媒体不可能流动确保在创建 offer 前已添加轨道pc.addTrack(track, stream)必须在createOffer()之前执行否则 SDP 中不会包含媒体描述m-line确认浏览器权限已授予getUserMedia的video/audio权限被拒绝时轨道永远处于muted/ended状态使用chrome://webrtc-internals调试详见本文第七节。这与 api.md 中给出的标准 WebRTC 流程一致new RTCPeerConnection → getUserMedia → addTrack → createOffer → setLocalDescription → 发给后端 → setRemoteDescription任何一步顺序错位都会复现本故障。四、轨道收不到数据Track Not ReceivingID 与会话一致性是关键成因轨道未成功发布、轨道 ID 没有在两端共享、会话 ID 不匹配、pc.ontrack未设置、需要触发重协商。解决方案验证轨道发布成功发布接口返回的tracks[0].trackName才是可共享的发布轨道 ID见 api.md 的 Publishing 流程确认轨道 ID 已在两端共享发布者通过后端把trackName广播给订阅者检查会话 ID 匹配订阅时{location: remote, trackName: remoteTrackId, sessionId: remoteSessionId}中的sessionId必须是发布者的会话 ID在 answer 前设置pc.ontrack订阅者务必在createAnswer()之前注册pc.ontrack回调否则远端媒体流事件会丢失必要时触发重协商若轨道在连接建立后才加入需要通过PUT /sessions/{sessionId}/renegotiate完成一次新的 SDP 往返。从源码结构看TrackMetadata类型trackName/location: local | remote/sessionId?/mid?明确区分了本地与远端轨道订阅侧的sessionId字段正是跨会话订阅的寻址依据。五、ICE 连接失败用restartIce()恢复连接成因网络环境变化、防火墙阻断 UDP、需要 TURN 中继、瞬时网络抖动。原文档给出了一段可直接落地的 ICE 重启代码pc.oniceconnectionstatechange async () { if (pc.iceConnectionState failed) { console.warn(ICE failed, attempting restart); await pc.restartIce(); // Triggers new ICE gathering // Create new offer with ICE restart flag const offer await pc.createOffer({iceRestart: true}); await pc.setLocalDescription(offer); // Send to backend → Cloudflare API await fetch(/api/sessions/${sessionId}/renegotiate, { method: PUT, body: JSON.stringify({sdp: offer.sdp}) }); } };要点解读restartIce()会重新触发 ICE 收集随后必须以iceRestart: true重新createOffer并走renegotiate端点把新 SDP 回传给 Cloudflarerenegotiate端点对应 api.md 中的PUT /v1/apps/{appId}/sessions/{sessionId}/renegotiate请求体为{sessionDescription: {sdp, type: answer}}若失败源于防火墙封禁 UDP则需引入 TURNICE 服务器配置可参考 realtime-sfu/configuration.md 中的iceServers清单stun:stun.cloudflare.com:3478与turn:turn.cloudflare.com系列TURN 服务随 SFU 免费包含。相关端口为 3478UDP/TCP、53UDP、80TCP、443TLS、5349TLS生产环境建议bundlePolicy: max-bundle仅测试时把iceTransportPolicy设为relay强制走 TURN。六、轨道卡住/冻结Track Stuck/Frozen成因发送方暂停了轨道、网络拥塞、编解码不匹配、移动端浏览器被后台化后台会冻结媒体采集。解决方案检查track.enabled以及track.readyState live验证发送器仍附着轨道pc.getSenders().find(s s.track track)通过getStats()检查丢包率与抖动参考 patterns.md 的连接质量监控inbound-rtp报告中的packetsLost/packetsReceived/jitter丢包率 5% 或抖动 100ms 即告警移动端在应用回到前台时重新获取轨道getUserMedia重建 MediaStream若问题持续改用不同编解码器验证是否为编解码协商问题。七、网络切换导致断线监听连接事件或直接使用 PartyTracks移动端在 WiFi↔蜂窝、笔记本在多个网络间切换时ICE 候选失效会导致会话中断。原文档给出两种处理方式// Listen for network changes if (connection in navigator) { (navigator as any).connection.addEventListener(change, async () { console.log(Network changed); await pc.restartIce(); // Use ICE restart pattern above }); } // Or use PartyTracks (handles automatically)更省心的选择是 PartyTracks从 patterns.md 可以看到PartyTracks 是基于 Observable 的官方推荐客户端库会自动处理设备切换如蓝牙耳机、网络切换与 ICE 重启且提供 React hooksuseObservableAsValue读取pt.localTracks$/pt.remoteTracks$。如果不想手工维护 WebRTC 生命周期建议优先采用 PartyTracks 而非裸写上述逻辑。八、重试机制带指数退避的fetchWithRetry在信令链路后端 → Cloudflare API偶发 5xx 时采用指数退避重试是标准做法。原文档提供的实现如下async function fetchWithRetry(url: string, options: RequestInit, maxRetries 3) { for (let i 0; i maxRetries; i) { try { const res await fetch(url, options); if (res.ok) return res; if (res.status 500) throw new Error(Server error); return res; // Client error, dont retry } catch (err) { if (i maxRetries - 1) throw err; const delay Math.min(1000 * 2 ** i, 10000); // Cap at 10s await new Promise(resolve setTimeout(resolve, delay)); } } }要点解读仅对 5xx 服务端错误重试4xx 客户端错误直接返回避免放大无效请求退避延迟为1000 * 2^i毫秒1s → 2s → 4s …上限 10 秒防止长时间阻塞建议在会话创建、发布/订阅轨道等关键信令调用上统一套用该工具函数配合第 11 节限额表中600 req/min的 API 速率限制可显著降低生产环境偶发失败率。九、chrome://webrtc-internals调试指南当上述逻辑排查无效时浏览器内置的 WebRTC 调试面板能提供链路级证据。按以下步骤操作在 Chrome/Edge 中打开chrome://webrtc-internals在列表中找到你的 PeerConnection查看Stats graphs丢包packet loss、抖动jitter、带宽bandwidth曲线查看ICE candidate pairs关注succeeded状态以及候选类型是 relay 还是 host——若全部是 relay 说明走了 TURN查看getStatsinbound/outbound RTP 的原始指标在Event log中寻找错误重点看iceConnectionState、connectionState的变化序列使用 Download the PeerConnection updates and stats data 按钮导出完整数据便于离线分析或提交工单该面板最常见的可见问题ICE 失败、高丢包、码率骤降。十、资源与限额速查表原文档给出了 SFU 平台的硬性/软性限额这是架构设计与容量评估的直接依据资源/限额数值说明Egress免费套餐1TB/月按账号计Egress付费套餐$0.05/GB超出免费额度后计费入站流量免费所有套餐TURN 服务免费随 SFU 附带参与者数量无硬性上限受客户端带宽/CPU 限制典型 10–50 条轨道每会话轨道数无硬性上限受客户端资源限制会话时长无硬性上限生产通话可连续运行数小时WebRTC 端口UDP 1024–65535仅出站媒体传输必需API 速率限制600 req/min按应用计允许突发设计启示无硬性上限并不意味着可以无限制并发订阅——单客户端的解码能力才是瓶颈。正因如此patterns.md 中的 Stage Management 模式只订阅活跃发言的前 6 路才显得必要通过topSpeakers列表动态增删订阅避免客户端同时拉取过多轨道。十一、安全清单上线前逐项核对原文档的安全清单是 SFU 应用上线前必须逐项打勾的检查项✅绝不将CALLS_APP_SECRET暴露给客户端——该密钥用于信令鉴权Authorization: Bearer必须仅存于后端/Workers 环境变量通过wrangler secret put CALLS_APP_SECRET注入参见 configuration.md✅在后端创建会话前校验用户身份——不要在客户端直接调用sessions/new✅为会话访问实现鉴权令牌JWT 置于自定义请求头——平台本身没有房间/成员概念会话与轨道访问权必须由你的后端把控✅对会话创建端点做速率限制——避免被滥用打爆 600 req/min 限额✅服务端对不活跃会话设置过期——防止孤儿会话长期占用资源✅订阅前校验轨道 ID——防止未授权访问他人发布的轨道✅所有信令API 调用走 HTTPS✅启用 DTLS-SRTP——Cloudflare 侧自动开启媒体流默认加密⚠️敏感内容考虑端到端加密E2EE——需客户端配合 Insertable Streams API 自行实现平台不代做。其中验证用户身份 JWT 限流的组合与 patterns.md 的后端示例一脉相承Express/Workers 后端代理sessions/new等调用凭据只出现在服务端请求头中。十二、关联文档导航本文围绕故障排查主题展开其余维度的参考资料如下均位于仓库skills/.curated/cloudflare-deploy/references/realtime-sfu/目录README.md核心概念Sessions/Tracks、阅读顺序与 PartyTracks/Raw API/RealtimeKit 选型configuration.mdDashboard 凭据、Wrangler 配置、TURN 配置与 Durable Object 房间样板api.md会话/轨道/重协商等全部 HTTP 端点与 TypeScript 类型patterns.md架构图、1:1/N:N/1:N/Breakout 用例、PartyTracks 示例、音浪检测与带宽管理。排查实时音视频问题时建议按先看连接状态 → 再查 SDP 交换 → 后看 ICE/Stats的顺序配合本文的六类错误对照表逐项定位即可覆盖绝大多数生产故障场景。【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cloudflare Realtime SFU 故障排查与调优实战指南（Gotchas Troubleshooting）
Cloudflare Realtime SFU 故障排查与调优实战指南Gotchas Troubleshooting【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills本指南以 Cloudflare Realtime SFUSelective Forwarding Unit的故障排查文档为核心系统梳理从首连慢无媒体流到ICE 失败网络切换断线等高频问题的成因与解决方案并给出可复制的 ICE 重启、指数退避重试等 TypeScript 代码。读完本文你将掌握基于 WebRTC 会话Session与轨道Track模型构建实时音视频应用时的完整排障方法论、chrome://webrtc-internals调试技能以及 SFU 平台的资源限额与安全基线可直接用于生产环境的联调与上线前检查。一、故障排查全景六个高频问题速览Cloudflare Realtime SFU 的核心心智模型是客户端与 Cloudflare 边缘建立一个 WebRTC 会话Session发布本地轨道Track音频/视频/数据通道通过后端共享轨道 ID其他客户端用轨道 ID 会话 ID订阅远端轨道详见 realtime-sfu/README.md。当链路出现问题时问题往往集中在 SDP 协商、ICE 打洞、轨道发布/订阅状态这三个层面。原文档gotchas.md给出了六类最常遇到的错误症状核心成因关键动作慢初始连接~1.8s共识形成阶段首个 STUN 被延迟等待后续连接靠 CF 提前探测 DTLS ClientHello 补偿无媒体流SDP 交换不完整、连接未建立、offer 前未添加轨道、浏览器权限缺失按 5 步链路逐项核对轨道收不到数据轨道未发布、轨道 ID 未共享、会话 ID 不匹配、未设置pc.ontrack、未重协商检查发布/订阅两侧 ID 一致性ICE 连接失败网络变化、防火墙封 UDP、需要 TURN、瞬时网络抖动触发 ICE restart 并携带iceRestart标志重新协商轨道卡住/冻结发送方暂停轨道、网络拥塞、编解码不匹配、移动端被后台化检查track.enabled与getStats丢包/抖动网络切换断线移动端 WiFi↔蜂窝切换、笔记本更换网络监听navigator.connection并 restartIce或直接用 PartyTracks下面逐类展开成因与可落地的解决方案。二、慢初始连接~1.8s属正常现象勿当 bug 处理成因在 ICE 共识形成consensus forming阶段首个 STUN 绑定请求存在一次固有延迟这是协议协商的正常行为并非配置错误。解决方案后续连接会明显更快不要基于首次连接耗时做性能结论Cloudflare 边缘会提前检测 DTLS ClientHello 以补偿该延迟即首包握手路径已被平台层优化生产环境建议复用已建立的会话避免为每次通话重建 PeerConnection。结合 patterns.md 中的性能数据平台典型的连接耗时约 100–250ms、95 分位延迟约 50ms、端到端玻璃到玻璃延迟约 200–400ms首次连接的 1.8s 不应作为持续性的性能基准。三、无媒体流No Media Flow按 5 步链路排查成因SDP 交换不完整、连接未建立、轨道在创建 offer 之前未添加、浏览器音视频权限缺失任一环节断裂都会导致对端无媒体。解决方案逐项验证验证 SDP 交换完整发布端offer与订阅端answer都必须成功送达可通过后端日志确认/renegotiate请求的往返检查连接状态确认pc.connectionState connected未连接则媒体不可能流动确保在创建 offer 前已添加轨道pc.addTrack(track, stream)必须在createOffer()之前执行否则 SDP 中不会包含媒体描述m-line确认浏览器权限已授予getUserMedia的video/audio权限被拒绝时轨道永远处于muted/ended状态使用chrome://webrtc-internals调试详见本文第七节。这与 api.md 中给出的标准 WebRTC 流程一致new RTCPeerConnection → getUserMedia → addTrack → createOffer → setLocalDescription → 发给后端 → setRemoteDescription任何一步顺序错位都会复现本故障。四、轨道收不到数据Track Not ReceivingID 与会话一致性是关键成因轨道未成功发布、轨道 ID 没有在两端共享、会话 ID 不匹配、pc.ontrack未设置、需要触发重协商。解决方案验证轨道发布成功发布接口返回的tracks[0].trackName才是可共享的发布轨道 ID见 api.md 的 Publishing 流程确认轨道 ID 已在两端共享发布者通过后端把trackName广播给订阅者检查会话 ID 匹配订阅时{location: remote, trackName: remoteTrackId, sessionId: remoteSessionId}中的sessionId必须是发布者的会话 ID在 answer 前设置pc.ontrack订阅者务必在createAnswer()之前注册pc.ontrack回调否则远端媒体流事件会丢失必要时触发重协商若轨道在连接建立后才加入需要通过PUT /sessions/{sessionId}/renegotiate完成一次新的 SDP 往返。从源码结构看TrackMetadata类型trackName/location: local | remote/sessionId?/mid?明确区分了本地与远端轨道订阅侧的sessionId字段正是跨会话订阅的寻址依据。五、ICE 连接失败用restartIce()恢复连接成因网络环境变化、防火墙阻断 UDP、需要 TURN 中继、瞬时网络抖动。原文档给出了一段可直接落地的 ICE 重启代码pc.oniceconnectionstatechange async () { if (pc.iceConnectionState failed) { console.warn(ICE failed, attempting restart); await pc.restartIce(); // Triggers new ICE gathering // Create new offer with ICE restart flag const offer await pc.createOffer({iceRestart: true}); await pc.setLocalDescription(offer); // Send to backend → Cloudflare API await fetch(/api/sessions/${sessionId}/renegotiate, { method: PUT, body: JSON.stringify({sdp: offer.sdp}) }); } };要点解读restartIce()会重新触发 ICE 收集随后必须以iceRestart: true重新createOffer并走renegotiate端点把新 SDP 回传给 Cloudflarerenegotiate端点对应 api.md 中的PUT /v1/apps/{appId}/sessions/{sessionId}/renegotiate请求体为{sessionDescription: {sdp, type: answer}}若失败源于防火墙封禁 UDP则需引入 TURNICE 服务器配置可参考 realtime-sfu/configuration.md 中的iceServers清单stun:stun.cloudflare.com:3478与turn:turn.cloudflare.com系列TURN 服务随 SFU 免费包含。相关端口为 3478UDP/TCP、53UDP、80TCP、443TLS、5349TLS生产环境建议bundlePolicy: max-bundle仅测试时把iceTransportPolicy设为relay强制走 TURN。六、轨道卡住/冻结Track Stuck/Frozen成因发送方暂停了轨道、网络拥塞、编解码不匹配、移动端浏览器被后台化后台会冻结媒体采集。解决方案检查track.enabled以及track.readyState live验证发送器仍附着轨道pc.getSenders().find(s s.track track)通过getStats()检查丢包率与抖动参考 patterns.md 的连接质量监控inbound-rtp报告中的packetsLost/packetsReceived/jitter丢包率 5% 或抖动 100ms 即告警移动端在应用回到前台时重新获取轨道getUserMedia重建 MediaStream若问题持续改用不同编解码器验证是否为编解码协商问题。七、网络切换导致断线监听连接事件或直接使用 PartyTracks移动端在 WiFi↔蜂窝、笔记本在多个网络间切换时ICE 候选失效会导致会话中断。原文档给出两种处理方式// Listen for network changes if (connection in navigator) { (navigator as any).connection.addEventListener(change, async () { console.log(Network changed); await pc.restartIce(); // Use ICE restart pattern above }); } // Or use PartyTracks (handles automatically)更省心的选择是 PartyTracks从 patterns.md 可以看到PartyTracks 是基于 Observable 的官方推荐客户端库会自动处理设备切换如蓝牙耳机、网络切换与 ICE 重启且提供 React hooksuseObservableAsValue读取pt.localTracks$/pt.remoteTracks$。如果不想手工维护 WebRTC 生命周期建议优先采用 PartyTracks 而非裸写上述逻辑。八、重试机制带指数退避的fetchWithRetry在信令链路后端 → Cloudflare API偶发 5xx 时采用指数退避重试是标准做法。原文档提供的实现如下async function fetchWithRetry(url: string, options: RequestInit, maxRetries 3) { for (let i 0; i maxRetries; i) { try { const res await fetch(url, options); if (res.ok) return res; if (res.status 500) throw new Error(Server error); return res; // Client error, dont retry } catch (err) { if (i maxRetries - 1) throw err; const delay Math.min(1000 * 2 ** i, 10000); // Cap at 10s await new Promise(resolve setTimeout(resolve, delay)); } } }要点解读仅对 5xx 服务端错误重试4xx 客户端错误直接返回避免放大无效请求退避延迟为1000 * 2^i毫秒1s → 2s → 4s …上限 10 秒防止长时间阻塞建议在会话创建、发布/订阅轨道等关键信令调用上统一套用该工具函数配合第 11 节限额表中600 req/min的 API 速率限制可显著降低生产环境偶发失败率。九、chrome://webrtc-internals调试指南当上述逻辑排查无效时浏览器内置的 WebRTC 调试面板能提供链路级证据。按以下步骤操作在 Chrome/Edge 中打开chrome://webrtc-internals在列表中找到你的 PeerConnection查看Stats graphs丢包packet loss、抖动jitter、带宽bandwidth曲线查看ICE candidate pairs关注succeeded状态以及候选类型是 relay 还是 host——若全部是 relay 说明走了 TURN查看getStatsinbound/outbound RTP 的原始指标在Event log中寻找错误重点看iceConnectionState、connectionState的变化序列使用 Download the PeerConnection updates and stats data 按钮导出完整数据便于离线分析或提交工单该面板最常见的可见问题ICE 失败、高丢包、码率骤降。十、资源与限额速查表原文档给出了 SFU 平台的硬性/软性限额这是架构设计与容量评估的直接依据资源/限额数值说明Egress免费套餐1TB/月按账号计Egress付费套餐$0.05/GB超出免费额度后计费入站流量免费所有套餐TURN 服务免费随 SFU 附带参与者数量无硬性上限受客户端带宽/CPU 限制典型 10–50 条轨道每会话轨道数无硬性上限受客户端资源限制会话时长无硬性上限生产通话可连续运行数小时WebRTC 端口UDP 1024–65535仅出站媒体传输必需API 速率限制600 req/min按应用计允许突发设计启示无硬性上限并不意味着可以无限制并发订阅——单客户端的解码能力才是瓶颈。正因如此patterns.md 中的 Stage Management 模式只订阅活跃发言的前 6 路才显得必要通过topSpeakers列表动态增删订阅避免客户端同时拉取过多轨道。十一、安全清单上线前逐项核对原文档的安全清单是 SFU 应用上线前必须逐项打勾的检查项✅绝不将CALLS_APP_SECRET暴露给客户端——该密钥用于信令鉴权Authorization: Bearer必须仅存于后端/Workers 环境变量通过wrangler secret put CALLS_APP_SECRET注入参见 configuration.md✅在后端创建会话前校验用户身份——不要在客户端直接调用sessions/new✅为会话访问实现鉴权令牌JWT 置于自定义请求头——平台本身没有房间/成员概念会话与轨道访问权必须由你的后端把控✅对会话创建端点做速率限制——避免被滥用打爆 600 req/min 限额✅服务端对不活跃会话设置过期——防止孤儿会话长期占用资源✅订阅前校验轨道 ID——防止未授权访问他人发布的轨道✅所有信令API 调用走 HTTPS✅启用 DTLS-SRTP——Cloudflare 侧自动开启媒体流默认加密⚠️敏感内容考虑端到端加密E2EE——需客户端配合 Insertable Streams API 自行实现平台不代做。其中验证用户身份 JWT 限流的组合与 patterns.md 的后端示例一脉相承Express/Workers 后端代理sessions/new等调用凭据只出现在服务端请求头中。十二、关联文档导航本文围绕故障排查主题展开其余维度的参考资料如下均位于仓库skills/.curated/cloudflare-deploy/references/realtime-sfu/目录README.md核心概念Sessions/Tracks、阅读顺序与 PartyTracks/Raw API/RealtimeKit 选型configuration.mdDashboard 凭据、Wrangler 配置、TURN 配置与 Durable Object 房间样板api.md会话/轨道/重协商等全部 HTTP 端点与 TypeScript 类型patterns.md架构图、1:1/N:N/1:N/Breakout 用例、PartyTracks 示例、音浪检测与带宽管理。排查实时音视频问题时建议按先看连接状态 → 再查 SDP 交换 → 后看 ICE/Stats的顺序配合本文的六类错误对照表逐项定位即可覆盖绝大多数生产故障场景。【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考