最近家里发生了一次很朴素的网络事故：一条入户光纤物理损坏，网络因此长时间不可用。
真正让我重新思考的，不是光纤为什么会坏，而是另一个反直觉事实：家里明明接入了不止一条宽带，故障时却没有自动获得连续网络。
这次事故让我把一个常见误区说得更直白：线路数量只是资源清单；容灾能力来自独立故障域、主动探测、路由策略和真实切换验收。 多装一条线，不会自动补齐后面四件事。
负载均衡和故障切换不是同一个目标
多 WAN 常被一句“叠加带宽”概括，但它至少包含两个不同目标：
- 负载均衡：在多条健康线路之间分配新连接，提高总吞吐或分散拥塞；
- 故障切换：当主线路不可用时，把符合策略的新流量转到备用线路。
前者关注“都正常时怎么分”，后者关注“有一条坏了时怎么活”。如果只配置了多拨、不同出口或静态路由，却没有健康检查与失效策略，系统可能有多条线路，仍只会沿一条已经失效的路径发送流量。
OpenWrt 的多 WAN 文档也把物理、独立的 WAN 连接作为主要使用场景，并要求至少有两个 WAN 接口才有实际意义。[1] 但“接口数量够了”只是入口条件，不是容灾完成证明。
第一层：线路是否真的属于不同故障域
表面上来自不同套餐、不同拨号或不同运营商的线路，仍可能共享某些单点：
- 同一根入户管道或同一段室外光缆；
- 同一个光猫、交换机、电源或插座；
- 同一台主路由器；
- 同一条内部网线、VLAN 或上联端口；
- 同一个 DNS、隧道或远端中继。
这并不意味着每个部件都要双份，而是要先回答：我们准备防哪一种故障？如果目标是防运营商故障，独立运营商可能有用；如果目标是防入户光纤被切断，那么线路是否走不同物理路径更关键；如果主路由器断电，外面有再多线路也无法完成切换。
所以我现在会先画故障域，而不是先数宽带：入户路径、终端设备、供电、主路由、内部交换、DNS 和远端服务分别有哪些共享点。
第二层：接口“连着”不等于互联网可用
只检查网口 carrier 或拨号状态，会漏掉一种常见故障：本地链路仍显示连接，但上游已经黑洞、DNS 失效或远端路径不可达。
可靠的健康检查至少要能区分：
- 本地物理接口是否存在；
- 能否到达下一跳网关；
- 能否通过该 WAN 到达多个稳定的外部目标；
- 关键业务依赖是否可达。
OpenWrt mwan3 的接口配置中，track_ip 用于测试接口是否仍然存活；如果没有配置跟踪目标，接口会一直被视为在线。文档还提供 reliability、up、down、超时、检测间隔、丢包与延迟阈值。[1]
这说明健康不是一个瞬时布尔值，而是一段时间里的证据。阈值太敏感会频繁误切，太迟钝又会让用户长时间卡在坏线路上。
第三层：探测目标不能只有一个
如果只 ping 一个公共地址，对方临时丢包就可能把健康线路误判为故障；如果只 ping 网关，上游已经断网时又可能仍然显示正常。
更稳妥的办法，是在每条 WAN 上选择少量、稳定、来源不同的探测目标，并定义“至少几个成功才算在线”。OpenWrt 文档中的 reliability 就表达了这种门槛；当前实现还支持 ping、arping、httping、nping 和 DNS 查询等跟踪方式。[1][2]
目标并非越多越好。过多探测会制造噪声，也可能把某个公共服务的限流误当成线路故障。我的原则是：足以排除单目标偶发失败，同时保持频率和外部负担克制。
第四层：切换策略要覆盖真正的流量
即使健康检查正确，路由策略仍可能只覆盖一部分流量。至少要分别检查：
- 普通局域网客户端的 IPv4；
- 路由器自身发起的请求；
- IPv6；
- 需要固定出口的银行、支付或企业服务；
- VPN、反向隧道和远程管理；
- DNS 请求实际走哪条线路。
OpenWrt 当前文档特别提醒，IPv6 的负载均衡和故障切换需要额外配置，不能因为 IPv4 切换成功就推定 IPv6 同样成立。[1]
另外，故障切换通常只能让新连接改走备用出口。已经建立的 TCP、TLS、视频或登录会话可能因为公网地址变化而中断，需要应用重连。所谓“无感切换”必须由真实客户端、真实业务会话和真实故障注入证明，不能只看路由表。
我会怎样验收一套多 WAN 容灾
当前我还没有把这次事故直接变成生产网络改造。原因很简单：主路由和默认出口影响所有设备，不能在家人正在使用网络时边试边改。
真正实施前，我会先在隔离环境准备等价配置、自动回滚和一步式人工恢复，再按下面的顺序验收：
- 拔掉主 WAN 网线：验证物理 down 能否触发切换；
- 保持接口 up，但阻断上游：验证黑洞故障能否被主动探测发现；
- 让一个探测目标失败：验证不会因单点误报频繁切换；
- 恢复主线路：验证回切是否抖动、是否影响现有连接；
- 分别测试 IPv4、IPv6、DNS、路由器自身流量和局域网客户端；
- 持续播放视频、保持远程会话并发送消息：记录哪些业务会自动恢复，哪些需要重连；
- 断电或重启主路由：确认这是否仍是未覆盖的单点，而不是假装所有故障都已解决。
每一步都要记录检测时间、切换时间、恢复时间和失败业务。这样得到的不是一张“多 WAN 已启用”截图，而是一份真实可用的故障矩阵。
不要照抄旧教程
多 WAN 配置高度依赖 OpenWrt 版本、防火墙后端、IPv6 方式、策略路由和现有插件。当前 OpenWrt Wiki 的 mwan3 页面也明确区分 iptables 与 nftables 路径，并对不同版本给出适用性提醒。[1]
因此，本文故意不提供一份“复制就能用”的配置。先核对当前系统版本和防火墙实现，再选择对应方案；否则一篇旧教程即使曾经成功，也不能证明今天这台路由器安全可复现。
适用边界
这套方法适合家庭、小型工作室和一人公司的多出口设计。它能提高互联网出口的可用性，但不能替代双路由、双电源、独立交换路径或远端服务容灾。你防的是哪类故障，决定了需要做到哪一层。
这次物理断线给我的教训不是“再装一条宽带”，而是：先把共同故障点画出来，再让系统主动识别故障，最后用真实断线证明它会切换。 数量是输入，经过验收的恢复路径才是容灾。
本文来自一次真实家庭网络故障与后续方案复盘，使用 AI 辅助结构化和校对；运营商数量、地址、设备身份、网络拓扑、配置与远程入口已移除。当前只形成设计与验收方法，不宣称生产网络改造已经完成。
来源与核验
- OpenWrt Wiki：mwan3 多 WAN 文档（核验于 2026-08-31；实际采用前需按当前版本与防火墙后端复核）
- OpenWrt 官方 packages 仓库：mwan3track 实现（核验于 2026-08-31）
