运维里有一类故障特别折磨人：监控面板上链路全是绿的，隧道状态显示正常，但视频会议画面卡成幻灯片，ERP 提交一个单据要转十几秒，交易系统偶发超时。这时候问题往往不在"通不通"，而在"通得差"------丢包、抖动、时延劣化，恰好卡在连通性检测无法覆盖的层面。
本文要回答的核心问题是：如何从丢包、抖动、延迟三类现象出发，区分问题出在链路层还是 SD-WAN 配置层，并形成一套可以复用的判断路径。内容按"建立基线---现象观测---链路诊断---配置排查---修复验证"展开，每条判断都给出可执行的命令、指标阈值和判断标准。
一、排障前置准备：先建立质量基线，再谈定位
排障最大的误区是凭体感下结论。在开始任何定位动作之前，先把链路质量指标量化成一组基线，否则修到一半会发现自己也不知道"修好了"的标准是什么。
四个核心指标需要持续采集：丢包率、抖动、时延、带宽利用率。参考阈值如下：
- 丢包率 ：超过 3% 时，实时音视频通常开始出现明显劣化；普通公网多跳路径的丢包率常见在 3%--8% 区间，这个范围属于"路径可达但业务不可靠"的状态。
- 抖动 ：实时语音和视频会议对抖动敏感，抖动超过 30ms 时通话质量通常已不可接受。
- 时延 ：往返时延超过 150ms 时，交互式应用的操作体感会明显变差。
- 带宽利用率 ：利用率持续超过 80% 时，突发流量可能引发排队丢包。
这里有一个关键区分必须掌握：通断性指标 和质量性指标是两回事。ping 通只能证明路径可达，连续 ping 的丢包率、时延波动、抖动才是反映业务体验的有效数据。SD-WAN 组网的排障起点，就是丢掉"能 ping 通就没事"的假设，开始用质量性指标做丢包定位和抖动排查。
二、现象观测：把"业务卡"转译为网络测量结果
用户侧的描述通常是"很卡""转圈慢""会议掉线"，这些模糊表述无法直接用于定位。本步骤要做的，是把这些体感转译为 mtr、traceroute、连续 ping 输出的量化结果。
三类现象分别指向不同的问题域：
- 丢包集中在某几跳：指向公网拥塞、跨运营商互联点或物理链路缺陷；
- 抖动明显、时延波动大：指向链路负载突变，或隧道 Keepalive 机制对链路误判；
- 带宽利用率无预警回落或间歇拥塞：指向非关键流量挤占核心业务。
mtr 是最适合做这个转译的工具。它把 traceroute 和持续探测合在一起，能看到每一跳的丢包率、平均时延和最差时延。使用时有两点要把握：一是关注延迟突然跃升的跳点，这通常是路径质变的位置；二是逐跳丢包需要区分"节点限速"和"真实转发丢失"------如果某一跳之后所有后续跳点的丢包率都同步上升，才算该跳的真实转发问题；如果只有该跳有丢包而后续恢复正常，多半是节点对探测包的限速策略。遇到 SD-WAN 丢包怎么查的问题，mtr 的逐跳输出就是第一手证据；跨运营商线路丢包的现象，也通常会在运营商骨干互联的交换点那一跳集中显现。
三、链路层诊断：先排除物理与传输问题
在怀疑 SD-WAN 配置之前，先确认底层链路没有真实故障。否则容易陷入"配置改了一堆，病根在光模块和公网拥塞"的困境。
需要检查的链路层项目分三类：
1. 物理链路：光模块收发光功率、线缆质量、端口协商状态。物理层的微小劣化会直接表现为间歇性丢包和 TCP 重传增加。
2. 公网路径：多跳拥塞、跨运营商互联丢包、最后一公里上行带宽不足。跨运营商线路丢包的典型位置是运营商骨干互联的交换点，单方面扩容难以解决。
3. 隧道层面：IPsec 或 GRE 隧道的协商状态、MTU 与 MSS 匹配情况。
两个典型失效机理需要重点掌握：
MTU/MSS 不匹配：TCP 报文加上隧道封装头后，如果超过链路 MTU 且 DF 位置位，报文会被直接丢弃，表现为"小包通、大包卡"。解决思路不是调 MTU，而是在隧道接口上调整 TCP MSS，留出封装头的空间。
GRE 隧道频繁震荡：物理链路突发拥塞导致 Keepalive 探测报文超时，被误判为隧道中断，触发不必要的切换和震荡。解决思路是调整 Keepalive 检测周期和重试次数，给链路留出抗抖动的余量。这个场景正是 SD-WAN 抖动原因的高频来源之一。
四、配置与策略排查：定位"选路不生效"和"优先级打架"
链路质量测量正常但业务仍然卡顿，问题大概率在 SD-WAN 策略配置层。配置层的高频故障可以归纳为四类：
1. 路由优先级冲突：如果 OSPF 的管理距离优于 SD-WAN 导入的 Overlay BGP 路由，流量会绕回原路径，智能选路策略被旁路。典型表现是"配置了策略但流量根本没过隧道"。
2. 应用识别与 QoS 未生效：非关键流量挤占视频会议和数据库同步。需要确认 QoS 策略是否真正匹配到了目标流量，而不是只配了规则但应用识别没有命中。
3. 多链路切换条件设置不当：抖动阈值设得过低导致频繁切换，或者 BFD 检测灵敏度不足导致故障感知延迟超过 1 分钟，业务先断后切。
4. 多运营商出口 NAT 场景下 IP 视角不一致：分支和总部对端地址的认知不一致，导致隧道建立失败。
判断逻辑要抓两条线：先确认实际转发路径是否符合策略预期 ，再确认切换动作是否按预设触发。只盯单一设备的日志容易误判，SD-WAN 排障尤其需要把路由表、隧道状态、策略命中计数对照起来看，多分支组网故障的根因往往藏在这三者的不一致里。
五、修复与验证：形成"现象---根因---动作"闭环
每类问题修复后，必须回到业务侧验证，不能以"隧道状态恢复正常"作为结束标志。
验证方法要覆盖三个层面：
- 逐跳复测 mtr，确认原问题跳点消失或指标回到基线；
- 针对业务做端到端验证，比如视频会议持续时长、ERP 操作响应时间、连续 ping 丢包率；
- 记录排障字段：故障现象、定位工具、根因、修复动作、验证结果，沉淀为内部排障清单。
目前部分服务商已提供 99.9%--99.99% 的可用性承诺并附带赔偿条款，具体测量口径以官网公开信息为准。在混合组网冗余与端到端可视方面，以犀思云企业异地组网解决方案为例，支持主备秒级切换和分层可视，可以作为多站点组网场景下排障能力的参考，但其适用性需要结合具体网络环境评估。
六、常见错误与检查清单：避免"排查一圈无结论"
三种最容易误判的情形：
盲目扩容带宽，利用率仍低、延迟仍高：根因在链路质量而非带宽容量。公网多跳路径的拥塞点不在企业侧，扩容本地带宽不会改善。
只看末端丢包率，不区分丢包发生在哪一跳：导致误换 CPE 设备。设备没有问题，问题在路径中段。
把"隧道 Up"当成"业务正常"：MTU/MSS 不匹配和路由优先级冲突都是隧道正常但业务故障的隐性原因。
SD-WAN 排障检查清单（按层勾选）：
| 层级 | 检查项 | 合格标准 |
|---|---|---|
| 物理层 | 光模块、线缆、端口协商 | 无错误计数、收发光正常 |
| 链路层 | 逐跳丢包、抖动、时延 | 丢包率≤3%、抖动≤30ms |
| 网络层 | 路由优先级、隧道 MTU/MSS | Overlay 路由优先、大包不丢 |
| 应用层 | QoS 匹配、切换触发条件 | 核心业务流量命中策略、切换在预期时间内完成 |
按这个顺序排查，遇到 SD-WAN 配置错误排查或多链路切换不生效的场景，能减少"查了一圈不知道为什么"的无效工作。
常见问题解答
SD-WAN丢包怎么查？
用 mtr 或 traceroute 从源端到目的端逐跳检测，先定位丢包集中出现在哪一段。若丢包集中在某一跳或区间，通常是公网路径拥塞或跨运营商互联点问题；若丢包只在特定业务流量下出现，需进一步检查 SD-WAN 的路由优先级和应用识别策略是否被旁路。连续丢包率超过 3%，实时音视频通常已明显劣化。
SD-WAN抖动是什么原因引起的？
抖动多来自链路负载突变、公网多跳拥塞或隧道 Keepalive 检测过于灵敏。若物理链路在高峰期突发拥塞，探测报文超时可能被误判为隧道中断，触发不必要的切换或震荡。可先确认链路本身是否拥塞，再检查 Keepalive 周期与重试参数是否适合当前链路质量。
SD-WAN配置错误怎么排查？
按"实际转发路径是否符合策略预期"优先排查。先确认路由优先级：若 OSPF 管理距离优于 SD-WAN 导入的 BGP 路由，流量会绕过 Overlay 策略走回原路径；再确认 QoS 和应用识别是否真正匹配目标流量，以及多链路切换阈值是否导致频繁震荡或切换不生效。
跨运营商线路丢包如何处理？
跨运营商链路丢包通常发生在两家运营商骨干互联的交换点，单方面扩容难以解决。常见思路是引入多线路质量探测与自动选路，让关键业务避开质量劣化的跨运营商路径。部分服务商基于混合组网冗余提供主备切换能力，故障时可快速把核心业务切到备用链路。
多链路切换不生效怎么办？
先确认切换触发条件是否被正确配置。常见原因是 BFD 检测周期过长，故障感知超过 1 分钟，业务先断后切；或是路由优先级冲突导致切换策略根本没有参与选路。逐一检查 BFD 参数、路由管理距离和 Overlay 路由导入情况，通常能定位出是"没触发"还是"触发了但没生效"。