Number Resource Society
路由一旦出错,正常运行的业务也会失联
从路由泄漏、劫持、ROA 错配到注册记录争议,辨明服务为何失联,按步骤恢复连接,并把号码资源纳入业务连续性管理。
本页内容

路由故障的表现:丢包、高延迟、路由环路与服务中断。图中展示的是症状,不是某次具体事故,也不是协议规范。
打开网站、调用 API、连接云端服务,一次看似简单的请求,可能跨过多个独立运营的网络。BGP(边界网关协议)让这些网络交换可达性信息;平时,用户几乎感觉不到它的存在。
故障发生后,情况就完全不同:前缀从路由表中消失,流量绕向错误的网络,未经授权的 ASN 开始宣告地址段,或者业务刚完成 ASN 迁移,ROA 还停留在旧配置。再复杂一些,实际运行的网络、路由授权、注册记录和机构处理程序会彼此矛盾。
对 ISP、云平台、托管商、数据中心、电信运营者和企业来说,这已经超出网络设备故障的范围。客户能否访问、交易能否完成、业务能否继续,都取决于它。因此,路由韧性必须与号码资源管理、RPKI、记录准确性、实际控制权、资源可迁移性和连续性预案一起考虑。
互联网如何找到一条路
互联网由独立运营、彼此交换流量的网络组成。ISP、云服务商、电信企业、大型企业、大学、内容网络、数据中心和托管商,都可能运行以 ASN 标识的自治系统。
通过 BGP,网络向邻居传递这样的信息:“经过这条路径,可以到达这个 IP 前缀。”信息继续向外传播,各网络根据 BGP 属性和自己的策略选择路由。全球没有一台中央路由器替所有数据包决定方向,这正是互联网能够扩展的重要原因。
这种去中心化也意味着,网络必须判断其他网络提供的信息是否可信。一条错误信息被接受和转发,影响就可能沿着互联关系扩散。
路由故障有哪些表现
路由出错,意味着流量没有沿预期或获授权的路径抵达目标前缀。常见表现包括网站打不开、应用失联、延迟骤增、丢包、流量经过异常网络,以及只有部分地区能够访问。也可能直接观察到前缀撤回、起源 ASN 改变,或原本正常的路由变成 RPKI Invalid。
原因可能是误操作、恶意宣告、技术记录不一致,也可能是管理层面的变动没有反映实际运行状态。先分清故障发生在哪一层,才能避免修好了服务器,客户仍然连不上。
路由泄漏:信息传到了不该去的地方
网络从一家上游学到路由,却因为导出策略错误,又把它通告给另一家上游;后者接受并继续传播,流量就可能被吸引到本不应承担中转的网络。这就是路由泄漏的一种典型情形。
泄漏不一定涉及攻击者。一次普通的配置错误,也可能造成拥塞、高延迟、丢包、局部中断,甚至大范围不可达。控制 BGP 策略、前缀过滤和生产变更,是防范这类问题的基础。
路由劫持:谁在宣告不属于自己的路由
当某个网络未经合法授权宣告一个前缀,而其他网络又接受了它,流量就可能进入错误的自治系统。后果包括业务中断、流量重定向、连接丢失、潜在的截获风险、安全告警和客户受影响。
传统 BGP 并未要求每条起源宣告都附带资源持有者的密码学授权证明,RPKI 正是为弥补其中一部分缺口而引入。这里必须区分三件事:看到了路由宣告、查到了注册记录、确认了合法运营控制权。它们互有关联,却不能互相替代。
小小的配置错误,也可能切断大量客户
错误宣告前缀、漏宣告、过滤规则写错、使用错误 ASN、意外撤回路由、local preference 设置不当、放出不应出现的更具体前缀,或者迁移后没有更新路由,都可能造成严重故障。
路由变更应按生产变更管理。操作前必须明确:究竟应当宣告哪些前缀,又由哪个 ASN 获授权宣告。网络规模越大,一处小错误影响的客户越多。
RPKI 与 ROA 必须跟上网络变更
RPKI 提供可用密码学验证的资源授权信息。资源持有者通过 ROA 指定允许起源宣告的 ASN、IP 前缀,以及可选的最大前缀长度。执行路由起源验证(ROV)的网络,会将 BGP 宣告与已验证的 ROA 数据进行比对。
只要有一条覆盖该路由的有效授权数据同时匹配 ASN 和允许的前缀长度,状态就是 Valid;有覆盖数据、却没有任何一条匹配,才是 Invalid;没有覆盖数据,则是 Not Found。验证状态供本地路由策略使用,并不证明整条路径都安全。
例如,公司已经把业务切换到新的起源 ASN,ROA 却仍只允许旧 ASN;或者宣告的子前缀长度超出了 maxLength。实际合法运行的路由也可能因此变成 Invalid。授权信息必须与经过核实的网络变更同步。
安全工具不应成为争议中的施压手段
RPKI 的用途是维护路由安全,帮助网络判断某个 ASN 是否获准起源宣告某个前缀。NRS 主张,这套安全机制不应被扩张为处理商业、机构、会员或政策争议的通用处罚工具。
商业用途、客户所在地、地址租赁、注册政策、会员关系和企业结构方面的分歧,并不会自动构成路由安全故障。对于仍在合法运营的网络,安全声明应围绕技术有效性和已确认的运营控制权,而不应成为无关争议的筹码。
否则,原本用于保护网络的基础设施,就会反过来威胁业务连续性。RPKI 应维护路由完整性,不应惩罚政策上的不同意见。
起源验证不能包办路由安全
ROV 回答的是“这个 ASN 是否获准宣告这个前缀”,并不逐段验证完整 AS 路径。它不能独自消除路由泄漏、所有路径操纵、内部路由错误、上游配置故障、物理断网或不良路由策略。
因此,RPKI 要与前缀过滤、IRR 记录、BGP 监测、路由策略管理、准确的资源记录和受控变更一起使用。理解两者的分工,才能把保护措施用在正确的位置。
过时的 IRR 记录也会影响可达性
互联网路由注册库(IRR)记录路由策略信息,运营者常据此生成过滤规则。例如,上游可以参考 route 对象,判断某客户 ASN 预期会宣告哪些前缀。
客户更换 ASN、地址段更换运营者、旧对象未删、新对象未建,或者网络架构调整后没有同步记录,都可能让合法路由被过滤,也可能使过滤规则失去约束力。路由记录属于实际运营基础设施,不能当成填完便无人维护的表格。
WHOIS 和 RDAP 为什么仍然重要
WHOIS 和 RDAP 不负责转发数据包,但能帮助排障人员核实前缀关联的组织、联系人、所属注册机构及组织变动,并与预期起源 ASN 等其他资料交叉核对。
错误的联系方式未必造成最初的故障,却可能让故障拖得更久。号码资源记录应持续维护,而不是只在申请或审计时才打开。
记录应反映现实,而不是替代现实
号码资源必须保持唯一,资源关系、联系信息、登记状态、转移、安全声明和争议都需要可靠记录。但数据库不是正在运行的网络:交换路由的是路由器,执行策略和维护基础设施的是运营者,依赖服务的是客户。
NRS 提出的连续性原则,可以表述为“运行中的网络—运营控制权—路由授权—注册记录”。这些层次应当相互印证,出现矛盾时应进行核实和协调,而不是破坏服务。
这是一项治理主张,不是协议规定。能在 BGP 中看到一条宣告,也不等于已经证明合法控制权;仍需结合授权、记录、运营证据及适用的权利关系判断。
记录有争议,网络仍在运行,怎么办
一个 IPv4 地址段可能已经承载客户、应用、DNS 记录和安全白名单,其 ASN 仍在宣告路由。此时若出现管理争议,就可能同时存在几种状态:客户正常使用、BGP 可见、登记记录受争议、安全授权待核查、合同主张相互冲突。
NRS 主张,在独立处理争议的同时,维护最后一次经过核实的合法运营状态。不能因为修改了一项登记记录,就假定客户、合同、控制权和网络运行的其他事实也随之消失。
应保护已有路由、客户服务、安全声明、DNS 与反向 DNS、登记历史和证据,并为中立的争议解决留下空间。行政分歧不应无端变成客户断网。
登记、授权、宣告和接收是不同环节
登记为地址段持有者,不会自动使地址可达;还需要 BGP 宣告和其他网络接收。反过来,技术上能宣告一个前缀,也不能证明其资源关系都正确。
排障时应分别确认:记录写的是谁,谁拥有实际运营控制权,哪个 ASN 获授权,哪个 ASN 正在宣告,以及哪些网络接受了宣告。网络工程、资源管理和安全团队需要理解彼此的工作,不能把注册信息、路由和 RPKI 放进互不沟通的部门。
服务器正常,客户仍可能打不开网站
用户不会看到 BGP 消息。他们只会发现“网站打不开”“这个国家能访问,另一个国家不行”,或手机网络可用、固定宽带却失败。
各网络收到并选用的路径可能不同:有的正确到达,有的走错,有的拒收。因此,应用监控显示服务器健康,不足以证明客户能够访问。对客户而言,无论故障在服务器还是路由,结果都是服务不可用。
路由故障为何必须进入业务连续性管理
路由事故很快就会超出网络工程团队的职责边界,影响收入、支持、承诺、信任和跨团队协作。
收入
SaaS、云平台、托管、金融科技、电商、ISP、游戏和其他在线业务,都可能因为客户无法访问而停止交易。后台继续运转,并不意味着收入仍在产生。
客户支持
即使应用没有报错,客服工单也可能迅速增加。支持团队需要准确的影响范围和恢复信息,而不只是“服务器正常”的答复。
服务承诺
基础设施企业通常有可用性承诺。内部系统运行正常,也不能排除路由中断触发 SLA 问题。
客户信任
客户一般不会区分服务器坏了还是路由错了。一次无法访问的体验,就足以影响他们对服务可靠性的判断。
处置成本
恢复可能需要网络工程师、上游、外部运营者、安全团队、注册和号码资源管理人员、RPKI 管理员、客服及管理层共同协调。号码资源连续性因此必须纳入整体业务预案。
如何判断问题出在路由
不要在服务失联后立即认定应用或服务器出了问题。先从可达性、起源、验证状态和近期变更建立排查线索。
前缀还看得见吗
查看不同的全球路由观测点。如果受影响前缀消失,应检查 BGP 宣告是否停止或被撤回。
现在是谁在宣告
将观测到的起源 ASN 与预期值比较。异常起源可能来自配置错误、迁移遗漏、劫持,也可能暴露授权记录尚未更新的问题。
RPKI 状态有没有变化
确认状态是 Valid、Invalid 还是 Not Found。若合法的网络变更后突然出现 Invalid,应检查 ROA 是否仍匹配,而不是仅凭状态直接判定攻击。
有没有异常的更具体前缀
更具体的路由可能从聚合路由吸走流量。检查目标地址段时,也要查看其子前缀。
故障前改过什么
回看路由器配置、上游迁移、ASN、RPKI、前缀过滤、基础设施和注册记录的变更时间。时间上的对应关系往往能缩小原因范围。
配套记录还准确吗
核对注册和 IRR 信息是否与已确认的生产网络一致。不能只看路由器,也不能只看登记数据库。
八步恢复流程
先明确正常状态,再比对外部观测、检查授权和过滤,最后修复并验证恢复。这样可以减少多人处置时的猜测和重复操作。
1. 写清楚正常状态
记录受影响前缀、预期起源 ASN、预期上游、计划中的 BGP 宣告、当前 ROA 以及相关 IRR 对象。没有基线,就难以判断究竟偏离了哪里。
2. 比较多个网络的观测
不要只看本地一台路由器。对照不同网络和地区的结果,判断故障局限于本地、上游、某一区域,还是已经广泛传播。
3. 核查 RPKI
检查前缀、ASN、最大前缀长度,以及证书是否仍有效、签名 ROA 对象是否通过验证。网络架构刚发生变化时,还要确认 ROA 是否同步调整。
这里的有效期指证书和签名对象的验证条件;ROA 载荷中并没有单独的“授权期限”字段。证书到期或撤销,会影响对象有效性,但不会直接把所有相关路由都变成 Invalid。最终状态取决于其余仍然有效的授权数据。
4. 检查 IRR 和前缀过滤
确认上游过滤规则允许客户合法、预期的宣告,尤其注意迁移和资源变更后尚未更新的对象。
5. 向相关网络提供可操作的信息
联系上游或对等互联方时,提供前缀、预期 ASN、实际观测 ASN、RPKI 状态、事故时间和路由证据。比起笼统地说“网络坏了”,这些信息更有助于定位问题。
6. 修复错误发生的位置
如果原因在自己的网络内,应修正配置,并核实正确路由已经向外传播。只在边缘绕开症状,可能留下持续扩散的错误。
7. 在争议期间保护连续性
涉及登记或资源控制争议时,应保留最后核实的路由状态、安全信息、登记历史和证据,尽可能维持客户服务。争议解决不应依赖不必要的破坏性变更。
8. 持续观察恢复
路由变化不会同时出现在所有地方。继续检查各地可达性,直到预期路由稳定可见,客户连接也恢复稳定。
日常怎样降低路由风险
事故无法完全杜绝,但可以降低发生概率和影响。日常维护要同时覆盖授权、过滤、监测和记录。
随网络变更维护 ROA
起源 ASN、上游、前缀长度或网络架构改变时,都要复核 ROA,确保它反映实际获授权的路由安排。
使用路由起源验证
接收 BGP 路由的网络,可以把 RPKI 验证结果纳入自己的路由策略。验证状态和是否接收路由,是相关但不同的决定。
维护准确的 IRR 信息
路由对象应与合法、预期的宣告一致。创建新对象和处理过时对象都属于变更的一部分。
限定邻居能够宣告的范围
不能默认一个 BGP 邻居可以宣告任何路由。合理的前缀过滤能够限制错误向外传播。
监测宣告变化
关注前缀消失、新起源 ASN、意外的更具体前缀、RPKI 状态改变,以及异常 AS 路径。越早发现,越有机会缩短中断。
让登记资料保持可用
联系人、组织信息和资源记录必须随现实变化更新。事故发生时,能否找到真正负责的人很重要。
资源需要一条真正可走的退出路径
NRS 主张,运行中的网络不应永久依附于某一家机构。注册机构或服务商可能发生故障、破产、技术中断、重大治理争议、法律上的履职障碍,或失去运营者的信任;这些问题不应让资源本身失去连续性出路。
资源级可迁移性,不等于搬走整家公司。它意味着,某项资源的登记和运营连续性不应被困在失效的机构结构中。更换管理服务提供者时,应能够保存控制权证明、登记记录、反向 DNS、RPKI、路由连续性和历史审计资料。
这部分以及下文的注册服务故障转移,是 NRS 提出的制度设计方向。现实中能否实施,取决于适用机制和机构安排;本文不承诺任意资源今天就能自由迁移或切换。没有退出路径,机构故障就容易演变成网络故障。
注册功能应能在机构失效后继续
关键基础设施不应把命运完全押在一家法人机构的存续上。功能越重要,就越需要提前设计失败后的接续方式。
号码资源的连续性安排应涵盖登记状态备份、历史记录、WHOIS/RDAP、反向 DNS、RPKI 仓库、安全凭据、转移历史、争议元数据及后续管理责任。
要保护的是互联网真正需要的登记功能,而不是默认必须保住现任董事会、全部政策结构、每一种合同解释和既有机构权力。机构可以更替,关键功能应当延续。
保护登记账本,不是保护把关者的无限权力
互联网确实需要可信协调:地址必须唯一,记录必须准确,路由安全声明需要持续可用,争议也应有据可查。但维护记录的机构,不等于记录本身。
机构出问题时,应优先保护账本、安全链、路由、客户和运行中的网络。不能因为某组织掌管着基础设施的一部分,就要求全系统无限维持它的控制权。
协调功能越关键,其运营者就越应当可审计、可替换、可迁移,并具备抵御故障的能力。
以运行中的网络为本
“Running-Code Primacy”在这里表达的是 NRS 的原则:共同协调层应围绕真实互操作所必需的事情运作。
对号码资源而言,这包括唯一性、准确记录、控制权证明、安全声明、转移记录、冲突信息和运营连续性。它并不自动赋予注册机构控制商业模式、客户所在地、租赁、资产融资、企业战略和资源一切未来用途的权力。
这些事项可以由合同、法律、市场、运营者或其他适当机制处理。除非确实威胁唯一性或互操作,不应把相关分歧转化为路由故障。明确注册层的职责边界,才能让运行中的互联网更有韧性。
“稳定”首先应当指客户还能连上
机构稳定与网络稳定并不是同一件事。办公室正常营业、客户网络却已经离线,不能算保护了互联网稳定。反过来,机构遇到治理问题,而网络仍在正常路由,也不能直接等同于互联网失稳。
更有意义的衡量是:合法网络能否继续运营,客户能否保持可达,路由能否传播,有效安全声明能否维持,争议能否在不破坏生产基础设施的前提下解决。治理最终应保护这样的连续性。
为号码资源制定连续性预案
企业会为电力、数据中心、云服务、网络传输、硬件、人员和网络安全准备预案,号码资源也需要同样的重视。
至少应答清:前缀从 BGP 消失时怎么办;谁能修改 ROA;谁掌握 RIR 账号;每个前缀由哪个 ASN 宣告;哪些客户依赖固定地址;哪些应用依赖现有地址段;谁能联系上游;注册机构不可用时怎么办;哪些证据能证明资源控制权;登记服务能否接续;出现资源争议时怎样维持服务。
IP 地址和 ASN 已经嵌入业务
公共 IP 地址和 ASN 可能连接着客户、API、DNS、防火墙、VPN、合作伙伴白名单、云系统、安全策略、支付网络、监控和合规文件。它们早已不只是后台技术资料。
服务器健康、应用运行、机房有电,仍不足以确保服务可达。前缀无法正确路由,用户就连不上。号码资源连续性必须成为业务连续性的一部分。
目标是互联网持续运转
前缀消失、流量走错、意外 ASN 宣告、合法路由变成 Invalid、不同地区访问结果不一,都可能来自配置错误、泄漏、劫持、错误过滤、过时 ROA、陈旧 IRR、登记错误,或管理状态与运营事实脱节。
保护路由不能只盯着路由器。运行网络、号码资源、路由授权、登记记录、安全基础设施和实际控制权必须相互协调。记录应反映事实,RPKI 应服务路由安全,争议应独立处理,资源应有退出路径,关键注册功能应有接续能力。
要保护的不是机构永远存在,而是互联网持续运转。保护客户、运行网络、安全声明和登记账本,不要把把关者与它本应服务的基础设施混为一谈。
常见问题
互联网路由问题通常由什么引起
常见原因包括 BGP 配置错误、路由泄漏、未授权宣告、错误过滤、RPKI 或 ROA 配置问题、上游故障,以及路由与资源记录之间的不一致。
什么是 BGP 路由泄漏
路由信息被传播到了预期策略范围之外,可能把流量引向非预期路径。泄漏可能源于误配置,并不一定是攻击。
什么是 BGP 劫持
未经合法授权的 ASN 起源宣告某个前缀,其他网络若接受它,流量就可能被重定向。
RPKI 能做什么
它提供可用密码学验证的信息,帮助网络判断某 ASN 是否获准起源宣告某 IP 前缀。它并不独自证明完整路径都安全。
ROA 写错会导致断网吗
会有这种可能。如果存在覆盖路由的有效授权数据,却没有任何一条匹配起源 ASN 和前缀长度,路由会被判为 Invalid;采用相应策略的网络可能拒收。证书过期或某个 ROA 对象被丢弃则是另一回事,最终状态仍取决于剩余有效授权数据。
资料来源
本文于 2026 年 8 月 11 日首次发表,8 月 13 日更新。证书及签名对象的有效性与路由起源验证状态是两回事。文中的连续性、资源迁移和注册功能接续是 NRS 推动的制度主张,并非已经普遍可用的服务。
把号码资源纳入下一次连续性检查
NRS Shield 是运营商把个体风险转化为集体力量的地方;授权委托书则是你授予 NRS 为你的网络行动之权力的方式。
