摘要： 本文围绕"SD-WAN 主备链路已经切换，业务却仍然中断"这一常见现象展开，指出链路切换只解决流量转发路径问题，业务恢复还取决于故障检测速度、切换决策、路由收敛、NAT 与会话状态以及应用重连机制。文章按"检测---决策---转发---会话---应用"的顺序拆解各环节的耗时与失效原因，给出五步定位方法、主备切换验收流程（T0--T5 时间点记录）以及六项优化建议，帮助运维人员区分"链路是否切换""新连接能否建立""原有连接能否延续"三类问题，从而准确判断中断发生在哪个阶段。
一、主备链路已经切换，为什么业务还是中断了？
在企业网络中，SD-WAN 通常会配置主备链路。当主链路发生故障时，设备检测到异常后，将流量切换到备用链路，以减少网络中断对业务的影响。
但在实际运行中，经常会遇到一种情况：
主链路已经显示故障，备用链路也已经接管流量，网络状态看起来恢复正常，但用户访问业务系统时，仍然会遇到网页加载失败、远程桌面断开、文件传输中止，甚至需要重新登录等问题。
这并不一定意味着主备切换机制失效了。
链路切换解决的是流量转发路径的问题，而业务恢复还取决于故障检测速度、路由收敛、连接状态、NAT 映射以及应用自身的重连机制。
例如，一家企业通过 SD-WAN 连接海外办公系统。主链路出现丢包后，设备在数秒内完成了备用链路切换。但如果原有 TCP 连接依赖主链路上的 NAT 出口，切换后出口 IP 发生变化，服务器可能无法识别新的数据流。此时，即使网络已经恢复，原有连接也可能继续超时。
因此，分析主备切换问题，不能只看设备是否显示"切换成功"，还需要沿着检测、决策、转发和会话恢复几个阶段逐一排查。
二、SD-WAN 主备切换的完整过程
从技术实现来看，一次主备切换通常涉及以下几个环节：
- 故障检测： 通过链路探测、心跳、主动探测报文或业务质量指标判断主链路是否异常。
- 切换决策： 根据探测结果、链路优先级、阈值和防抖策略，决定是否启用备用链路。
- 路由与转发更新： 更新路由表、策略路由或隧道转发状态，使新流量经备用链路传输。
- 会话处理： 根据连接状态、NAT 映射和隧道机制，决定已有会话能否继续使用。
- 业务恢复： 由 TCP、应用协议或客户端重连机制恢复业务访问。
这几个环节并不总是同步完成。设备可能已经完成路由切换，但已有连接还在等待超时；也可能探测报文已经恢复，而路由和会话状态尚未稳定。
排查时，应将"检测到故障的时间""备用链路开始转发的时间"和"业务恢复的时间"区分开来，而不是将它们统称为切换时间。
三、故障检测：为什么主链路出问题后，没有立即切换？
故障检测是主备切换的第一个关键环节。检测过慢会延长中断时间，而检测过于敏感，又可能引发不必要的切换。
1. 仅检测链路是否在线，无法识别所有故障
如果设备只通过物理接口状态判断链路是否正常，那么网线断开、接口关闭等故障通常能够被及时发现。
但实际网络故障不一定表现为接口断开。
例如：
- 接口状态正常，但上游设备无法转发数据。
- 网关可以访问，但目标业务服务器无法访问。
- 链路没有完全中断，却出现持续丢包或高延迟。
- DNS 解析正常，但后续 TCP 连接无法建立。
- 隧道仍然存在，但业务流量经过的路径已经发生异常。
这类故障属于逻辑连通性或业务质量异常。如果探测目标选择不合理，设备可能认为主链路仍然正常，导致切换延迟，甚至始终不触发切换。
因此，链路监控不能只依赖物理接口状态，还应结合网关可达性、隧道状态和关键业务目标的探测结果。
2. 探测周期和故障阈值决定检测耗时
假设某设备每隔 1 秒发送一次探测报文，并将连续 3 次探测失败设置为故障条件。
在探测报文持续失败、没有其他快速故障信号的情况下，检测时间可能达到数秒。具体耗时还取决于探测调度、超时设置、失败计数方式以及设备实现。
如果探测周期较长，故障可能无法及时发现；如果连续失败阈值过低，短暂拥塞就可能触发切换。
常见参数包括：
- 探测间隔：两次探测之间的时间。
- 探测超时：等待一次探测响应的最长时间。
- 失败阈值：连续多少次失败后判定异常。
- 恢复阈值：连续多少次成功后判定链路恢复。
- 防抖时间：避免链路状态短时间内反复变化。
这些参数需要结合链路质量、业务敏感程度和设备能力进行调整，不宜直接套用固定数值。
3. 检测目标不同，判断结果也不同
假设设备只探测本地运营商网关，那么网关正常只能说明当前节点到网关的连接基本可用，并不能证明后续所有网络路径都正常。
更合理的方式是根据业务架构设置分层探测目标：
- 第一层：本地网关或下一跳地址。
- 第二层：SD-WAN 隧道对端或远端网络节点。
- 第三层：关键业务服务器、SaaS 服务或应用入口。
分层探测能够帮助运维人员区分本地接入故障、隧道异常和业务目标不可达等不同问题。但探测目标也不宜无限增加，应优先选择能够代表实际业务路径的目标，并注意服务器限速、ICMP 丢弃等因素对检测结果的影响。
四、切换决策：检测到故障，为什么仍然没有立即恢复？
设备检测到主链路异常后，还需要根据策略决定是否切换，以及切换到哪条链路。
1. 主备优先级与链路质量策略存在差异
传统主备策略通常按照链路优先级进行选择。当主链路不可用时，备用链路接管流量。
但在 SD-WAN 环境中，部分部署还会根据延迟、丢包率、抖动、带宽利用率等指标调整路径。
例如，主链路虽然没有完全中断，但丢包率已经超过业务要求。设备可能根据策略将业务迁移至备用链路。
这里需要注意：链路质量超过阈值，不一定意味着设备会立即切换。实际行为取决于产品是否支持相应的质量策略，以及策略中是否配置了持续时间、优先级和恢复条件。
排查时，需要确认触发切换的究竟是接口故障、隧道故障，还是链路质量不达标，不能只根据最终的主备状态判断原因。
2. 路由收敛和策略更新也需要时间
当备用链路接管流量时，设备可能需要更新路由表、策略路由、隧道转发表或相关邻接状态。
如果网络中还涉及动态路由协议、多个网关或集中式控制系统，路径变化可能需要额外的收敛时间。
此时可能出现以下现象：
- 设备日志已经记录切换，但部分流量仍然走原路径。
- 新建连接可以正常访问，部分已有连接仍然超时。
- 不同业务恢复时间不一致。
- 部分目的地址正常，另一些目的地址仍然不可达。
建议检查路由表、策略路由和实际流量路径，确认切换后的数据包确实经过备用链路，而不是只查看控制台上的链路状态。
3. 防抖策略可能延长切换时间
主链路出现短暂丢包后，如果设备立即切换，而链路很快又恢复，就可能出现主备链路反复切换的情况。
为了避免这种现象，设备通常可以配置故障阈值、恢复阈值或切换防抖机制。
但防抖并非越长越好。防抖时间过长，会增加故障期间的等待时间；过短，则可能导致链路状态频繁波动。
较合理的配置方式是结合历史链路质量数据、故障持续时间和业务可接受的中断范围进行验证，并分别观察故障触发与恢复触发的行为。
五、会话恢复：为什么网络通了，原有连接还是断了？
这是主备切换后最容易被忽略的问题。
网络能够转发新的数据包，不代表此前建立的 TCP 连接、NAT 映射或应用会话仍然有效。
1. 出口 IP 变化可能导致原有 TCP 连接失效
假设客户端通过主链路访问远端服务器，建立了一条 TCP 连接。
主链路故障后，设备将流量切换到备用链路。如果备用链路使用不同的公网出口 IP，那么原有连接的网络五元组可能发生变化。
网络五元组通常包括：
- 源 IP 地址
- 源端口
- 目的 IP 地址
- 目的端口
- 传输层协议
对于已经建立的 TCP 连接，服务器通常会根据原有连接状态识别后续报文。若源 IP 或端口发生变化，新的报文可能无法匹配原有连接，服务器也就无法将它视为原连接的正常延续。
结果是：备用链路可以正常访问服务器，但原有 TCP 连接已经失效，需要重新建立连接。
因此，主备切换后能否保留原有会话，取决于出口地址、NAT 状态、连接跟踪和具体网络架构，而不是单纯取决于是否启用了 SD-WAN。
2. NAT 状态不同步会影响已有连接
如果主备设备分别维护 NAT 转换表或连接跟踪状态，而备用设备没有同步相关状态，那么切换后就可能出现以下问题：
- 已有连接的数据包无法匹配 NAT 映射。
- 返回流量无法正确关联到内部客户端。
- 防火墙将切换后的报文识别为异常连接。
- 新连接正常，切换前建立的连接持续超时。
在排查时，应确认主备设备是否支持会话状态同步，以及同步范围是否包含相关 NAT 和防火墙状态。
需要强调的是，会话同步并不自动解决所有连接中断问题。如果主备出口 IP 不同，或者中间网络的连接状态发生变化，已有 TCP 会话仍可能无法继续使用。
为便于快速判断不同部署方式对会话连续性的影响，可将出口 IP 与 NAT 状态同步两个因素组合起来对比：
| 部署场景 | 已有 TCP 连接能否延续 | 新建连接是否正常 | 典型故障现象 | 排查要点 |
|---|---|---|---|---|
| 出口 IP 不变 + NAT 状态同步 | 通常可以延续 | 正常 | 切换瞬间可能出现短暂丢包或延迟抖动，业务基本无感 | 确认会话同步范围覆盖 NAT 与防火墙状态，并核对同步是否实时生效 |
| 出口 IP 变化 + NAT 状态不同步 | 基本无法延续 | 正常 | 网页需刷新、远程桌面断开、数据库连接池重建，用户感知中断时间较长 | 对比切换前后五元组，检查出口地址、NAT 映射与连接跟踪是否一致 |
| 出口 IP 不变 + NAT 状态不同步 | 部分可延续，取决于连接跟踪是否保留 | 正常 | 新连接正常，切换前建立的连接持续超时或返回流量无法关联 | 重点检查 NAT 转换表与连接跟踪状态，确认返回流量能否正确回程 |
从选型角度看，若业务对会话连续性要求较高，应优先选择主备出口 IP 一致且支持 NAT 与连接跟踪状态同步的方案，这是保留已有连接的前提；若受线路条件限制无法保证出口 IP 一致，则应把重点放在应用层重连、超时与幂等设计上，并在验收阶段明确记录会话可延续的边界，避免对"切换无损"产生误判。
3. TCP 超时会让用户感觉"断网时间很长"
即使备用链路已经恢复转发，客户端也可能仍在等待旧连接的重传或超时处理。
不同应用和操作系统的 TCP 重传、连接超时及错误处理机制存在差异。因此，业务中断时间可能明显长于设备显示的链路切换时间。
例如：
- 网页请求失败，但刷新页面后可以正常访问。
- 文件传输中断，需要重新上传或续传。
- 远程桌面断开，需要重新连接。
- 数据库连接失效，应用连接池需要重新创建连接。
- 长连接业务短暂失联，等待心跳超时后才启动重连。
这类现象不一定意味着备用链路有问题，更可能是旧连接无法恢复，或者应用没有及时建立新连接。
4. 应用层重连机制决定最终体验
不同业务对网络中断的容忍程度不同。
普通网页访问通常可以通过重新发起请求恢复；长连接业务、数据库会话和实时音视频则可能对短时中断更敏感。
因此，除了优化链路切换，还应检查应用是否具备合理的连接超时、重试、重连和断点续传机制。
需要注意，重试也不应无限进行。对于写入订单、提交支付或创建任务等非幂等操作，应结合请求 ID、幂等控制和业务状态核验设计重试策略，避免网络中断后重复执行操作。
六、如何定位主备切换后仍然断网的问题？
下面这张流程图把五步排查串成一条决策路径，每一步先判断当前环节是否正常，再根据"是/否"决定继续往下走还是就地深入排查：
#mermaid-svg-F6RS5SsKgs4K1k9e{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-F6RS5SsKgs4K1k9e .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-F6RS5SsKgs4K1k9e .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-F6RS5SsKgs4K1k9e .error-icon{fill:#552222;}#mermaid-svg-F6RS5SsKgs4K1k9e .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-F6RS5SsKgs4K1k9e .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-F6RS5SsKgs4K1k9e .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-F6RS5SsKgs4K1k9e .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-F6RS5SsKgs4K1k9e .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-F6RS5SsKgs4K1k9e .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-F6RS5SsKgs4K1k9e .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-F6RS5SsKgs4K1k9e .marker{fill:#333333;stroke:#333333;}#mermaid-svg-F6RS5SsKgs4K1k9e .marker.cross{stroke:#333333;}#mermaid-svg-F6RS5SsKgs4K1k9e svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-F6RS5SsKgs4K1k9e p{margin:0;}#mermaid-svg-F6RS5SsKgs4K1k9e .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-F6RS5SsKgs4K1k9e .cluster-label text{fill:#333;}#mermaid-svg-F6RS5SsKgs4K1k9e .cluster-label span{color:#333;}#mermaid-svg-F6RS5SsKgs4K1k9e .cluster-label span p{background-color:transparent;}#mermaid-svg-F6RS5SsKgs4K1k9e .label text,#mermaid-svg-F6RS5SsKgs4K1k9e span{fill:#333;color:#333;}#mermaid-svg-F6RS5SsKgs4K1k9e .node rect,#mermaid-svg-F6RS5SsKgs4K1k9e .node circle,#mermaid-svg-F6RS5SsKgs4K1k9e .node ellipse,#mermaid-svg-F6RS5SsKgs4K1k9e .node polygon,#mermaid-svg-F6RS5SsKgs4K1k9e .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-F6RS5SsKgs4K1k9e .rough-node .label text,#mermaid-svg-F6RS5SsKgs4K1k9e .node .label text,#mermaid-svg-F6RS5SsKgs4K1k9e .image-shape .label,#mermaid-svg-F6RS5SsKgs4K1k9e .icon-shape .label{text-anchor:middle;}#mermaid-svg-F6RS5SsKgs4K1k9e .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-F6RS5SsKgs4K1k9e .rough-node .label,#mermaid-svg-F6RS5SsKgs4K1k9e .node .label,#mermaid-svg-F6RS5SsKgs4K1k9e .image-shape .label,#mermaid-svg-F6RS5SsKgs4K1k9e .icon-shape .label{text-align:center;}#mermaid-svg-F6RS5SsKgs4K1k9e .node.clickable{cursor:pointer;}#mermaid-svg-F6RS5SsKgs4K1k9e .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-F6RS5SsKgs4K1k9e .arrowheadPath{fill:#333333;}#mermaid-svg-F6RS5SsKgs4K1k9e .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-F6RS5SsKgs4K1k9e .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-F6RS5SsKgs4K1k9e .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-F6RS5SsKgs4K1k9e .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-F6RS5SsKgs4K1k9e .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-F6RS5SsKgs4K1k9e .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-F6RS5SsKgs4K1k9e .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-F6RS5SsKgs4K1k9e .cluster text{fill:#333;}#mermaid-svg-F6RS5SsKgs4K1k9e .cluster span{color:#333;}#mermaid-svg-F6RS5SsKgs4K1k9e 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-F6RS5SsKgs4K1k9e .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-F6RS5SsKgs4K1k9e rect.text{fill:none;stroke-width:0;}#mermaid-svg-F6RS5SsKgs4K1k9e .icon-shape,#mermaid-svg-F6RS5SsKgs4K1k9e .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-F6RS5SsKgs4K1k9e .icon-shape p,#mermaid-svg-F6RS5SsKgs4K1k9e .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-F6RS5SsKgs4K1k9e .icon-shape .label rect,#mermaid-svg-F6RS5SsKgs4K1k9e .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-F6RS5SsKgs4K1k9e .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-F6RS5SsKgs4K1k9e .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-F6RS5SsKgs4K1k9e :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 否
是
否
是
否
是
否
是
否
是
开始：主备已切换但业务仍中断
检测是否及时
检查探测目标、探测周期、超时与失败阈值
修正探测配置后重新验证
切换是否生效
检查路由优先级、策略匹配、隧道与转发表更新
确认流量实际经过备用链路
新建连接是否正常
排查路由、NAT、DNS、安全策略与双向可达性
修复后重新测试新建连接
双向路径与安全策略是否正常
检查回程路由、防火墙会话表、NAT 转换与端口放行
消除非对称路由与策略阻断
应用重连是否生效
检查连接超时、心跳、重试间隔与连接池失效检测
完善重连与幂等重试策略
定位完成：业务恢复正常
使用时应严格按"检测---切换---转发---会话---应用"的顺序自上而下推进：先确认故障检测是否及时，避免把检测延迟误判为切换失败；检测正常后再验证切换是否真正生效，确认流量确实走了备用链路；切换生效后区分新建连接与已有连接，若新建连接异常则回到路由、NAT 与安全策略层面排查；新建连接正常但业务仍不可用时，再检查双向路径与安全策略是否造成非对称路由或会话阻断；最后才落到应用层，检查重连、超时与重试配置。每一步的"否"分支都应就地定位并修复后再回到该判断节点复测，只有当前环节确认正常才进入下一步，这样可以避免在多个环节同时改动而无法判断问题根因。
建议按照"检测---切换---转发---会话---应用"的顺序进行排查，避免一开始就反复调整主备优先级或缩短探测周期。
第一步：确认故障检测是否及时
查看设备日志和探测记录，重点确认：
- 主链路首次异常的时间。
- 设备判定链路故障的时间。
- 探测失败次数是否达到配置阈值。
- 探测目标是否能代表实际业务路径。
- 是否存在丢包、延迟升高或探测误报。
如果链路已经出现明显异常，但设备迟迟没有判定故障，应优先检查探测目标、超时和失败阈值。
第二步：确认切换是否真正生效
检查主备状态、路由表、策略路由、隧道状态和实际流量路径。
可以使用系统支持的路由查询、连通性测试或路径跟踪工具，验证切换后访问目标的报文是否经过备用链路。
如果设备显示切换成功，但流量仍经过主链路，应进一步检查路由优先级、策略匹配和转发表更新情况。
第三步：区分新建连接与已有连接
这是判断会话问题的重要方法。
在备用链路已经稳定的前提下，分别测试：
- 新建一个到目标服务器的连接。
- 观察切换前已经建立的连接能否继续传输。
- 检查原有连接的源地址、NAT 映射及设备连接跟踪状态。
如果新建连接正常，而原有连接持续失败，就应重点排查出口 IP 变化、NAT 状态同步和连接超时，而不是继续把问题归因于链路不可达。
第四步：检查双向路径和安全策略
网络通信需要请求和响应都能够正确传递。
切换后，如果去程经过备用链路，回程却仍然经过其他出口，可能产生非对称路由问题。对于有状态防火墙、NAT 网关或严格的安全策略，这种变化可能导致报文被丢弃。
应检查：
- 去程与回程路由是否符合网络设计。
- 防火墙会话表是否存在对应连接。
- NAT 转换是否正确。
- 备用链路是否允许相关端口和协议。
- 远端访问控制是否依赖原有出口地址。
第五步：检查应用重连和超时配置
如果网络探测、新建连接和路由都正常，但应用仍然长时间不可用，就需要进一步分析应用日志。
重点查看连接超时、心跳超时、重试间隔、连接池失效检测和重连策略。对于文件传输、数据库访问及远程办公业务，还应确认客户端是否支持断点续传或自动重连。
七、建议建立一套主备切换验收流程
主备切换不能只验证"拔掉主链路后，备用链路能否接管"，还应测试切换对实际业务的影响。
可以将验收分为以下几个阶段：
1. 正常状态测试
记录主备链路的延迟、丢包、隧道状态、路由信息和业务连接状态，形成对照基线。
2. 主链路故障测试
在获得授权且具备回滚方案的测试环境中，模拟接口中断、上游不可达或链路质量恶化等故障，记录设备从发现异常到触发切换的时间。
3. 转发恢复测试
验证备用链路是否真正承载流量，并测试 DNS、TCP 连接、关键业务端口及实际应用访问。
4. 会话连续性测试
分别观察已有 TCP 会话和新建 TCP 会话的表现，确认原有连接是否保留、哪些业务需要重连，以及 NAT 或防火墙状态是否符合预期。
5. 主链路恢复测试
验证主链路恢复后是否存在频繁回切，检查恢复阈值、防抖策略和业务连接是否再次受到影响。
测试时建议分别记录以下时间点：
- T0：主链路开始异常。
- T1：设备检测到故障。
- T2：设备执行切换。
- T3：备用链路开始正常转发。
- T4：新建业务连接成功。
- T5：原有业务会话恢复，或确认需要重新建立。
由此可以计算检测耗时、切换耗时、新连接恢复耗时，以及业务最终恢复所需的时间。
需要注意，原有 TCP 连接如果已经失效，T5 可能对应的是应用重新建立连接，而不是原连接本身恢复。验收报告应将两种情况分别记录，避免将重新连接误认为会话无损恢复。
八、如何优化，才能缩短主备切换后的业务中断？
优化应针对实际瓶颈展开，而不是单纯追求更短的探测周期。
第一，完善分层检测机制。 结合接口、网关、隧道和关键业务目标进行探测，避免仅凭接口在线状态判断网络正常。
第二，合理设置故障与恢复阈值。 根据链路波动情况和业务要求调整探测周期、失败次数及防抖策略，并通过测试验证误切换率与检测耗时。
第三，优化路由和隧道切换。 检查路由优先级、策略匹配和转发表更新过程，减少检测成功后到实际转发恢复之间的额外延迟。
第四，评估会话保持能力。 如果业务要求尽量维持已有连接，需要评估主备出口地址是否一致、NAT 映射是否可延续、连接跟踪是否支持同步，以及实际部署是否满足这些条件。
第五，完善应用重连机制。 对于无法避免的连接重建，应合理设置超时、重试和重连逻辑。关键业务还需要考虑请求幂等、任务恢复和数据一致性。
第六，建立切换监控与告警。 除了监控主备状态，还应记录切换次数、检测耗时、路由收敛时间、新建连接成功率和业务恢复时间。若链路频繁切换，应进一步分析底层质量，而不是只提高切换频率。
九、总结
SD-WAN 主备切换后仍然断网，通常不是单一原因造成的，而是故障检测、切换决策、路由更新、连接状态和应用恢复等多个环节共同作用的结果。
排查时应重点区分三个问题：
- 链路是否已经切换？ 关注故障检测、策略判断和转发路径。
- 新的连接是否可以建立？ 关注路由、NAT、DNS、安全策略和双向可达性。
- 原有连接能否继续使用？ 关注出口地址、会话状态、TCP 超时和应用重连机制。
只有把这三个问题分开验证，才能准确判断中断发生在哪个阶段。
对于企业网络而言，真正有效的主备设计，不只是故障发生后能够切换到另一条链路，更需要明确切换时间、业务恢复时间和已有会话的连续性边界，并通过可重复的故障演练验证设计是否满足业务要求。