两条出口线还是不通：多宿主网络的故障收敛和回程路径查什么

两条出口都接了，两条运营商的光都进了机房，路由也做了主备或者负载分担。结果真出事那天，一条线断了，业务还是卡了十几分钟才缓过来，最气人的是监控大屏上一片绿——链路状态显示正常，BGP 会话显示 established，告警一条都没触发。事后复盘，谁也说不清这十几分钟到底耗在哪。

这类事我见过太多次了。链路确实是正常的，问题是它坏的方式，压根不在你的检测范围里。你盯着的是"线有没有断"，而真正要命的故障是"线没断，但已经不转发了"。这两件事在监控图上长得一模一样，在业务上差着十几分钟。

先把结论摆在这里，后面逐条拆：

一、"两条线"只冗余了物理路径和会话，没有冗余"故障被发现的速度"。你的第二条路一直都在，但没人告诉设备该走了，它就不会走。

二、最贵的那段时间，花在"检测"上，不是花在"切换"上。真正把流量挪到备用出口，设备干活的时间很短；等它意识到该挪了，可能已经过去一两分钟甚至更久。

三、接口 down 是最容易发现的故障，也是最不容易发生的那个。现实中大量的中断，光模块还在亮，会话还在握手，包就是过不去。

四、切出去不等于能回来。你只能决定流量往哪走，回来的路是对方网络选的。回程不对称在有状态设备面前，等于又造了一次故障。

五、切换时间 = max(路由收敛, DNS 生效, 客户端重试)。路由再快，TTL 是十分钟、客户端还攥着旧解析结果，用户感知到的 downtime 还是十分钟。

"两条线"到底冗余了什么，哪部分压根没冗余

很多人买多宿主的时候，脑子里的模型是这样的：我有两条路，一条断了走另一条，所以可用性翻倍。这个模型只对一半，而且对的那一半还是比较容易实现的那一半。

被冗余掉的部分

物理路径这一段是真的冗余了。光缆、光模块、上联端口、运营商的接入层设备，一处断了还有另一处。链路层 down 的时候，你的设备几乎立刻就知道了——接口状态变化是硬件中断触发的，感知速度在毫秒量级，快到你可以认为它是瞬时的。

会话层也冗余了。两条 BGP 会话各自独立建立，一条会话掉了，另一条还在，路由表里有备选，转发层面不需要重新学习什么。

再往上，运营主体也冗余了。两家不同的运营商，各自有自己的城域网、骨干网、出口和国际链路，一家出问题，另一家同时出问题的概率确实低很多——前提是这两家在你这个机房里的物理路由真不一样，这个后面会说。

没被冗余掉的部分

没被冗余的，是三样东西。

第一样，故障的可见性。你的设备凭什么知道那条路坏了？接口 down 它知道，会话断它知道，但"链路还亮着、会话还握着手、中间某个设备已经开始丢包"，它不知道。而这一类恰恰是现网里最常见的中断形态：传输设备中间某段出问题但对端收光正常、上层设备的转发层面卡死但控制层面还活着、某个中间节点在静默丢包。这类故障的共同特征就是——控制平面一切正常，转发平面已经死了。

第二样，故障的传播时间。就算你的设备第一时间知道了，它还要把这条路由撤掉、重新通告、等上下游跟着收敛。这一段的耗时你控制不了，它取决于整个互联网的 BGP 收敛行为，而不是你机房里那台路由器的性能。

第三样，回程。这是最容易被漏掉的一块。你做出方向选路的决定，只解决了一半问题。对端怎么把包发回来，走哪条路回来，你说了不算。

所以"两条线"真正买到的是冗余的可能性，而不是冗余本身。把这个可能性变成实际的高可用，靠的是检测机制、收敛行为和回程一致性这三件事——这三件事全都不在"接几条线"这个动作里，全都在配置、验证和演练里。

故障检测的三个层次，最难的那层是"还活着但不转发"

把检测想成三层，很多问题一下就清楚了。

第一层：链路层，最快也最省心

