ISP选路详解：多WAN出口智能调度与策略路由实战

1. 先从最容易踩坑的一句话说起

有一天同事甩过来一张报错截图，屏幕中央就一句话：选路连接失败，可能当前连接网络异常，请稍后重试。再往下翻日志，满屏都是“ISP”相关字段。他很认真地问我：是不是运营商把我宽带限速了？我当时就乐了，这里的“选路”跟运营商关系不大，真正干活的其实是自己家里的路由器、公司出口网关或者云上的一个网络节点，它要在两条甚至更多条宽带出口之间，替每一股流量选一条“最划算”的路送出去。

先把口径统一掉。在网络语境下，ISP 的完整拼写是 Internet Service Provider，也就是互联网服务提供商。ISP 选路，通俗点讲就是“多运营商宽带接入时的出口路径调度”。家里只有一条宽带，通常遇不到这个问题；但公司、学校、商场、机房，基本都会同时拉两条以上的宽带：可能是一条运营商专线用来跑关键业务，另一条带宽大价格便宜的线路用来缓冲峰值流量；也可能是因为机房本身需要双线路备份，一条断了另一条马上顶上。

这篇文章会把 ISP 选路从“概念 → 原理 → 配置 → 排错”整个链条完整捋一遍，最后还会专门回应一个特别容易把人带偏的问题：你在搜索引擎里敲“ISP”三个字母，经常会看到 ISP Pipeline、ISP 算法、Jetson ISP、GD32 ISP 例程这些关键词，它们跟网络里的 ISP 选路并不是同一回事，而是图像信号处理器领域的术语。为了不让你继续在资料海里绕弯子，我会在文末把它们解释清楚。

这篇文章适合谁看？企业网络管理员、IDC 运维、软路由玩家、双 WAN 或多 WAN 设备用户，以及那些只是被一句“选路连接失败”逼到抓狂，想搞清楚背后到底发生了什么的人。

2. ISP 选路到底“选”的是什么？

2.1 核心定义：给每一股流量挑一扇出门的“门”

如果你把互联网想象成一个巨大的城市交通网，路由器就是各个路口的交警。单线宽带场景下，你家小区只有一个出入口，所有车都从同一个门进进出出，交警不需要做任何选择，一条路走到底就行。可当小区突然开了东南西北四个门，每个门出去后遇到的堵车情况不一样、通往不同方向的便利程度也不一样，这就麻烦了，交警必须在每辆车出发前判断出，到底把车指向哪个门最合适。

ISP 选路做的正是这件事。它会为每一个数据包或者每一条连接会话，决定“从哪条上行链路出去”。这里的“选”不是随便轮着来，而是基于一组客观条件：

• 目标 IP 属于哪个运营商地址段；
• 目标地址段跟当前哪条上行链路“互联质量最好”；
• 当前几条链路的延迟、丢包、带宽占用情况；
• 应用类型对延迟和抖动是否敏感；
• 某条主链路是否已经断线或出现严重劣化。

一句话总结，ISP 选路是在“多条互联网出口同时可用”的前提下，用策略把流量分派到最合适那条链路，并在链路异常时自动切换。它不是运营商的服务，而是你自己出口网关上的一个本地决策功能。

2.2 它和普通路由有什么区别？

有人可能会问：路由器本来不就在选路吗？它每天都在查路由表、匹配目标网段、决定下一跳是谁，这不也是选路吗？

确实，这种广义的“查表找下一跳”也可以叫选路。但绝大多数单线网络里，你只有一条默认路由，也就是 0.0.0.0/0 指向唯一出口。这就相当于所有流量都只有一扇门可以走，路由器再怎么选，结果都一样。

ISP 选路却是完全不同的玩法。它强调的是“策略化”“差异化”的转发，管理的是多条“默认级别”的线路。常见的分流维度包括：

• 按目标 IP 地址段分流：流量去往 A 运营商的已知地址段，就优先走 A 运营商线路，尽可能避免跨运营商绕路。
• 按源 IP 或源端口分流：办公网段走稳定专线，访客 Wi-Fi 网段走普通宽带。
• 按应用类型分流：视频会议、VoIP 语音这些对延迟敏感的业务，固定走低延迟线路；大流量下载、视频缓存走大带宽线路。
• 按实时链路质量分流：对每条线路做持续探测，延迟超过阈值、丢包恶化、拨号断开时自动切换，业务做到尽量无感知。

