SD-WAN 视频会议卡顿怎么办？按 7 步定位问题
简答：SD-WAN 视频会议卡顿，最快不要先改线路，而是先判断是终端、Wi-Fi、隧道质量、实际选路还是会议平台流量被防火墙或 VPN 影响。按“症状记录→连续探测→查看 SD-WAN 路径→核对 QoS 与 UDP→修复后复测”的 7 步顺序，通常能把问题定位到具体层级。
定义：SD-WAN 视频会议卡顿，是指会议中的音频断续、画面马赛克、延迟升高、音视频不同步或中途掉线等实时通信质量问题。
先试这一步：用症状和指标确定排查方向
会议已经开始卡顿时，先记录发生时间、受影响人数、使用的网络接入方式、是否刚发生链路切换，以及是音频、视频还是两者同时异常。不要只记录“网络不好”，因为不同表现对应的排查层级不同。
| 现象 | 优先检查 | 先做的验证 |
|---|---|---|
| 只有一名员工卡顿 | 终端、Wi-Fi、网卡、后台上传 | 改用有线网络或手机热点短测，关闭同步、上传和下载任务 |
| 同一办公室多人同时卡顿 | 接入交换机、出口带宽、无线信道或局域网拥塞 | 对比有线与 Wi-Fi，并查看出口利用率和同一时间段的链路指标 |
| 音频断续、画面基本正常 | 上行丢包、抖动、UDP 不通或 QoS 未生效 | 查看实时媒体流的丢包、抖动、协议和实际路径 |
| 画面马赛克或频繁降清晰度 | 下行带宽、丢包、拥塞或路径切换 | 对比会议期间下行利用率与 SD-WAN 路径质量 |
| 切换链路后恢复 | 原链路质量或策略阈值 | 查看 SD-WAN 事件、切换前后的延迟、抖动和丢包 |
| 所有人中途掉线 | 防火墙、代理、VPN、WebSocket 或会议服务连接 | 核对 UDP、WSS、TLS 检查和代理空闲超时设置 |
SD-WAN 的路径质量通常至少要观察延迟、抖动和丢包；部分 SD-WAN 产品会使用这些指标参与应用选路，但具体阈值属于厂商和企业策略设置，不能把某一个厂商的默认值当成统一标准。可参考 Palo Alto Networks 对 SD-WAN 路径健康与动态选路的说明。
7 步排查流程：每一步都要有结果和回退
- 记录会议症状。
记下会议平台、客户端设备、连接方式、有线或 Wi-Fi、发生时间、是否多人同时异常，以及音频和视频哪个先出问题。若只影响单台设备，先不要修改整个 SD-WAN 策略；先把该设备移到有线网络或经过批准的备用网络短测。若备用网络恢复，回退路径就是保留原配置，继续检查接入网络和终端。
- 检查终端和局域网。
Windows 可在命令提示符执行
ping -n 100 192.168.1.1；macOS 可执行ping -c 100 192.168.1.1。这里的地址应替换为本地默认网关或企业批准的局域网探测地址。预期结果是延迟变化较小、没有明显超时；如果本地网关就出现超时或剧烈波动，优先检查 Wi-Fi 信号、无线信道、网卡驱动、网线和接入交换机，而不是先调整公网选路。腾讯会议帮助中心也将网卡、后台占用、上行连接质量和网络拥塞列为声音卡顿的常见方向，并建议检查 Wi-Fi 或移动网络信号。 - 做公网连续探测，但不要把它当成会议质量结论。
Windows 可执行
pathping -n 1.1.1.1；macOS 可执行traceroute 1.1.1.1。目标地址应替换为企业批准的稳定探测目标。公网探测只能帮助判断本地出口或某条链路是否在同一时间异常，不能直接代表会议媒体服务器的质量；应将结果与会议平台诊断数据和 SD-WAN 监控放在同一时间窗口比较。 - 查看 SD-WAN 隧道、路径和切换事件。
在 SD-WAN 管理面查看受影响分支、站点或用户的隧道状态，重点记录会议发生时的延迟、抖动、丢包、链路利用率、实际出接口和路径切换事件。Palo Alto Networks 的排障文档明确建议查看 SD-WAN 事件、路径选择以及虚拟 SD-WAN 接口上的延迟、抖动和丢包；如果监控界面显示路径切换，应进一步确认切换前后的指标，而不是只看当前链路状态。若当前链路恢复正常，先保留证据再回退到原策略，避免复测时丢失现场信息。
- 确认会议流量被正确识别并获得优先级。
检查应用识别、业务分类、实时音视频队列、上行和下行方向的 QoS，以及是否存在大文件同步、云盘上传、系统更新或备份任务抢占带宽。业务优先级不是简单地“给会议无限带宽”，而是确认分类命中、队列没有丢包、策略没有被更高优先级或错误的默认规则覆盖。修改前导出当前策略；若修改后会议质量没有改善，应恢复原策略，并比较同一会议时段的数据。
- 排查 VPN、代理、防火墙和 UDP。
会议平台通常需要信令连接和媒体连接。以 Twilio Video 的官方网络说明为例，其媒体连接优先使用 UDP，若只能回退到 TCP/TLS 443，可能增加延迟；TLS 检查、DPI、SIP ALG、代理和 VPN 也可能干扰实时媒体。该页面还建议对实时媒体流量配置合适的防火墙放行、避免不必要的检查，并在使用 VPN 时评估分流。实际端口、域名和地址范围必须以所用会议平台的当前官方文档为准，不能把 Twilio 的配置直接套用到 Teams、Zoom 或其他平台。
- 修复后用同一场景复测。
复测至少包含一次相同会议平台、相同办公地点、相同接入方式和相近参会人数的会议。记录修复前后四类结果：本地网关丢包、公网或企业探测结果、SD-WAN 实际路径与路径质量、会议平台的音视频体验。Microsoft Teams 的官方质量管理文档建议使用 CQD 按网络、VPN、Wi-Fi、有线网络、设备和客户端版本分析，并提醒 CQD 可以指出需要调查的区域，但不一定直接给出单次故障的根因。若只在单个终端复现，应继续按设备和客户端分组；若同一网段多人复现，应优先升级网络或 SD-WAN 侧处理。
按平台和症状分流：什么时候改网络，什么时候改客户端
只有音频卡顿，视频还能看
优先检查上行丢包、抖动、麦克风设备、后台上传和 UDP 媒体路径。可以临时关闭摄像头和屏幕共享来保障语音，但这只是应急回退，不代表网络问题已经解决。腾讯会议官方帮助建议在网络条件较差时切换到质量更好的网络，必要时关闭视频和屏幕共享优先保障语音。
画面马赛克、延迟高或音视频不同步
同时查看下行利用率、丢包和链路切换。若 SD-WAN 监控显示路径质量恶化，应检查路径质量策略是否命中、备用链路是否真的可用，以及切换后是否出现更高延迟。不要只按照“延迟低就一定最好”判断，实时会议还要结合抖动、丢包、带宽余量和路径稳定性。
只有使用 VPN 或公司代理时卡顿
对比 VPN 开启和关闭时的会议诊断结果，检查实时媒体是否被强制送入远端 VPN、代理是否支持所需协议、TLS 检查或 DPI 是否作用于媒体流。Teams 官方文档将 VPN、代理、防火墙、带宽、Wi-Fi 和客户端版本列为需要持续监控的质量因素；因此应将这些维度纳入同一份故障记录，而不是只测试一次速度。
会议能接通，但中途掉线
检查信令连接的 WebSocket 或 HTTPS 连接、代理空闲超时、链路切换时会话是否重建，以及防火墙是否允许返回流量。具体配置应以会议平台的官方网络要求为准。以 Twilio Video 为例，官方文档指出较短的 WebSocket 空闲超时可能导致通话中途断开，并给出了针对信令、媒体、代理和检查策略的排查方向。
验证标准：怎样判断问题真正解决
一次“感觉好一些”的会议不足以证明问题已解决，建议用以下清单验收：
- 同一地点、同一终端和同一会议平台连续复测，卡顿发生时间不再与某条链路切换或某个队列丢包同时出现。
- 本地网关探测没有异常时，SD-WAN 隧道和实际会议路径也没有明显丢包、抖动或频繁切换。
- QoS 统计能够证明会议流量被正确分类，且上行和下行队列没有持续丢弃。
- 关闭 VPN、代理或 TLS 检查后，会议质量变化能够被诊断数据记录，而不是只凭主观感受。
- 单台设备问题要通过更换有线网络、耳机或客户端版本复测；多人同网段问题要通过其他终端或其他接入点复测。
- 修复前已保存 SD-WAN 策略、路径事件和会议诊断结果，修复失败时可以回退。
如果企业使用 Teams，可在 CQD 中按楼宇、子网、VPN、Wi-Fi、有线网络、设备和客户端版本聚合观察；如果使用其他平台，应优先使用该平台提供的会中诊断、网络测试或管理员质量报表。平台报表用于定位趋势，不能单独替代 SD-WAN 的路径和链路证据。
什么时候需要联系运营商或 SD-WAN 厂商
出现以下情况时，建议将证据包交给运营商或 SD-WAN 厂商，而不是继续盲目调高 QoS：
- 本地网关稳定，但某条 WAN 链路在多个时间段持续出现丢包、抖动或异常延迟。
- 多个站点或多个用户在同一时间出现相同故障，且实际选路都经过同一出口、隧道或运营商路径。
- 策略显示应切换到备用链路，但实际会议流量仍停留在故障链路，或切换后会话频繁重建。
- 会议平台诊断显示 UDP、媒体或信令路径不可用，而防火墙日志显示被代理、DPI、TLS 检查或应用识别规则处理。
提交信息时包含故障时间、站点、用户数量、会议平台、接入方式、SD-WAN 路径事件、延迟/抖动/丢包记录、QoS 命中情况和防火墙日志摘要。不要在工单中直接上传会议账号、令牌或完整敏感配置。
相关指南
如果你还需要从基础概念或指标入手，可以继续阅读站内的 SD-WAN 延迟高怎么办、SD-WAN 抖动怎么测试、SD-WAN 丢包率怎么判断 和 SD-WAN 网络故障排查。这些页面适合把本篇会议现场的现象进一步拆成延迟、抖动、丢包和整体故障流程。
常见问题
SD-WAN 视频会议卡顿，应该先换线路吗？
不建议一开始就换线路。先记录症状并检查本地网关、终端和 Wi-Fi；确认 SD-WAN 监控中的延迟、抖动、丢包和实际路径后，再判断是否需要切换线路。若切换后恢复，应保留切换事件和前后指标，避免只凭体感下结论。
视频会议卡顿主要看延迟还是丢包？
不能只看一个指标。延迟影响交互反应，抖动会造成媒体到达时间不稳定，丢包会造成音频断续、画面马赛克或重传；还要结合带宽利用率、VPN、代理和实际会议路径。不同平台和 SD-WAN 厂商的阈值不同，应以当前策略和平台诊断为准。
关闭摄像头后声音恢复，说明 SD-WAN 一定有问题吗？
不一定。这可能说明上行带宽、无线质量、队列拥塞或终端编码负载不足，但也可能是会议平台在网络受限时优先保障音频。应同时检查设备资源、上行利用率、QoS 命中、丢包和抖动，再决定是否修改 SD-WAN 策略。
VPN 会导致视频会议卡顿吗？
VPN 可能增加路径长度、隧道处理和带宽占用，但是否构成根因要用对比测试确认。比较 VPN 开启和关闭时的会议诊断、实际路径、协议和丢包情况；涉及企业安全策略时，不要自行关闭 VPN，应让网络管理员评估分流或其他合规方案。
什么时候应该联系运营商？
当本地网关和终端基本正常，但同一 WAN 链路在多个时段持续出现丢包、抖动或异常延迟，或者多个站点经过同一路径同时异常，就应提交带时间戳的链路监控、SD-WAN 事件和会议诊断记录给运营商或 SD-WAN 厂商。