接口 down、光模块收光丢失、链路协议 down。这一层是硬件直接告诉你的，中断触发，毫秒级。设备收到这个信号之后，关联的接口状态立刻变化，路由立刻重新计算，快到几乎不用你操心。

问题是，这一层只覆盖了"物理上彻底断掉"这一类故障。拔光纤它管，光衰到临界它管，但对端设备死机、传输网中间静默丢包、上联设备的转发引擎hang 住，它统统不管。你机房里那条线的指示灯照样是绿的。

第二层：协议层，慢，而且有盲区

链路没 down，那就靠协议来发现。BGP 靠的是 Keepalive 和 Hold timer：双方定期互发保活报文，如果超过 Hold 时间没收到对方的，就认为会话断了，拆会话、撤路由。

这个时间量级是什么概念？不同厂商、不同版本的默认值不一样，但基本都在几十秒到两三分钟这个区间里。也就是说，如果故障的形态是"对端整机没了"，你的设备可能要等一分多钟才开始动作。很多人以为 BGP 是秒级收敛的，那是建立在"有别的机制帮忙快速检测"的前提下，裸的 Keepalive/Hold 机制本身是很慢的——它的设计目标是稳定，不是快。协议作者宁可慢一点也不要误判，因为一次误判导致的路由震荡，比晚发现一分钟麻烦得多。

而协议层的盲区比慢更麻烦：对端设备还在、还在发 Keepalive、会话还是 established，但它的转发已经坏了。这种情况下，协议层永远不会告诉你出事了。它没出事，它好得很，它只是不干活了。

第三层：上层探测，最后一道防线

再往上就是你自己加的健康检查、ICMP 拨测、HTTP 探活、业务层的端到端检测。这一层的特点是能发现"真实现象"——它测的是"包到底过不过去"，而不是"协议状态好不好看"。

它的代价也明显：探测本身有间隔，太频繁会变成噪声甚至被当成攻击；探测路径未必覆盖所有业务流；探测点选在哪，直接决定它能发现什么。而且从检测到动作之间，还得有一套"探测失败 → 触发切换"的逻辑，如果这套逻辑是人手工执行的，那就又加了几分钟的人力响应时间。

三层合起来看，你会发现一个尴尬的事实：最容易发现的故障（链路 down）发生频率最低，最难发现的故障（静默不转发）发生频率最高。你的检测能力和故障分布是错位的。这就是为什么"两条线"接完之后，故障时长常常没有明显改善——你投入的钱买的是路径冗余，但你实际需要的那个能力（快速发现静默故障）一点都没买。

检测时间从哪来：几种手段的量级、前提和代价

既然检测是瓶颈，就得知道每种检测手段能压到多快、要付什么代价。下面这张表是我习惯用来跟客户对齐口径的，注意时间列全是量级，不是某个厂商的固定默认值——各家实现不一样，配置也不一样，具体数字必须以你自己的设备和配置为准。

这张表读下来，你只要记住一件事：从第二行往下往上是花钱买时间。链路层是白送的，协议层是默认的但很慢，BFD 是要专门配的，上层探测是要专门搭的。你不配 BFD，就默认接受"几十秒到两三分钟才被发现"这个现实。

BFD 到底解决了什么，又带来什么

BFD 存在的唯一理由，就是把"会话还活着但已经不转发"这类故障的检测时间，从几十秒压到亚秒级。它是一个极轻量的独立检测协议，跑在转发路径上，跟路由协议解耦，检测到失败就直接通知上层协议把会话拆掉。它测的是转发通路，不是协议状态，所以能抓到协议层看不见的那类故障。

代价也得讲清楚，别听谁一句"开了 BFD 就快了"就往上堆。

第一，两端必须都支持、都配置。你自己开了没用，对端不开就建立不起来。跟运营商对接的时候，这一条必须在商务阶段就谈清楚，别等上线了才发现对方不支持或者要走变更流程。

第二，参数要对齐。发送间隔、检测倍数，两端配置不一致的时候，协商结果可能不是你想要的那个值。