所以，判断一台设备是不是真正支持 ISP 选路，不用看厂商宣传页上写了多少天花乱坠的形容词，直接翻后台设置里有没有“策略路由”“PBR”“多 WAN 负载均衡”“链路健康检查”这类选项就明白了。能同时做到“按条件分流”和“故障自动切换”，才算一个合格的 ISP 选路实现。

2.3 两个最典型的落地场景：多 WAN 网关与 SD-WAN

第一个场景是传统的多 WAN 网关 / 防火墙，多出现在企业出口。设备上 WAN1 接 A 运营商，WAN2 接 B 运营商，内部维护一张运营商地址段表，再配合策略路由和链路探测模块，实现流量分流和主备切换。很多企业级安全网关的后台里直接把这个功能叫“多 ISP 接入配置”，你搜“USG6000E 多 ISP 接入配置示例”看到的，基本都是这类设备的操作界面和配置思路。

第二个场景是 SD-WAN 边缘设备。可以把它理解为 ISP 选路的“进阶版”。SD-WAN 不光看目标地址段，它还会实时采集每条链路的延迟、抖动、丢包，甚至根据应用 SLA 要求，在链路质量不达标时自动把流量调度到另一条路径上。从“按地址段选路”到“按实时质量选路”，这中间跨越的复杂度不是一星半点。

这也是为什么很多刚接触网络的人会把“ISP 选路”和“SD-WAN 智能选路”混在一起搜。两者解决的问题高度重叠，区别只在于策略的维度和动态化程度。理解传统 ISP 选路，是读懂 SD-WAN 的地基。

3. 为什么需要 ISP 选路：单线、双线与成本的三笔账

3.1 单条链路靠不住，多出口是刚需

先把最朴素的理由摆出来：单条宽带线路太容易“出事”了。运营商线路可能因为市政施工被挖断，电费欠缴被停机，光模块老化导致光衰过大，甚至一个区域性的路由抖动就能让你内外网全部瘫痪。

对家庭用户来说，断网最多忍一晚上。但对公司、医院、学校、机场这类场所，断网意味着收银台停摆、挂号系统打不开、线上考试中断，每一分钟都是真金白银的损失。于是很多网络设计会直接拉两条不同运营商的宽带，形成物理级的冗余。一条断了，另一条顶上，网络不中断。可两条线路都在的时候，流量到底走哪条？总不能一条空着一条堵死，这时候就需要 ISP 选路来分配。

3.2 跨运营商互联，是很多人忽略的隐形延迟

你可能有过这种体验：同一台服务器，办公室 A 运营商宽带访问飞快，办公室 B 运营商宽带却卡成 PPT。原因很简单，两个不同运营商之间的网络互联带宽和路由绕行情况差异很大。同网访问速度最快，跨网访问往往会绕经互联网交换节点，延迟、丢包率都会明显升高。

ISP 选路一个很务实的用法，就是维护一张“运营商地址段表”。当终端要访问的目标 IP 属于 A 运营商的地址段，就让流量走 A 运营商线路出去；属于 B 运营商地址段，就走 B 运营商线路。尽量让流量“同网直达”，减少跨网绕行带来的额外延迟。这在游戏加速、语音通话、视频会议这类对延迟极其敏感的场景里，体验差异会非常直观。

3.3 专线和便宜宽带混用，把每一分钱花在刀刃上

企业在网络预算上通常是很算计的。一条固定 IP 的商务专线价格是普通家宽的好几倍，但专线胜在带宽稳定、上行大、有公网 IP。更常见的设计是：专线只承载关键业务，比如 ERP、OA、视频会议、远程办公；价格便宜的普通宽带则承担视频下载、软件更新、员工刷网页看视频这类“非关键流量”。

这种“好钢用在刀刃上”的组网方式，也必须靠策略路由来实现。你不能指望员工的浏览流量和核心系统流量挤在同一条专线上，那专线再宽也顶不住。你也不希望大流量下载把便宜宽带跑死以后，自动溢流到专线上去。把流量按业务价值划分到不同成本等级的出口链路，才是企业多线组网的真实图景。

3.4 业务隔离与合规需求，是常被忽略的第四类理由

