摘要： 本文围绕"SD-WAN 主备切换成功但业务仍然断网"这一常见现象展开，先说明链路可用并不等于业务连接自动恢复，再拆解故障检测、切换决策、路由更新与会话恢复四个阶段，分析故障检测阈值、切换时间与会话状态三个关键影响因素，并给出主备切换测试的设计方法、耗时计算方式与五步排查路径，最后总结需要进一步优化配置或架构的典型场景，帮助读者从网络与业务两个层面定位并改善切换后的中断问题。
一、为什么 SD-WAN 主备切换成功，业务仍然会断网？
在企业网络中，SD-WAN 通常会通过主备链路、链路质量检测和自动切换机制，提高网络的可用性。当主用链路发生故障时，系统将流量切换到备用链路，尽可能减少业务受到的影响。
但实际使用中，经常会出现一种情况：设备显示主备切换成功，网页却仍然打不开；监控显示备用链路已经接管，远程桌面却断开了；网络恢复了，正在进行的文件传输却没有继续。
这并不一定意味着主备切换机制失效，而是因为链路恢复可用，不等于业务连接自动恢复。
整个过程涉及故障检测、切换决策、路由更新、数据转发以及应用会话恢复等多个环节。任何一个环节存在延迟或状态不一致，都可能造成短暂甚至较长时间的业务中断。
例如，某企业的办公网络同时接入两条外部链路，日常业务通过主用链路访问云端管理系统。当主用链路出现故障后，备用链路虽然能够正常转发数据，但原有连接可能仍然绑定在旧的出口地址或旧的网络路径上。此时，用户可能需要重新登录系统，甚至重新发起业务请求。
因此，分析 SD-WAN 主备切换为什么仍然会断网，不能只看设备有没有完成切换，还需要关注切换前后的网络状态与业务状态。
二、SD-WAN 主备切换的完整过程
要定位链路切换断网问题，首先需要了解一次自动切换通常经历哪些阶段。
1. 故障检测：系统如何发现链路异常？
SD-WAN 设备需要持续判断当前链路是否可用，以及链路质量是否满足业务要求。
常见检测方式包括：
- 物理接口状态检测： 通过接口状态判断网线断开、端口故障等问题。
- 主动探测： 向指定目标发送探测报文，根据响应情况判断网络连通性。
- 链路质量检测： 监测时延、丢包率、抖动等指标，识别质量下降的链路。
- 协议状态检测： 根据隧道、路由邻居或其他协议的状态判断连接是否正常。
需要注意的是，接口正常并不代表整条链路正常。例如，设备与上游网关之间仍然连通，但后续网络出现故障，接口状态可能始终保持正常。
类似地，普通连通性探测成功，也不一定代表实际业务系统能够正常访问。探测目标、检测协议和真实业务路径之间可能存在差异。
因此，检测机制不仅要关注物理连接，还应尽可能覆盖实际的数据转发路径。
2. 切换决策：什么时候应该切换？
检测到异常之后，系统还需要根据策略决定是否启动切换。
常见决策条件包括：
- 链路连续多次探测失败；
- 丢包率超过设定阈值；
- 时延或抖动持续超出业务要求；
- 隧道或路由邻居状态异常；
- 主用链路不再满足预设的选路条件。
这里涉及两个重要参数：检测周期和故障判定阈值。
假设系统每隔一段时间发送一次探测报文，并设置连续多次失败后判定链路故障。那么，系统通常需要等待一定时间，才能确认故障成立。
检测过于宽松，可能导致故障发现不及时；检测过于敏感，则可能在短暂丢包或网络抖动时频繁切换。
对于企业网络而言，合理的做法不是简单地将检测周期调到最短，而是结合链路质量、设备处理能力、业务容忍度和误切换风险进行配置。
3. 路由更新：备用链路接管流量
系统确认主用链路异常后，会按照具体实现和配置执行选路调整。
可能涉及的操作包括：
- 将故障链路标记为不可用或降低其选路优先级；
- 更新路由或转发策略；
- 将符合条件的业务流量引导至备用链路；
- 确认备用链路及相关隧道具备转发能力。
需要注意，链路切换、路由收敛和数据平面更新不一定同时完成。
即使控制平面已经完成选路决策，转发表、隧道状态或相关转发资源仍可能需要一定时间才能达到一致状态。
如果切换后出现部分业务恢复、部分业务仍然失败，就需要进一步检查实际转发路径，而不是只看控制台上的链路状态。
4. 会话恢复：为什么网络通了，应用却没恢复？
这是 SD-WAN 主备切换后最容易被忽略的环节。
对于新发起的连接，只要备用链路、路由和访问策略正常，业务通常可以重新建立连接。但对于切换前已经建立的连接，情况可能不同。
例如，某条 TCP 连接已经通过主用链路建立，切换后数据开始经备用链路传输。如果备用链路使用不同的出口公网 IP，或者连接经过的网络路径发生变化，原有会话可能无法继续使用。
常见原因包括：
- 源地址发生变化： 连接使用的公网出口地址发生变化，远端系统可能无法将新报文识别为原有会话。
- NAT 状态不一致： 新旧出口设备或链路上的地址转换状态不同，导致后续报文无法正确匹配。
- 防火墙会话状态不匹配： 状态检测设备未同步相关连接状态，切换后可能丢弃后续报文。
- TCP 连接超时或重置： 连接在故障期间持续丢包，超过应用或系统的等待时间后被关闭。
- 应用层连接无法续用： 即使底层网络已经恢复，应用也可能需要重新建立连接或重新认证。
因此，网络高可用不只是让备用链路能够接管流量，还需要考虑出口地址、会话状态、转发策略与应用自身的恢复机制。
5. 主备切换时序与中断耗时点
下面用一张时序图把上述四个阶段串起来，并标注每个阶段可能产生中断耗时的位置：
#mermaid-svg-uuMEATi5wJ0u3MBS{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-uuMEATi5wJ0u3MBS .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-uuMEATi5wJ0u3MBS .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-uuMEATi5wJ0u3MBS .error-icon{fill:#552222;}#mermaid-svg-uuMEATi5wJ0u3MBS .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-uuMEATi5wJ0u3MBS .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-uuMEATi5wJ0u3MBS .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-uuMEATi5wJ0u3MBS .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-uuMEATi5wJ0u3MBS .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-uuMEATi5wJ0u3MBS .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-uuMEATi5wJ0u3MBS .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-uuMEATi5wJ0u3MBS .marker{fill:#333333;stroke:#333333;}#mermaid-svg-uuMEATi5wJ0u3MBS .marker.cross{stroke:#333333;}#mermaid-svg-uuMEATi5wJ0u3MBS svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-uuMEATi5wJ0u3MBS p{margin:0;}#mermaid-svg-uuMEATi5wJ0u3MBS .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-uuMEATi5wJ0u3MBS .cluster-label text{fill:#333;}#mermaid-svg-uuMEATi5wJ0u3MBS .cluster-label span{color:#333;}#mermaid-svg-uuMEATi5wJ0u3MBS .cluster-label span p{background-color:transparent;}#mermaid-svg-uuMEATi5wJ0u3MBS .label text,#mermaid-svg-uuMEATi5wJ0u3MBS span{fill:#333;color:#333;}#mermaid-svg-uuMEATi5wJ0u3MBS .node rect,#mermaid-svg-uuMEATi5wJ0u3MBS .node circle,#mermaid-svg-uuMEATi5wJ0u3MBS .node ellipse,#mermaid-svg-uuMEATi5wJ0u3MBS .node polygon,#mermaid-svg-uuMEATi5wJ0u3MBS .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-uuMEATi5wJ0u3MBS .rough-node .label text,#mermaid-svg-uuMEATi5wJ0u3MBS .node .label text,#mermaid-svg-uuMEATi5wJ0u3MBS .image-shape .label,#mermaid-svg-uuMEATi5wJ0u3MBS .icon-shape .label{text-anchor:middle;}#mermaid-svg-uuMEATi5wJ0u3MBS .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-uuMEATi5wJ0u3MBS .rough-node .label,#mermaid-svg-uuMEATi5wJ0u3MBS .node .label,#mermaid-svg-uuMEATi5wJ0u3MBS .image-shape .label,#mermaid-svg-uuMEATi5wJ0u3MBS .icon-shape .label{text-align:center;}#mermaid-svg-uuMEATi5wJ0u3MBS .node.clickable{cursor:pointer;}#mermaid-svg-uuMEATi5wJ0u3MBS .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-uuMEATi5wJ0u3MBS .arrowheadPath{fill:#333333;}#mermaid-svg-uuMEATi5wJ0u3MBS .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-uuMEATi5wJ0u3MBS .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-uuMEATi5wJ0u3MBS .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-uuMEATi5wJ0u3MBS .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-uuMEATi5wJ0u3MBS .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-uuMEATi5wJ0u3MBS .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-uuMEATi5wJ0u3MBS .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-uuMEATi5wJ0u3MBS .cluster text{fill:#333;}#mermaid-svg-uuMEATi5wJ0u3MBS .cluster span{color:#333;}#mermaid-svg-uuMEATi5wJ0u3MBS div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-uuMEATi5wJ0u3MBS .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-uuMEATi5wJ0u3MBS rect.text{fill:none;stroke-width:0;}#mermaid-svg-uuMEATi5wJ0u3MBS .icon-shape,#mermaid-svg-uuMEATi5wJ0u3MBS .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-uuMEATi5wJ0u3MBS .icon-shape p,#mermaid-svg-uuMEATi5wJ0u3MBS .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-uuMEATi5wJ0u3MBS .icon-shape .label rect,#mermaid-svg-uuMEATi5wJ0u3MBS .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-uuMEATi5wJ0u3MBS .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-uuMEATi5wJ0u3MBS .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-uuMEATi5wJ0u3MBS :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 耗时点①：故障未被及时识别
耗时点②：判定阈值过松或过紧
耗时点③：控制面与数据面不一致
耗时点④：出口地址变化、会话无法续用
耗时点⑤：应用等待超时后重新认证
故障发生
业务报文开始丢失
故障检测
探测周期 × 失败次数
切换决策
阈值判定与策略匹配
路由与转发更新
路由收敛、隧道与转发表刷新
会话恢复
NAT、防火墙状态与应用重连
业务真正恢复
读图说明：图中五个阶段横向串联，从故障发生到业务真正恢复，中间任何一段都不是瞬时完成的。耗时点①来自检测周期与失败次数的乘积，耗时点②取决于阈值设置是否合理，耗时点③体现控制面决策与数据面转发之间的时间差，耗时点④和⑤则属于会话与应用层，往往比网络恢复更晚结束。因此排查时应分段计时，而不是只看设备是否显示切换成功。
三、影响主备切换效果的三个关键因素
1. 故障检测阈值：发现故障需要多久？
故障检测时间直接影响切换开始的时机。
以主动探测为例，如果系统采用固定探测周期，并要求连续多次探测失败才判定故障，那么检测过程需要消耗一定时间。实际耗时还会受到探测报文调度、响应超时、设备处理和具体实现方式的影响。
对于支持双向转发检测（BFD）的场景，检测时间通常与协商后的报文发送间隔和检测倍数有关。相关机制可以参考 IETF 的 RFC 5880。需要强调的是，BFD 是故障检测机制之一，并不意味着启用后所有业务都能实现无感切换。
配置时建议关注以下问题：
- 探测目标是否能够代表真实业务路径；
- 探测失败次数和超时设置是否合理；
- 短暂丢包是否会触发误切换；
- 不同链路的时延和丢包特征是否存在明显差异；
- 故障检测机制能否覆盖接口正常、但实际转发异常的情况。
优化目标是及时识别真实故障，同时控制误切换，而不是一味追求更短的检测周期。
2. 切换时间：从故障发生到流量恢复需要多久？
在实际排查中，可以把总切换时间拆分为多个阶段：
总切换耗时 ≈ 故障检测时间 + 切换决策时间 + 路由与转发更新耗时 + 业务恢复耗时。
这是一种用于定位问题的分析模型，并非适用于所有设备的严格公式。各阶段可能存在重叠，部分系统也会提前建立备用隧道或预先维护转发状态。
其中，故障检测和路由更新主要影响网络何时具备新的转发能力；业务恢复时间还会受到连接状态、应用重试策略和远端服务行为的影响。
因此，建议在测试中分别记录：
- 故障实际发生的时间；
- 设备检测到故障的时间；
- 主备切换决策完成的时间；
- 备用链路首次成功转发业务报文的时间；
- 关键业务恢复正常的时间。
这样才能判断问题究竟发生在检测、切换还是业务恢复阶段。
3. 会话状态：备用链路能否承接原有连接？
不同业务对链路切换的敏感程度并不相同。
例如：
- 普通网页访问通常可以通过重新发起请求恢复，但用户可能遇到页面加载失败或需要刷新。
- 远程桌面和实时交互应用对短时丢包、连接重置较为敏感，可能出现卡顿或断开。
- 大文件传输可能因 TCP 连接中断而失败，需要应用重新传输。
- 长连接业务可能依赖固定的出口地址、连接状态或应用层心跳。
- 对源地址有校验要求的系统，可能拒绝来自新出口地址的连接。
针对这些场景，需要分别评估网络路径切换能力和业务会话恢复能力。
如果业务依赖原有连接持续工作，可以进一步评估出口地址稳定性、会话状态同步能力、连接迁移机制和应用重连策略。具体支持情况取决于设备、网络架构和业务协议，不能简单认为所有连接都可以无损迁移。
四、如何设计 SD-WAN 主备切换测试？
判断网络高可用是否达到预期，需要通过可重复的测试验证，而不是只看设备显示的切换成功状态。
1. 明确测试环境与测试条件
开始测试前，建议记录以下信息：
| 测试项目 | 需要记录的内容 |
|---|---|
| 网络拓扑 | 主用链路、备用链路、出口设备及业务系统位置 |
| 链路参数 | 带宽、基础时延、丢包率及备用链路状态 |
| 切换策略 | 检测周期、超时时间、故障判定阈值和选路策略 |
| 地址与会话 | 出口地址、NAT 方式、防火墙状态及会话保持策略 |
| 测试业务 | 网页访问、持续 TCP 连接、文件传输或实时交互业务 |
| 测试工具 | 设备日志、链路探测、业务端日志和抓包工具 |
记录测试条件的目的，是确保不同时间、不同配置下的测试结果可以比较。
如果没有这些基础信息，即使记录到一次中断时间，也很难判断该结果是否具有代表性。
2. 设计不同类型的故障场景
建议至少覆盖以下场景。
场景一：物理链路中断
模拟主用链路接口断开或上游连接中断，检查设备能否及时识别故障并切换至备用链路。
场景二：链路仍然连通，但质量下降
通过受控测试环境模拟丢包、时延升高或抖动，验证质量阈值是否能够正确触发切换，同时观察是否出现频繁切换。
场景三：隧道或路由状态异常
在允许测试的环境中模拟隧道中断、路由邻居异常等情况，检查设备的检测机制、路由更新和恢复过程。
场景四：持续业务会话
在切换前建立持续运行的业务连接，观察切换后原有连接是否继续工作，以及是否需要重新建立连接。
场景五：主用链路恢复
主用链路恢复后，观察系统是否自动回切、是否出现短时间内反复切换，以及现有业务连接是否再次受到影响。
测试应在授权的实验环境或维护窗口内执行，避免直接对生产网络进行可能影响业务的故障注入。
3. 记录中断时间与业务恢复情况
建议同时监测网络探测和真实业务。仅使用 Ping 测试，可能无法反映 TCP 会话、应用认证或业务请求是否正常。
可以使用下面的记录模板：
| 记录项目 | 示例记录方式 |
|---|---|
| 故障触发时间 | 记录实际执行故障注入的时间戳 |
| 故障识别时间 | 记录设备首次确认链路异常的时间戳 |
| 切换完成时间 | 记录路由或转发路径完成更新的时间戳 |
| 网络恢复时间 | 记录探测目标首次持续恢复正常的时间戳 |
| 业务恢复时间 | 记录关键应用重新正常响应的时间戳 |
| 原有会话状态 | 记录连接保持、超时、重置或重新建立 |
| 其他异常 | 记录丢包、误切换、回切波动及日志信息 |
这里需要区分两个指标：
网络中断时间： 从故障发生到网络转发能力恢复所经历的时间。
业务中断时间： 从故障发生到目标业务重新正常工作的时间。
两者并不一定相等。假设备用链路已经恢复转发，但应用连接仍在等待超时或重连，那么业务中断时间就可能明显长于网络中断时间。
建议在相同条件下重复测试，并记录每次结果的最小值、最大值和中位数。如果需要评估高分位恢复时间，还可以进一步统计 P95 或 P99。测试报告应说明样本数量、测试时长、业务类型和统计方法，不能用单次测试结果直接代表长期表现。
4. 如何计算切换耗时？
对于具备统一时间戳的测试记录，可以使用以下计算方式：
- 故障检测耗时 = 故障识别时间 − 故障触发时间
- 路径切换耗时 = 转发路径恢复时间 − 故障识别时间
- 业务恢复耗时 = 业务恢复时间 − 故障触发时间
这些指标有助于定位瓶颈。如果故障检测耗时较长，应优先检查探测周期、超时阈值和故障识别方式；如果网络已经恢复但业务仍然中断，则应重点检查连接状态、出口地址、NAT、防火墙和应用重连机制。
为了避免测量误差，各设备和测试端应尽量采用统一、可靠的时间基准。对于无法精确捕获故障触发时刻的场景，也应在报告中注明时间测量方式及其误差范围。
没有真实实验记录时，不应直接给出固定的毫秒级切换结论。 实际表现会受到设备型号、链路质量、检测策略、网络拓扑和业务类型等多种因素影响。
五、主备切换后仍然断网，应该如何排查？
可以按照以下顺序进行定位。
第一步：确认故障是否被正确检测
查看设备日志、探测记录和链路状态，确认系统是否识别了实际故障。
如果接口状态正常，但业务流量无法通过，应检查探测目标是否覆盖完整业务路径，以及检测机制能否识别上游转发异常。
第二步：确认切换决策是否执行
检查故障发生后，系统是否真正触发主备切换，切换原因是否与预期一致。
如果链路已经异常，但系统仍将其作为首选路径，需要检查质量阈值、选路优先级、策略匹配条件和故障保持时间等设置。
第三步：检查备用链路是否具备完整转发能力
确认备用链路的接口、隧道、路由、访问控制和相关安全策略均正常。
还需要从业务实际访问的目标出发进行验证，不能只确认备用链路能够访问一个与业务无关的探测地址。
第四步：检查连接状态与出口地址
如果新建连接正常，而切换前的连接持续失败，应重点检查：
- 切换前后出口公网 IP 是否变化；
- NAT 映射和防火墙会话状态是否一致；
- 远端系统是否限制源地址变化；
- 原有 TCP 连接是否已经超时或被重置；
- 应用是否具备自动重连能力。
这一类问题往往不是简单调整路由优先级就能解决的。
第五步：验证恢复和回切过程
主用链路恢复并不意味着应立即无条件回切。
如果链路质量仍不稳定，频繁回切可能导致新的丢包、连接中断或路由震荡。可以根据设备能力评估恢复确认时间、回切条件和防抖策略，并通过测试验证其效果。
六、哪些场景需要进一步优化配置或架构？
当常规检测与选路配置无法满足业务需求时，可以根据实际瓶颈采取进一步措施。
场景一：故障发现明显滞后。
检查探测周期、超时机制和检测目标，评估是否需要更适合当前网络环境的快速检测机制。调整时应兼顾设备负载与误报风险。
场景二：切换完成后仍有大量连接中断。
检查出口地址是否变化、NAT 状态是否可延续，以及防火墙和其他状态检测设备是否支持必要的会话同步。如果业务必须依赖持续连接，还需要结合应用协议评估重连或连接迁移方案。
场景三：主备切换频繁，网络反复波动。
检查链路质量阈值是否过于敏感，是否缺少故障确认、恢复确认和回切防抖机制。对于质量波动明显的链路，应根据实际业务要求重新制定选路条件。
场景四：备用链路接管后性能不足。
核查备用链路带宽、并发连接能力、设备处理能力以及关键业务的流量优先级。备用链路即使能够接管流量，也不代表它能够在高负载下提供与主用链路相同的业务体验。
场景五：单一设备故障仍会导致整体网络中断。
如果业务对可用性要求较高，还需要评估设备冗余、电源与接入冗余、不同运营商路径、故障域隔离及管理控制面的可靠性。
主备链路解决的是部分链路故障问题，不能自动消除所有设备、地址、会话和应用层面的单点风险。网络高可用需要从链路、设备、路由、会话和业务多个层面进行设计。
七、总结：网络切换成功，不代表业务已经恢复
SD-WAN 主备切换后仍然出现断网，常见原因可以归纳为四类：故障检测不够及时、切换决策或路由更新存在延迟、备用链路无法完整承接业务，以及原有连接状态无法在切换后继续使用。
排查时，建议按照"故障检测---切换决策---路由更新---网络恢复---业务恢复"的顺序逐步验证，并分别记录网络中断时间与业务中断时间。
对于企业而言，真正有价值的网络高可用方案，不只是能够在故障发生时自动切换，还应具备可观测、可验证、可定位和可持续优化的能力。