第三，越激进越容易误判。检测时间压到极短，意味着网络里一次轻微的抖动、一次 CPU 瞬时打满导致的报文延迟，都可能被判定为故障，触发不必要的切换。切换本身是有代价的，收敛过程中会有丢包，来回震荡比一次干净的切换难受得多。所以参数不是越小越好，是要跟你的链路质量匹配。

我的判断是：凡是承载业务的出口，BFD 值得开，尤其是中间穿了传输设备、不是直连的场景——因为一旦中间有传输设备，"对端接口 down"这个信号根本传不到你这里，你唯一能指望的就是 BFD 或者上层探测。但参数别照抄网上的样例，按你自己链路的实际抖动水平来调，调完要演练验证。

收敛不是切换：本机切过去了，全网还要多久

很多人把"收敛时间"理解成"我这台设备把流量切到备用出口的时间"。这个理解会让你严重低估故障时长。

本机这一跳其实很快

检测到故障、撤销失效路由、重新计算、把新的下一跳写进转发表——现代设备做这一套，通常是很快的，尤其是路由条目不多、下一跳已经预先算好的情况下。硬件转发表的下发也就在毫秒到亚秒这个量级。

如果你事先做好了备用路由（而且是真正装进了转发表的那种，不是只在路由表里躺着），本机这一段的耗时几乎可以忽略。

慢的是传播

真正的时间大头在后面：你的路由变化要通告出去，上游要收到、要重新计算、要更新自己的转发表，上游的上游也要这么做，一层层往外扩散。同时，别的网络得知这条路径不可达之后，会把流量重新选路，这些流量的新路径未必经过你预期的那条线。

互联网规模的 BGP 收敛，量级通常是分钟级，不是秒级。而且这里面有个很讨厌的特性：收敛过程本身会产生新的不稳定性。路由撤销和重新通告会在网络里引发连锁反应，某些节点可能会经历多次更新，期间出现短暂的不一致，表现为间歇性丢包或者路由环路。这也是为什么协议设计者普遍倾向于"慢一点但稳一点"——抖动的代价往往高于晚收敛的代价。

还有一类情况更被动：故障不在你这一侧，而在上游的某个位置。这时候你能做的只有等待和观察，你自己的设备和配置再优秀也影响不了对端的收敛行为。

所以"收敛时间"要拆成两个数来谈

跟服务商或者跟内部对齐口径的时候，别只问"收敛时间多少"，要拆开问：

本地收敛：从我这边检测到故障，到我这台设备把流量真正转发到备用出口，多长时间。这个数主要由你的检测机制决定，是可控的、可优化的部分。

端到端可达性恢复：从故障发生，到绝大多数外部用户能正常访问，多长时间。这个数包含了传播、包含了上游收敛、包含了 DNS 和客户端行为，是用户真正体验到的那个数。

两个数差得很远是正常的，差一个数量级也不奇怪。拿本地收敛时间去承诺用户体验，是这个行业里最常见的口径混淆。你问"多久能好"，对方答"亚秒级"，很可能他说的是本地切换，而你关心的是用户能不能打开页面。

回程路径：你只能决定出去，回来是别人选的

现在讲最常被漏掉的一块。

出方向和入方向是两回事

你的设备做出方向选路：根据路由表、策略路由、权重，决定这个包从哪个接口扔出去。这一步你完全可控。

但响应包怎么回来？由发起访问的那一侧的网络决定。对方的网络根据自己的路由表，选择到达你这段地址的最佳路径。你通告了两条路出去，对方可能两条都收到了，然后按自己的选路规则（常见的如 AS 路径长度、MED、本地偏好、甚至是对方的流量工程策略）挑一条。

这里就出现了那个反直觉的现象：你接了两条运营商，但某一方向上，两个方向的流量可能全压在同一条线上。出去走 A，回来也走 A；或者出去走 A，回来走 B。前一种情况意味着你买的那条 B 线在回程上完全没派上用场，后一种情况就是下面要说的非对称路由。