ISP 选路还经常承担“安全隔离”的职能。比如一个商场，办公网和公共访客 Wi-Fi 从物理或逻辑上分开，访客流量统一走某条独立出口，即使访客区中了木马或者产生大量恶意流量，也不会冲击办公专线。再比如某些行业要求特定业务必须从固定 IP 段出网，外部系统通过白名单方式放行，那就必须把该业务的流量死死钉在具备那个固定 IP 的链路上。

这些需求表面看都是“给流量选路”，但驱动因素已经不单是性能或成本，而是安全策略和合规要求。所以我一直觉得，ISP 选路不只是一个技术功能，它本质上是一个“业务流量怎么走”的策略表达工具。

4. 核心技术原理拆分：地址表、策略路由与会话保持

4.1 运营商地址段表：选路的“第一把尺子”

ISP 选路一个最常用的依据，就是目标 IP 所属的运营商。想要做到“同网流量走同网出口”，设备必须知道“哪些 IP 地址段属于 A 运营商，哪些属于 B 运营商”。设备里内置或被管理员手动导入的这张表，就是运营商地址段表，也叫 ISP 地址库。

这张表是怎么回事呢？各大运营商都有自己申请到的 IP 地址块，比如某运营商可能持有若干个 /8、/12、/16 级别的地址段。这些地址段会被整理成了一张巨大的 IP 前缀列表。路由器在收到一个数据包后，先提取目标 IP，再拿它在地址表里做最长匹配，命中哪个运营商的地址范围，就准备从对应的出口链路转发。

这里有一个很关键的工程细节：地址表不是一成不变的。运营商会不定期调整 IP 段，所以你设备里内置的 ISP 地址库需要定期更新。我就见过不少项目，设备买回来以后三四年没更新过地址库，导致流量匹配偏差，明明有双线分流功能，实际效果却和单线差不多。建议把它放进周期性维护清单里，至少每个季度同步一次。

4.2 策略路由：比静态默认路由更聪明的“路线图”

策略路由，英文缩写 PBR，是 ISP 选路最核心的执行机制。普通路由表只会告诉你“目标网段怎么走”，策略路由却可以基于更多条件做判断，比如：

• 源 IP 是谁？来自办公网还是访客网？
• 目标 IP 是谁？访问的是哪个外部服务？
• 应用类型是什么？是 HTTP、VoIP 还是视频流？

设备内部通常会有多张路由表。默认路由在“主表”里，策略路由负责把符合特定条件的流量“引到”另一张路由表去查找出口。举个例子，管理员可以定义一条策略：所有来自 192.168.10.0/24 网段的流量，在下发匹配时直接查“ISP-A 出口表”；所有来自 10.20.0.0/16 网段的流量，则查“ISP-B 出口表”。这就是一张比默认路由精细得多的“路线图”。

实现策略路由的工程方式各家设备略有不同，但底层逻辑高度一致：先分类流量，再打上转发标记，最后走指定的下一跳或出接口。掌握了这套模型，换任何品牌的设备，上手速度都很快。

4.3 连接跟踪与会话保持：选路不能篡改“正在聊的天”

ISP 选路在实操中有一个特别容易被忽视的问题：连接状态。TCP 连接是讲究“一来一回”的，比如你打开一个网页，浏览器发出请求，服务器返回数据，这一来一回组成一条完整会话。如果设备在一开始把请求从 WAN1 送出去，几秒钟后返回的数据却因为策略变化被设备从 WAN2 送回来，很多服务就会立刻报错，表现就是网页打不开、视频加载失败、登录状态异常。

所以，真正完善的多 WAN 网关都带连接跟踪功能。它会记录一条会话“首次走了哪个出口”，后续属于同一条会话的所有数据包，哪怕策略规则此时已经变成“应该走另一条线”，设备也会强制让这条会话继续走原出口，直到会话结束。这个机制叫会话保持，也称粘性路由。

在实际配置中，一旦你要调整 ISP 选路策略，比如新增一条“视频流量走 WAN2”的规则，老会话大概率还是按旧规则走。不要急着说规则没生效，等旧会话超时重连后再测试，通常新策略就会正常表现。我自己在测试时，习惯改完策略直接等 30 秒，或者干脆重启一下客户端进程，让会话重新建立，能得到最干净的验证结果。

4.4 链路健康检查与自动切换：选路的前置条件是“活着”

把流量切到一条已经断掉的线路上，等于把车送进死胡同。所以链路健康检查是所有 ISP 选路方案里的“守门员”。