非对称路由怎么产生的

非对称本身在互联网上是常态，不是故障。BGP 的选路是逐跳独立决策的，去程和回程经过不同的路径，再正常不过。

问题出在你的网络里有有状态设备的时候。防火墙、NAT 网关、负载均衡、任何维护会话表的设备，都假设"一个会话的两个方向我都看得见"。请求从 A 口进来，响应从 B 口出去，那台只看得到 A 口的防火墙就懵了——它的会话表里没有这个连接的回程记录，或者记录状态对不上，于是按策略直接丢弃。

表现就是：单项测试能通，握手能建，业务就是时好时坏。或者是主链路正常的时候一切正常，一切换到备用出口，看起来路由都对，流量就是过不去。这种故障特别难查，因为你在任何一台设备上看到的都是"配置没问题"。

还有一种更隐蔽的：运营商侧启用了反向路径校验（uRPF 那一类机制），你从"不符合预期"的接口发出去的包，在对方那里直接被丢。这也是接口不 down、会话不断、包就是没了。

怎么判断是不是回程不对称

给你几个按顺序走的抓手，不用一上来就抓包。

看会话表。在有状态设备上直接查会话，看这个五元组的会话是从哪个接口建的、回程记录在哪个接口上。如果只有单向记录，或者两个方向的接口对不上，基本就坐实了。

对比出入接口计数。在出口设备上，对比两条线的入向和出向流量。如果一条线只有出、另一条线只有入，而且比例明显失衡，那就是典型的不对称。

双向抓包/双向 traceroute。从你这边往对端 traceroute，再让对端往你这边 traceroute，两条路径对比着看。这是最直观的证据，也是跟运营商扯皮时最好用的材料。

临时绕开有状态设备验证。如果条件允许，把有状态设备短时旁路或者改成宽松模式，看业务是否立刻恢复。恢复了，就说明问题不在链路，在状态一致性上。这个方法对生产环境有风险，做之前要评估好。

"同进同出"为什么重要

说白了，有状态的网络不能容忍不对称。要么你在架构上保证去回程走同一条路（通过通告策略、通过地址规划、通过让两条出口在同一台设备上做状态同步），要么你把所有有状态设备都设计成能容忍不对称（会话表跨设备同步、无状态过滤、或者干脆把状态上移到应用层）。

两条路各有适用场景。前者简单，代价是回程不完全受你控制，需要跟运营商反复调通告策略；后者灵活，代价是架构复杂度和成本。但不管选哪条，都必须明确选一条。最糟的状态是"默认假设同进同出，实际上经常不对称，而且没人验证过"——这就是开头那个"十几分钟"的另一个来源。

DNS 和客户端缓存：切换链条上最慢的一环

这一段单独拎出来讲，因为它经常让前面所有优化白做。

假设你的路由收敛做到了亚秒级、回程也调好了、BFD 也开了。故障发生时，流量很顺地切到了备用出口。然后用户还是打不开。

为什么？因为用户访问的是域名。域名的解析结果——那个 A 记录或者 AAAA 记录——可能仍然指向原来的地址。而解析结果有缓存，缓存的有效期就是 TTL。

链条上最慢的一环决定体验

把这个关系写清楚：切换时间 = max(路由收敛时间, DNS 生效时间, 客户端重试时间)。

路由收敛可能是几秒。但 DNS 这一环，你要等的是：权威服务器上的记录更新（如果是手动改，还要算人工响应时间）、各级递归服务器的缓存过期、客户端本地的缓存过期、应用层的连接池重建。这里面任何一环是十分钟，用户体验到的中断就是十分钟。

更麻烦的是有些客户端根本不遵守 TTL。部分应用、部分操作系统、部分中间件会自己固定一个缓存时长，你 TTL 设 60 秒，它照样缓存十几分钟。还有些长连接应用，连接一旦建立就不会主动重连，除非连接超时或者应用自己有重连逻辑——这种情况下，哪怕所有基础设施都在几秒内恢复了，那个连接还是会卡着，直到超时。