常见做法是让设备周期性地向某个探测目标发送探测报文。探测目标通常是对端运营商的网关地址，或者一个长期稳定可达的公网 IP。设备如果连续几次没收到回应，就判定该链路故障，然后把原本指向这条链路的流量，自动切换到另一条健康链路上。

这里有两个参数要重点调：探测间隔和失败判定次数。间隔太短，可能会因为网络瞬时抖动产生误判，把好线路也切走；间隔太长，故障响应又太慢，业务已经受影响了几十秒。我常用的经验值是：探测间隔 3 到 5 秒，连续 3 次失败才判定宕机，这样既能较快感知故障，又能过滤掉绝大多数瞬时抖动。至于探测目标，建议选两个不同运营商且长期稳定的公共 DNS 或大型门户的 IP，避免单个目标不可达导致误切。

4.5 负载均衡算法：多条链路同时跑，而不是一条忙死一条闲死

ISP 选路除了“按策略分”，还有一个朴素需求：让多条线路“雨露均沾”。这就涉及负载均衡算法。常见的实现方式有这么几种：

• 基于源地址哈希：对源 IP 做哈希计算，结果映射到 WAN1 或 WAN2。优点是同一个来源 IP 的流量始终走同一条链路，会话稳定；缺点是流量分配不是绝对均匀。
• 基于会话轮询：每来一条新会话，就按顺序轮流分配给不同出口。实现简单，但遇到重流量会话时会失衡。
• 加权负载均衡：给每条链路配置一个权重值，比如 100M 专线权重 3，500M 普通宽带权重 7，流量按权重比例分摊。这在多条链路带宽不等时非常实用。
• 动态链路质量负载：设备实时探测两条链路的延迟、丢包和带宽占用率，把新流量引导到质量更好的那一条上。

选择哪种算法，取决于你更看重“会话稳定”还是“带宽利用最大化”。我的建议是：没有特殊要求时，同运营商双线用按会话轮询即可；不同运营商、不同带宽，用加权负载均衡，并配合策略路由把关键业务钉在质量高的那条主线上。

5. 实操：手把手配一套 ISP 选路方案

5.1 先把自己的“流量地图”画出来

不管用什么品牌的设备，配置 ISP 选路的第一步都不是点鼠标，而是整理一张“流量地图”。拿一张纸或者一个表格，把下面几项写清楚：

• 有哪几条 WAN 线路？分别接在哪个物理接口？网关地址多少？带宽多少？
• 哪些网段是办公网、哪些是访客网、哪些是服务器网？
• 哪些业务要走专线？哪些业务可以走便宜宽带？
• 如果你知道目标服务的 IP 地址或者端口，把它们列出来。

这张表是你后续所有规则设计的基础。跳过这一步直接上设备敲命令，大概率会出现“配了策略但流量没按预期走”“两条链路互相打架”等后续问题。

5.2 配置逻辑：分类 → 绑定出口 → 兜底 → 探测

以一台典型的多 WAN 企业网关为例，逻辑上可以拆成四个环节：

第一步，定义 ISP 地址组。设备管理后台一般都有“ISP 地址池”或者“地址组”功能。把 A 运营商的 IP 段加入 ISP_A 组，B 运营商的 IP 段加入 ISP_B 组。如果不知道具体地址段，大多数设备支持从云端同步最新地址表。

第二步，定义访问控制列表或者流量分类器。根据你整理的流量地图，把需要特殊处理的流量选出来。例如：

• 来自 192.168.10.0/24 的访客流量 → 走 WAN2 便宜宽带；
• 目标 IP 属于 ISP_A 组 → 走 WAN1；
• 目标 IP 属于 ISP_B 组 → 走 WAN2；
• 来自 192.168.20.0/24 的语音会议业务 → 固定走 WAN1。

第三步，创建策略路由并指定动作。策略路由的动作一般是“下一跳指向某 WAN 接口”或者“路由表查表”。一条策略可以简单理解成：“如果数据包满足我分类出来的条件，就把它的出口指定为 WAN1 / WAN2”。策略顺序很重要，设备一般从上往下匹配，匹配到第一条就不再看后面的规则，所以越具体的规则越要靠前。

第四步，设置默认出口和链路健康检查。所有没有命中专项策略的流量，走默认路由。默认路由建议指向质量更稳定线路上，比如专线。然后开启链路健康检查，配置探测间隔、失败阈值和自动切换。有些设备会允许你设置“主备模式”还是“负载均衡模式”，根据实际需求选择。