这带来两个实操结论

第一，如果你的切换依赖改 DNS，那 DNS 就不是"配置细节"，它是切换链路上的主路径。它的时效必须跟你的可用性目标对齐。目标分钟级恢复，TTL 却是十分钟，这个设计一开始就是矛盾的。

第二，能用路由层解决的切换，尽量别用 DNS 层解决。同一个地址段在两条出口上都能通告、靠路由收敛来切换，比"改解析记录把流量导到另一个地址"快得多，也干净得多。DNS 切换更适合做计划内迁移，不适合做故障切换。

上线前该验证什么：把单线中断演练变成例行动作

讲完原理，落到能做的事上。以下为典型部署思路，并非特指某一真实客户，请按自己的拓扑和合规要求调整。

演练怎么做

选窗口。挑业务低峰，提前通知相关方，明确回滚条件。演练不是炫技，搞出事故比不演练更糟。

模拟真实故障形态，别只拔线。拔光纤是演练里最容易的一种，也是最不真实的一种。要覆盖至少三种：接口 shutdown（模拟链路层中断）；在远端把 BGP 会话拆掉（模拟协议层中断）；保持接口 up、会话 established，但在中间制造转发中断（模拟最难的那一层，比如在中间设备上用策略把流量丢掉）。第三种最能暴露问题——如果这一项做出来你的业务长时间不通，说明检测机制有缺口。

全程打时间戳。这是演练的核心产出。要记录的时间点至少包括：故障注入时刻、设备检测到故障的时刻、本地转发切换完成的时刻、外部拨测恢复可达的时刻、DNS 生效时刻（如果涉及）、业务层恢复正常的时刻。

要记录哪些指标

检测时间：从注入到设备产生第一条相关日志/告警。这是你所有优化动作的靶心。

本地收敛时间：从检测到流量真正从备用出口转发出去。

端到端恢复时间：从注入时刻到外部监控点确认可达。这个数才是用户感知的那个数。

丢包量：整个切换过程中丢了多少包，持续多长时间。这个比"有没有通"更有意义——很多业务能容忍短暂丢包，但不能容忍长时间丢包。

回程路径变化：切换前后，回程走的是不是同一条线。如果切换后回程变了，要单独验证有状态设备是否还在正常工作。

会话表行为：有状态设备上的会话是断掉了重建，还是被保留了。这直接决定用户是"卡一下"还是"要重新登录"。

DNS 与客户端表现：如果涉及地址变化，记录解析生效时间和客户端实际重连时间。

演练出来的数字才是你的 SLA

这句话是这个主题里我最想说的：配置文档上写的收敛时间不是你的 SLA，演练实测出来的才是。

文档上写的是"理论值"，基于假设的检测机制、假设的拓扑、假设的对端行为。实测值里包含了你真实的设备型号、真实的链路质量、真实的对端响应速度、真实的 DNS 配置、真实的客户端行为。这两者差一个数量级是常事。

而且演练要定期做。网络是活的：运营商换过设备、你改过策略、业务加过新地址段、防火墙规则调整过，任何一个变化都可能让上次演练的结果失效。半年一次的演练频率不算夸张，重大变更后补一次更稳妥。

我见过太多团队，验收的时候信心满满，因为"方案写了双出口冗余"。但你问他"上一次单线中断演练是什么时候，实测端到端恢复多少秒"，答不上来。答不上来，就等于你的可用性是未知数，跟有没有两条线没关系。

跟服务商要对齐的口径

如果你的出口是托管在服务商那里，那上面这些事你一个人做不完。演练方案、检测机制（比如 BFD 开不开、参数多少）、对端支持的检测能力、回程路径的通告策略、切换时谁来操作，这些都要在签约前就谈清楚并写进合同附件，不要等出事了才发现对方只能提供"链路通断监控"这一个能力。

像一万网络这种深耕 IDC 19 年（成立于 2007 年）、手里有多节点资源的服务商，谈这类方案时会比较省力：它本身是做 BGP 多线接入的，在华南、华东、华北都有节点，中国香港及海外节点则走 CN2 GIA 回国优化线路，多宿主、回程优化这类需求属于它的日常业务范畴，沟通成本比找一个只卖单线带宽的供应商低很多。但即便如此，检测时间和收敛口径这两件事，仍然要在合同里写成可验证的条款，不能只停留在口头承诺——写在纸上的"支持多线"和"实测端到端恢复多少秒"，是两种完全不同的东西。

关于多宿主，现场被问得最多的八个问题

BFD 是不是一定要开，不开会怎样？

不开也能跑，只是你默认接受了"故障要靠 Keepalive/Hold timer 来发现"这个现实，也就是几十秒到两三分钟量级才能察觉。如果链路是直连、中间没穿传输设备，接口 down 的信号能传到你这里，这个代价还可以接受。但只要中间有传输设备，对端接口 down 你根本收不到，这时候不开 BFD 就等于把检测全交给上层探测和用户投诉。我的建议是：承载业务的出口都开，尤其是非直连的场景；参数别照抄样例，按链路实际抖动来调，调完必须演练验证，别配完就以为好了。

两条线来自同一家运营商，算不算冗余？

严格说不算完全冗余。同一家运营商的两条线路，可能在城域网里走了同一段光缆、进了同一台汇聚设备、从同一个出口出网。物理上看是两条线，实际上共享了多处单点。判断办法很实在：两条线的路由追踪结果做对比，看中间几跳是不是重合；再向运营商索取两条线路的物理路由说明。真正有意义的冗余是两个维度都分开——运营主体不同，物理路由也不同。只做到一个维度，可用性提升有限，但比单线还是强。

接口没 down、BGP 会话也在，为什么业务还是不通？

这正是最难查的那一类：控制平面健康，转发平面坏了。可能是对端设备的转发引擎出问题但控制平面还活着，可能是中间传输网在静默丢包，可能是你的包在运营商侧被反向路径校验丢掉了，也可能是回程不对称导致有状态防火墙把响应包丢了。排查顺序建议是：先看有状态设备的会话表有没有双向记录；再对比两条出口的出入流量是否失衡；然后做双向路由追踪比对去回程；最后才是抓包。别一上来就怀疑运营商，先把自己的状态设备查一遍。

怎么判断丢包是不是回程不对称造成的？

最有特征的表现是"单项测试通、业务时好时坏"，或者"切换后一切配置都对但流量过不去"。验证手段按顺序来：查有状态设备上的会话表，看五元组会话是不是只有单向记录、出入接口是不是对不上；在出口设备上对比两条线的入向和出向流量，严重失衡就是信号；做双向路由追踪，把去程和回程的路径摆在一起看；条件允许的话临时放宽有状态设备的状态检查，如果业务立刻恢复，基本可以定性。定位之后要么调通告策略让去回程同路，要么把有状态设备改成能跨设备同步会话。

收敛时间有没有一个"可以接受"的标准？

没有通用标准，因为它取决于你的业务能容忍多久。举两个极端：实时音视频和交易类业务，几秒的中断就有明显感知；异步任务、批处理类业务，几分钟都无所谓。所以正确做法是先定业务目标——比如"端到端恢复不超过 30 秒"——再倒推检测时间、传播时间、DNS 时间各能分到多少预算。而且这个目标必须区分本地收敛和端到端恢复两个数，只谈本地收敛是自我安慰。目标定完之后靠演练验证能不能达标，达不了就改架构，别改目标。

DNS TTL 设多少才跟得上切换？

先想清楚一件事：如果你的故障切换依赖改 DNS 生效，那 TTL 就是你的切换时间下限，设十分钟就是十分钟起。所以 TTL 要跟你的恢复目标对齐，目标分钟级，TTL 就必须压到分钟级以内。但 TTL 压太短会显著增加递归查询压力和解析延迟，对大流量业务是实打实的成本。所以我的倾向一直是：故障切换尽量在路由层解决，同一个地址段从两条出口都能通告，靠路由收敛切换，不走改解析这条路。DNS 切换留给计划内迁移，那个场景你有充足时间提前把 TTL 调短。