5.3 一段可以“抄作业”的参考配置

具体命令因设备品牌差异很大，我只给一个跨设备通用的参考模板，逻辑优先级从高到低排列：

code复制# 逻辑上做流量分类
分类1：匹配目标IP在ISP_A地址组内的流量
分类2：匹配目标IP在ISP_B地址组内的流量
分类3：匹配源IP为访客网段(192.168.10.0/24)的流量
分类4：匹配源IP为办公网段且目标端口为 5060/10000-20000 的语音流量

# 建立策略路由
策略节点10：分类3     -> 出口绑定 WAN2（便宜宽带）
策略节点20：分类4     -> 出口绑定 WAN1（专线）
策略节点30：分类1     -> 出口绑定 WAN1
策略节点40：分类2     -> 出口绑定 WAN2
策略节点50：其余流量   -> 查默认路由表

# 默认出口：WAN1 专线
ip route 0.0.0.0/0 下一跳=WAN1网关

# 链路探测与切换：每3秒探测一次，连续3次失败判宕机
探测目标1 为 WAN1 网关，频率 3秒，失败3次触发切换
探测目标2 为 WAN2 网关，频率 3秒，失败3次触发切换

看到这个模板，你是不是已经察觉出 ISP 选路的全貌了？它不神秘，就是一个“匹配条件 + 指定出口”的组合，加上一把“链路健康锁”，再配一个默认出口兜底。把所有业务流量按优先级排好队，让设备按队列一张一张放行，就这么简单。

5.4 配置中最容易翻车的三个细节

细节一：策略路由的“方向”。策略路由有的基于入接口执行，有的基于转发流程全局执行。如果你发现策略条件写得很完美却不生效，先检查是不是忘了把它应用到 LAN 侧的入接口方向。

细节二：NAT 和 PAT 的联动。多 WAN 设备通常还承担 NAT 功能。流量走了 WAN2 出口，源地址就要被转换成 WAN2 接口上的 IP。有些设备如果不单独配置 NAT 对应关系，会导致出网流量有去无回。配置策略路由的同时，一定记得检查每条出口是否都有对应的 NAT 规则或接口 NAT 开关。

细节三：回程路由。如果你的出口设备后面还接了核心交换机、路由器或者防火墙，它们发出的回程流量也要能正确回到这台多 WAN 网关上。否则就会出现“请求发出了，回包却走丢”的问题。分组网设备多了以后，这种问题最容易藏得深。

6. 常见问题与排查实录：选路失败到底是怎么来的？

6.1 “选路连接失败，可能当前连接网络异常”的真相

回到文章开头那个报错。这句话本身很可能来自某个软件客户端或设备后台管理系统，而不是设备故障日志的原话。它的背后通常是这样一条链路：客户端通过某条业务链路尝试连接远程服务 → 设备策略把流量引到了某条出口 → 该出口此时不可用或者链路质量太差 → 连接握手超时 → 客户端弹窗报错。

排查思路可以按照这个顺序来：

1. 先看物理链路。对应出口的光猫、光模块指示灯是否正常，接口是否有大量错包、CRC 错误。
2. 再看探测结果。打开设备的管理后台，找到 WAN 链路状态页，看是不是已经把某条链路标识为“故障”或“降级”。如果探测目标被标记为宕机，马上验证探测目标是否还可达，别把好线路误判成坏的。
3. 接着看会话表。如果连接失败的是某条具体业务，比如一台服务器访问外部接口失败，去查设备的会话表或日志，确认数据包到底从哪个出口发出去了。很多“选路失败”的根源是策略指向了一个已经不通的出口。
4. 最后查策略优先级。有时候一条新加的策略顺序不对，把本来应该走专线的关键流量顶到了普通宽带上，普通宽带的 DNS 解析正常但大包传输受限，就会出现“看起来没断网，但就是连不上”的状况。

6.2 典型问题速查表

这张表里的每一条，我都在真实项目里踩过。尤其是“会话保持”和“策略顺序”这两条，是最容易让人怀疑人生的。有时候你会把设备设置翻来覆去看了十遍，看不出任何问题，结果就是一条策略顺序错了，把访客流量顶到了专线上，专线带宽被打满，所有业务一起跟着遭殃。

6.3 排错时最好用的两个命令思路

现在很多设备都提供命令行或者诊断工具，强烈建议做两件事：

一是查看接口下的瞬时流量和错包计数。 display interface 或者对应平台的 ip -s link，重点看 input errors、output errors、CRC errors。如果一个接口的 CRC 错包数量持续上涨，基本可以断定是物理链路或光模块问题，先换线换模块，再谈策略。

二是跟踪数据包实际转发路径。设备自带 tracert 或 traceroute，从设备本身发起到目标服务的追踪，可以判断数据到底从哪个出口出去、在哪一跳丢包。再加上策略路由的调试命令，比如查看命中计数，就能定位到“流量被哪条策略匹配到了、出口是否合理”。

记住一条原则：先把故障定位到“物理层还是链路层还是策略层”，再动手改配置。永远不要在链路层故障还没排除时，就去重写策略路由，只会越改越乱。

7. 另一个“ISP”：图像信号处理器，别搞混了

搜索引擎上有一个很有意思的现象：输入 ISP 选路，关联结果里经常混入 ISP Pipeline、ISP 算法、Jetson ISP、GD32 ISP 例程、CW32 ISP 这些内容。新手看到第一反应往往是：难道这些都是同一个东西？不是的，这里的 ISP 是 Image Signal Processor，图像信号处理器。

图像信号处理领域的 ISP，是一块专门处理摄像头原始数据的芯片或算法模块。它的职责是，把感光元件输出的原始 Bayer 数据，经过一系列信号处理步骤，最终转换成我们能直接预览、存储、传输的彩色图像。这条处理链路在业内叫 ISP Pipeline，典型环节包括：

• 黑电平校正：消除传感器暗电流造成的底噪；
• 镜头阴影校正：校正镜头边缘进光量不足导致四角偏暗；
• 坏点校正：补偿传感器上损坏的像素点；
• 降噪：减少高感光度下产生的噪点；
• 去马赛克：从每个像素只有一种颜色的 RAW 图还原出 RGB 彩色图像；
• 白平衡：让白色物体在不同光源下看起来仍然是白色；
• 色彩校正矩阵：校正传感器和实际人眼感知之间的色彩偏差；
• 伽马校正：调整亮度曲线，让图像更符合人眼对比度感知；
• 色调映射和边缘增强：提升细节表现；
• 缩放和格式转换：输出 YUV 或 JPEG 格式供上层使用。

如果你手上正好有热门开发板，比如 Jetson 平台，或者 Zynq 平台，看到的 ISP 章节讲的全是这些内容。那图像处理里有“选路”吗？严格来说没有叫“ISP 选路”的标准术语，但可以从两个角度理解：

一种是把每个图像处理环节看作一条“流水线”，数据从 sensor 进，按固定顺序经过多个算法模块，最后出图。这里的“顺序”就有点像选路：先做降噪还是先做去马赛克，不同算法顺序会导致完全不同的画质表现。

另一种是在多摄像头方案中，SoC 的 ISP 硬件资源通常只有一两路，但摄像头可能接了四五个。系统需要根据当前活跃的摄像头，把数据流“选路”到 ISP 对应通道上。从这个角度讲，它也的确存在“选路”动作。

所以，如果你搜 ISP 选路，却点进了一篇讲 ISP Pipeline 的技术博客，不用怀疑自己的眼睛，这俩只是撞了同一个缩写的词而已。网络里的 ISP 选路管的是流量去哪条宽带，图像处理里的 ISP 管线管的是像素怎么变成图。搞清楚这点，再回头看那些热搜词，就不会继续打转。

8. 写在最后的一点个人体会

我接触多 WAN 组网这些年，最大的感受是：ISP 选路这个功能，看似简单，真正做好的关键反而不在设备上，而在你对“业务流量”的理解里。你得知道自己哪些业务绝不能断，哪些流量可以容忍波动，哪条链路是你最该守住的底线。技术规则只是把这些业务优先级翻译成设备策略，翻译得越准确，网络跑得就越顺。

如果只让我留一句经验给后面的人，那就是：永远别一次性堆几十条策略。先保证默认路由、NAT、链路探测这三个基础项全部正常，再一条一条加分流规则，每加一条立刻验证。稳扎稳打，比什么都重要。

另外一个小技巧：链路健康检查的探测目标，除了运营商网关，再额外选一两个你业务真正依赖的公共目标，比如你常用视频会议服务器的官网 IP。因为运营商网关通，不代表到业务侧的路就是通的。两条腿走路，故障感知才更贴近真实体验。