单线中断演练怎么做，会不会影响线上业务？

有风险，但可控，而且不做风险更大——不做等于你的高可用从未被验证过。控制风险的关键是这几点：选业务低峰窗口，提前通知所有相关方；准备好一键回滚，明确什么情况下立刻中止；不要在演练期间叠加其他变更，否则出问题分不清是谁的锅；故障注入从最轻的开始（shutdown 接口），确认流程顺了再做最难的那一项（接口 up、会话在、中间丢包）。最重要的是全程打时间戳，把检测时间、本地收敛时间、端到端恢复时间、丢包量、回程路径变化、会话表行为这几个数记下来。演练的价值全在这些实测数字里，不在"演练成功"这四个字里。

两条线接在同一台路由器上，这个路由器不还是单点吗？

是单点，这一点必须承认。双出口解决了链路和运营商的单点，但出口设备本身、机房的供电和空调、机房所在的物理位置，这些都没有被冗余掉。要不要继续往上加冗余，取决于你的可用性目标值不值那个钱。出口设备双机是常规做法，代价是成本和复杂度上升；跨机房是再往上一层，代价是数据同步和应用架构都要跟着改。我的看法是：先把"两条线"这一层真正做扎实——检测开好、回程调对、演练做过——再考虑往上加。很多团队的问题是第一层都没做实，就急着上双机双活，结果钱花了，故障时间一点没少。

我的判断

这个话题聊到最后，其实就一句话：验收多宿主的时候，别问"有几条线"，要问"检测时间多少、收敛时间多少、回程是否同源"。这三个问题答不上来，接十条线也是心理安慰。

那些"两条线还是不通十几分钟"的事故，复盘下来几乎都是同一个配方：检测机制用的是默认值，从来没人算过它是几十秒还是两分钟；回程从来没验证过同不同源，大家默认它是同源的；DNS 的 TTL 是某次迁移之后随手设的，跟可用性目标没有任何关系；而演练，从上线那天起就没做过。

这四件事没有一件需要花大钱，没有一件需要换设备，全都是"做没做"的问题。反过来说，也全都是"不做就一定会在某次故障里付账"的问题。

如果你正在评估多宿主方案，或者已经接了两条线但没做过演练，那我建议的第一件事不是加带宽、不是加第三条线，而是：找服务商把检测和收敛的口径问清楚，约个低峰窗口，把主用出口断一次，把所有时间点记下来。你得到的那张时间表，比任何方案文档都值钱。

文中提到的时间量级来自哪里，以及哪些必须自己复核

本文涉及的时间量级（链路层毫秒级、协议层几十秒到两三分钟量级、BFD 亚秒级、整网收敛分钟级等）均为行业通用的量级描述，用于建立判断框架，不构成任何具体设备或任何具体网络环境下的承诺值。不同厂商、不同软件版本、不同配置参数下的实际数值差异很大，请勿直接引用本文数字作为设计依据。

一万网络相关的品牌与网络能力信息（深耕 IDC 19 年、成立于 2007 年、BGP 多线接入、华南/华东/华北多节点、中国香港及海外节点 CN2 GIA 回国优化线路等），可前往官网 https://www.idc10000.net/ 相关页面查阅。文中未列出任何一万网络的产品报价；如涉及具体方案的费用，具体以签约时最新报价与合同为准。

需要你自行复核的部分包括：你自身设备的检测机制默认值与当前实际配置、两端 BFD 支持情况与参数协商结果、两条出口的实际物理路由是否重合、回程路径在切换前后的变化、域名的实际 TTL 与客户端缓存行为，以及最关键的一项——通过演练实测出来的检测时间、本地收敛时间与端到端恢复时间。这些数据只能来自你自己的网络，任何文档和文章都替代不了。